Wildcard SNIs not being matched

[matt (Matt Holt)]

@shine

Oh, I think I get it now. It’s just about when ( emphasis on the when right? ) the certificate management lifecycle starts. While in the normal mode, the management lifecycle starts during server initialization which could block / delay the startup if there were too many domains. I hope I got it right this time.

Close! Certificate management never blocks startup, it’s always in the background of the main goroutine (unless you set manage_sync to true, but don’t do that unless you have a very good reason). The only difference is that Caddy will obtain “on-demand” certificates, well, on-demand… i.e. at the first handshake that requires it, rather than in the background at config load.

@shine

I don’t intend on being a pain, but I think this is what confused me in the first place. If you don’t mind ( and have the time, no pressure to answer at all ), can you please explain this concept to me?

Sure. Say you run a SaaS / web service, and your customers bring their own domain names. You tell them “point your domains to our server” but you have no idea when or if that will ever actually happen. If you started getting a cert for that domain right away, it would fail, since you don’t know when the customer has updated their DNS. Sure, you could poll, but DNS is all a matter of perspective anyway, so it’s unreliable and expensive to do that.

All you can do is whitelist their domain when they sign up for your service, and whenever your site starts seeing handshakes for that server name, then you know it’s time to get a certificate.

[francislavoie]

@matt

All you can do is whitelist their domain when they sign up for your service, and whenever your site starts seeing handshakes for that server name, then you know it’s time to get a certificate.

To clarify the “whitelist” is with using the "ask" option JSON Config Structure - Caddy Documentation

Caddy would “ask” the SaaS whether a domain is okay to use. You’d probably have a DB table that has all the domains you allow your customers to use to point to your service, and reply with HTTP 200 if it’s in the list, 4xx otherwise.

[shine]

@matt

Say you run a SaaS / web service, and your customers bring their own domain names. You tell them “point your domains to our server” but you have no idea when or if that will ever actually happen. If you started getting a cert for that domain right away, it would fail, since you don’t know when the customer has updated their DNS. Sure, you could poll, but DNS is all a matter of perspective anyway, so it’s unreliable and expensive to do that.

All you can do is whitelist their domain when they sign up for your service, and whenever your site starts seeing handshakes for that server name, then you know it’s time to get a certificate.

Oh man, that’s the innovation right there! That’s amazing stuff! Kudos to you for coming up with that idea!

One more reason why you deserve more love in terms of sponsorship. You’ll be the first person that I sponsor when I can actually afford it.

And you’re really nice and welcoming which is another thing ( other than fast response times ) that’s not seen in other open source projects that I’ve put my hands in.

[matt (Matt Holt)]

No problem. And thanks.

I’ll spend a little time to make sure the policy matching works correctly.

What is happening in your case is with the automation policies. Those matchers are taken literally, since you can actually have a certificate with a subject of *.shine.caddy.test.shinenelson.xyz (a wildcard certificate), vs. "all certificates for subdomains of shine.caddy.test.shinenelson.xyz".

I suppose we could try lumping them together, i.e. doing an exact match first, and if not, then trying a wildcard match… not sure if that would break anything though… probably not?

[matt (Matt Holt)]

@shine I think this commit will do what you want, however, where an automation policy can match a non-wildcard name with a wildcard subject in its list: caddytls: Match automation policies by wildcard subjects too · caddyserver/caddy@c87f82f · GitHub

If you could download the build artifact from that commit and try it out, that’d be much appreciated!

[shine]

Hey, I’m sorry I missed this notification, I was away from the keyboard.

I’m not sure what this change is supposed to address. Is it the thing about generating “on-demand” TLS certificates even for wildcard domains like my actual intention?

I thought that that was a confusion on my part. Did you just make that a feature?

Should I chuck the wildcard automation stuff out of the config again?

[matt (Matt Holt)]

To clarify, – and summarize, – this config:

"tls" : {
      "automation" : {
        "policies" : [
          {
            "subjects" : [
              "shine.caddy.test.shinenelson.xyz",
              "*.shine.caddy.test.shinenelson.xyz"
            ],
...

used to do exact matching only. Now it matches on wildcards like TLS connection policies, even for non-wildcard certificates.

I originally assumed you were trying to do wildcard certs on-demand because that’s how the automation policy selection worked. I’ve changed it though so that now wildcards allow selecting on non-exact matches.

[shine]

Wow man, this is precisely what I was asking for! This was the functionality that I had in my head when I read about the on-demand feature and the “arbitrary domains” use-case.
I love you what you did there. You just converted an out-of-scope thing into a feature.

However, I thought you said that this would have rate limit implications on Let’s Encrypt’s side right? So, would that be a good idea putting it out there?

Also, what happens to domains that would actually want a proper wildcard domain like you said?

Now, this would be good if it was limited to the internal ( SmallStep ) CA or some other provider without a rate limitation ( or something that is very, very lenient ).

[matt (Matt Holt)]

@shine

However, I thought you said that this would have rate limit implications on Let’s Encrypt’s side right? So, would that be a good idea putting it out there?

My change had nothing to do with the Let’s Encrypt rate limits. Any use of on-demand is subject to abuse unless you put in protections; that’s why it’s not on by default. And if enabled, make sure to make wise use of it.

@shine

Also, what happens to domains that would actually want a proper wildcard domain like you said?

They should still be matched to the correct automation policy.

@shine

Now, this would be good if it was limited to the internal ( SmallStep ) CA or some other provider without a rate limitation ( or something that is very, very lenient ).

The issuer that’s used is also irrelevant, Caddy’s cert management will behave the same regardless of where it gets a cert from.

[shine]

@matt

@shine

Also, what happens to domains that would actually want a proper wildcard domain like you said?

They should still be matched to the correct automation policy.

How? I don’t get it.

My scenario was that I specify *.shine.caddy.test.shinenelson.xyz in my automation policy and then when I request a.shine.caddy.test.shinenelson.xyz or b.shine.caddy.test.shinenelson.xyz, I’d get 2 separate TLS certificates per sub-domain that was being requested. And with this change, that’s exactly what it did as well.

Now, my question is - what if someone else wanted a single TLS certificate with *.shine.caddy.test.shinenelson.xyz as the SNI?

[shine]

Oh, I think I get it now. My scenario would work only if on_demand is enabled right?

Otherwise, it would provision the wildcard TLS certificate during the server initialization itself ( of course, in the background! ) so then any subsequent wildcard-matching requests would pick the wildcard TLS certificate.

[matt (Matt Holt)]

@shine

My scenario was that I specify *.shine.caddy.test.shinenelson.xyz in my automation policy and then when I request a.shine.caddy.test.shinenelson.xyz or b.shine.caddy.test.shinenelson.xyz , I’d get 2 separate TLS certificates per sub-domain that was being requested. And with this change, that’s exactly what it did as well.

Good - that’s my intention as well.

But before the change, an automation policy for *.shine.caddy.test.shinenelson.xyz was literal, and would only match for those wildcard certificates.

@shine

Now, my question is - what if someone else wanted a single TLS certificate with *.shine.caddy.test.shinenelson.xyz as the SNI?

Then they would configure Caddy’s tls app to manage a certificate for that name (or do that implicitly through auto-HTTPS in the http app).

@shine

Otherwise, it would provision the wildcard TLS certificate during the server initialization itself ( of course, in the background! ) so then any subsequent wildcard-matching requests would pick the wildcard TLS certificate.

Yes, exactly. If an exact match is not available to answer a TLS handshake, then a matching wildcard will be used instead.

[shine]

Understood. This is amazing stuff man.

Now, my only wish ( I know it’s too much to ask. Hence, I’m not even asking. ) is that there are pre-built binaries in package repositories for GNU/Linux distributions ( including helper binaries for different external “modules” ), then it’d be so much more easier to integrate into automated server initialization process for thousands of servers at scale. I know there are multiple ongoing discussions on that topic as well - Packaging Caddy, V2: Packaging for Debian/Ubuntu

NB : I think this discussion has digressed away from the original topic which was for the tls_connection_policies block. Do you think we should break this post away at post 12 into a separate topic? Maybe title it to - ‘on_demand’ wildcard TLS certificates.