for each 99 verified customer subdomains that get added, discard/ignore the original certificate and bundle the 99 into a SAN cert with assets.my-service.com as the common name (the first domain provided to letsencrypt) so that assets.my-service.com shows up in browsers rather than 1 of the 99, which wouldnāt be good optics
There will be more than 99 customer subdomains added, so my question is very specific: can assets.my-service.com be the common name (the first subdomain) for many letsencrypt issued certificates (so it gets displayed in browsers) in a production setting, say in haproxy or via many CDN APIs?
Edit: Ok, investigating ssl certificate transparency logs for cloudflare-issued 3rd party subdomain SAN certs, the common name used is a unique subdomain (eg sni115847.cloudflaressl.com) as the common name for each of their shared certs.
I assume that anyone attempting what Iām doing would have to do the same - and that itās not issuer-specific, but technical limitations of https in the browser?
Iād appreciate confirmation/correction on the above! Thank you!
Given your statement, would using assets1.my-service.com, assets2.my-service.com, etc (unique common name per cert) avoid this rate limit? I thought the rate limit was at the domain level, not subdomain?
Youāre correct. That would also be affected by the 20 certificates per domain rate limit, in exactly the same way. Youād need to either request a rate limit increase orā¦ choose not to create more than 20 certificates per domain per week.
For $0.66 you could get the domain my-service-00.cricket.
Edit:
Keep in mind that every certificate you issue affects the rate limit of every customer domain included.
The most rate-limit friendly thing to do is to issue 1 certificate per customer domain. (Or temporarily more than 1 if customers add different domains at different times, consolidated when the oldest one is later renewed.)
Even though you would actually be managing 99+ times as many certificates.
Iām guessing youāre looking into this in order to avoid a situation where someone inspecting the certificate of a site sees the subdomain of a different customer on the same certificate?
Iām not 100% certain if this is enabled in production yet, but I think Letās Encrypt lets you issue certificates without a common name if you donāt set one in the CSR. In that case, Letās Encrypt would set the subject to the certificateās serial number. That might solve your issue without having to think about rate limits. Iām not aware of any compatibility issues in mainstream browsers due to no common name being set, but you might want to double-check that.
Ewwww, I don't really want to manage a growing set of domains if at all possible, but you're right, this is an option.
Right, I remember reading that in the limits doc - thanks for the reminder.
That was my thinking: issue individual certs for 99+ of customer domains, then consolidate them (and discard/ignore the old certs) into a SAN cert at that point.
What I'm not sure of is how to deal with churning customers who remove their CNAMEd subdomain from my service - do they automatically get removed on the next SAN cert renew? If so, can I add in a different customer subdomain to keep the number of customer domains in the SAN cert at 99?
My understanding was if I changed any domains in an existing SAN cert, it counts as a 'new' cert instead of a 'renew' - and so impacts domain limits?
Indeed, this is the case yes.
Sounds neat, that is interesting. How would I find out if this is actually the case and planned for a future release?
Generating a CSR that doesnāt have a Common Name manually and submitting that using certbotās --csr flag should do the trick. Something like this should do for OpenSSL, or you could use this go code.
Itās up to your client. I would guess that most would bail out and refuse to renew if a single subdomain failed.
Certbot, for example, will do so by default. But it also has a --allow-subset-of-names option to drop names that fail.
On the other hand, it would be terrible if a clientās DNS had a brief outage at just the wrong time and their certificate got permanently dropped.
Well, you can. Youād probably have to script it.
Correct. For purposes of the renewal rate limit exemption, it has to be an exact match. Adding or removing names, or combining two certificatesā names into one, would count as a ānewā certificate.
You're a fountain of information - thanks. This is something to investigate further! Not sure how to find out the level of browser support for SAN certs without a common name though. Tips to where I might look?
Hmmm. I presume if a domain fails with this option enabled, it wouldn't be included in the resulting cert. If so...
Does --allow-subset-of-names mean it does a 'new' cert (affecting domain limits) or does it continue with a normal 'renew' if a domain fails? Meaning, are domain rate limits affected if there is a single failed domain during a renew of a SAN cert?
Yes, that's understood, thanks.
This sort of implies that rate domain rate limits aren't affected as long as the submitted domains are identical (thus, remains a cert 'renewal'), even if one fails. Is this accurate?
Iām not aware of any large-scale tests on this. Common names were deprecated ages ago in favour of SAN, so in theory, there should be no issues. That said, you never know what some weird, outdated TLS middlebox might do. The only report I could find is this post saying they experienced no issues without a common name.
If you want to be absolutely certain, Iād suggest running a small subset of your sites with a common name-less configuration and watching if thereās a noticeable drop in requests or increase in errors.
Support for Subject Alternative Names goes way back, to IE on Windows 98 even. Any TLS client following the letter of the spec should ignore the common name completely in favor of the Subject Alternative Name.
And browsers have most likely gotten it right, itās corporate filters and antivirus programs that MitM HTTPS traffic that are of concern. And itās really hard to test all those.
Virtually all clients support number 1, of course. But who knows how many clients have brittle certificate parsers that assume CN will exist, whether or not itās used. It canāt just be assumed.
Chrome started entirely ignoring CN literally two months ago, in M58. It caused big problems for enterprise users and they added a (temporary) policy flag to turn it back on.
I was just pointing out the correct behavior with or without a common name has been specified for a long time, as long as SANs have been a thing, and therefore well-behaved TLS clients should have gotten this right for a long time. Whether they do or not in practice is a different matter.
Browsers are pretty good about getting this stuff right by and large, it's really just corporate filters and non-browser clients where you'll run into trouble.
IIRC, they dropped support for common names entirely, and of course that broke crappy MitM boxes that don't include SANs in their generated certificates. I doubt they ever accepted a certificate with a common name that wasn't also listed in the SAN, and they probably have supported certificates without common names for their entire existence.
Thanks for the useful banter - it pretty much shows me that I canāt assume compatibility, so I had better have a unique san<unique-id>.my-service.com (ie san3342.my-service.com, san3343.my-service.com, etc) as both the common name and the first item in the SAN list for each cert of 99 customer domains.
Great discussion, thanks to you both. If thereās any other input, itās welcome - but I think my next post will be trying to establish the issuance strategy to avoid rate limits as well as limit the number of certs I need to have active on my servers (or push up to my CDN) at any given timeā¦
Even if I submit the exact same list of names for renewal, but one or more fails http validation? If so, any large service provider will easily hit rate limits, no?
On an API level, theyāre separate operations. Thereās a āvalidate a single nameā flow and an āissue a certificate for a list of namesā flow.
You could validate 200 names, one at a time, and then issue two certificates. You could validate 200 names and then issue zero certificates.
You could issue a certificate without (recently) validating any names at all, consisting of names validated weeks ago.
Additionally, the API largely doesnāt have a concept of renewal. The rate limiting code checks if the list of names is an exact match for a previous certificateās list of names, but thatās it (as far as i know). Otherwise itās just āissue a certificateā.
Edit: In other words, youāre never forced to issue an unwanted certificate. You can abort after validating the names and before issuing the certificate,
