0.10.11, SNI and "no cert matched"

Just downloaded 0.10.11, and when browsing we are getting the message “no certificate available for xxx” in the logs. I’m assuming this is related to the note in the release:“Raise TLS alert if SNI used and no cert matched”

Presumably my browser (which is chrome) is the one choosing to use SNI, so does that mean he only way to make it work is to have a cert with the correct servername? No way to workaround?

Thanks,

David

Yeah. What is the certificate you’re trying to use? Using a certificate for a name it isn’t designated for is invalid, so we raise a TLS alert instead. The fix for this is to use a proper certificate for the hostnames you serve.

We’re using it in an environment where Caddy is embedded in a product that generates a default cert without knowing the hostname - we generate one with a default server name. It can be replaced with a valid one with the real name, but we would like it to work without forcing that. I wonder if we can use a wildcard or something to resolve.

David

What clients are expected to connect to your embedded Caddy?

Most clients would alert or outright reject an invalid (wrong hostname) certificate anyway, and would need you to skip verification to connect.

I’m wondering if simply using a self-signed certificate would suffice on the default server name, maybe with On-Demand TLS on a catch-all to handle the real domain when it’s accessed.

We serve up a GUI in addition to an API, so clients are both browsers and applications. You are right, they all correctly complain. So until a valid cert is created, customers get browser warnings and have to use things like nosslverif y

With a self signed cert we’d still need to know the real hostname, right? We won’t until a customer configs one. We just want the box operational with warnings (for eval, for example) until they do.

Hmm. A quick test on the latest version indicates that tls self_signed is more or less useless for a catch-all because of this error.

This means that the only method I can think of to have hostname-specific TLS certificates on the fly is On-Demand TLS with validated LetsEncrypt certs…

You can issue yourself a wildcard certificate, or one that covers multiple wildcards etc. The next release of Caddy will allow self-signed certs that have an empty hostname (not technically ‘correct’ I think, buuut we’re gonna see how it goes) which will match within Caddy for any hostname, but the client will still raise errors for a name mismatch…

I highly suggest using either On-Demand TLS or generating certificates with the proper name(s).

Is there any reason not to have tls self_signed issue on-demand certificates for the requested hostname when the site label is a wildcard? Might be a good feature request?

Here’s the relevant issue regarding the change @matt mentioned, to have non-matched hosts fall back to an empty-name certificate.

https://github.com/mholt/caddy/issues/2035

https://github.com/mholt/caddy/pull/2037

If I understand correctly, 2037 sounds like it will fix it. We aren’t using self-signed certificates, but we can populate the one we generate with an empty hostname.

It’s more complicated. We might as well just have a single self-signed cert with a name of "" (empty) and use that as a catch-all. The cert won’t be trusted anyway, so who cares what the name is on the certificate. :stuck_out_tongue:

But yes, we’ll have this changed in the next release. See https://github.com/mholt/caddy/pull/2037

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.