TLS error from older iOS app

1. Caddy version (caddy version):

v2.1.0 h1:MC4d65RCVaEKy1iOFjsD51mybOwS8qdEVBi7ESDhUfE=

2. How I run Caddy:

a. System environment:

debian 10.4

b. Command:

systemctl start caddy

or just cd /etc/caddy caddy run

d. My complete Caddyfile or JSON config:

music.example.com {
        reverse_proxy 127.0.0.1:4041
}

3. The problem I’m having:

Hi! everything is working in my desktop browsers and mobile safari, but this ios app doesn’t work.
My guess is that it’s old and doesn’t do TLS1.2 ?

4. Error messages and/or full log output:

I’m getting these in my logs:
2020/07/02 05:08:01 http: TLS handshake error from 107.77.231.106:42863: no certificate available for 'xxx.27.66.193'

but only when I use the app, not browsers.

2020/07/02 05:23:52 WARNING: proto: file "pb.proto" is already registered
A future release will panic on registration conflicts. See:
https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict

2020/07/02 05:23:52.803 INFO    using adjacent Caddyfile
2020/07/02 05:23:52.804 INFO    admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2020/07/02 05:23:52.804 INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2020/07/02 05:23:52 [INFO][cache:0xc000187e00] Started certificate maintenance routine
2020/07/02 05:23:52.804 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2020/07/02 05:23:52.806 INFO    tls     cleaned up storage units
2020/07/02 05:23:52.806 INFO    http    enabling automatic TLS certificate management   {"domains": ["music.example.com"]}
2020/07/02 05:23:52.816 INFO    autosaved config        {"file": "/root/.config/caddy/autosave.json"}
2020/07/02 05:23:52.816 INFO    serving initial configuration

2020/07/02 05:24:14 http: TLS handshake error from 107.77.231.106:53859: no certificate available for 'xxx.27.66.193'

5. What I already tried:

I tried adding like :

music.example.com {
        reverse_proxy 127.0.0.1:4041
        tls { protocols tls1.1  }
}

But it says Wrong protocol name or protocol not supported: 'tls1.1'
I think I need to specify another cipher too, but now I’m at the end of my TLS knowledge.

What I think I’d like to do is somehow log what kind of TLS this app is trying to use so I can specify that, but I can’t figure out how to log that info.

For anyone who may be googling, the app is iSub and the server is Airsonic.

6. Links to relevant resources:

Caddy v2 does not support anything older than TLS 1.2 because older versions are insecure. Caddy strives to be secure by default.

Thanks for writing.

I can use http then :man_shrugging:

I’d still like to somehow confirm that the issue is a TLS version issue.

I guess the fact that using http works kind of confirms it though.

I don’t think TLS version has anything to do with it.

This means that Caddy received a TLS connection for a hostname it does not have any certificate for. Your config is for music.example.com, not 107.77.231.106, so Caddy does not have any certificate that will satisfy the request.

Either the client needs to send a ServerName in the ClientHello of music.example.com or your server needs to be configured to provide a certificate for the IP address.

Oh thanks! Interesting.
Got me thinking and I think I’m missing some headers:

I thought I had it working for a second, but it’s not and it’s too late at night for this type of thing.

If anyone has any troubleshooting ideas LMK.

Is it possible to log response headers?
My problem isn’t a caddy problem, but I am curious to figure out why this app is deciding to use the ip address instead of the domain name for only some requests.

Yeah - if you turn on the debug global option, you’ll see additional logs from the reverse_proxy handler which should be helpful for debugging

You can also enable access logs with the log directive:

This topic was automatically closed after 30 days. New replies are no longer allowed.