I'm planning to transition to 45-day certificate lifetimes ahead of the mandatory enforcement. To do this early, we want to opt-in to the tlsserver profile.
However, I'm facing a blocker with some existing certificates that contain more than 25 SANs (some up to the 100 limit).
I'm looking for advice or workarounds for this scenario:
Is there a way to opt-in to 45-day lifetimes on the classic profile?
If we could get 45-day certs while keeping the classic profile, we wouldn't have to split our certificates.
If we must split certificates to use tlsserver:
How should we manage the transition to avoid hitting rate limits? Splitting a single 100-SAN cert into four 25-SAN certs will significantly increase our certificate count. We are concerned about the "Certificates per Registered Domain" limit.
What is the long-term plan for the classic profile SAN limit?
When the classic profile eventually transitions to 45-day validity (Phase 3 in 2028), will it still support up to 100 SANs? If so, is our only option for >25 SANs to wait for the classic profile transition?
I would appreciate any recommendations or shared experiences from others who have navigated this.
Thanks!
Can you explain more about that concern? Because that limit is 50 certs per week for "new orders" that use the same registered domain. Is there one registered domain you are issuing numerous subdomains for? In which case if those are for different organizations you might (should) be on the Public Suffix List. Further, Let's Encrypt offers rate limit exemptions which you could apply for now.
Otherwise more details would be helpful. Perhaps you wouldn't be affected at all.
Huh. I hadn't realized that the maximum names per cert was different for different profiles.
No; if you need that many names on a certificate then you're not ready for the tlsserver profile.
That limit is only for new names, so if the names on the next certs are the same as the names on the old certs then you shouldn't need to worry about it.
I don't know as anything about that has been publicly announced, though I may have missed it. In general, though, over 25 is a lot and requires a lot of checking in order to issue, with more things that can go wrong, so I would recommend trying to have certificates that use that many or fewer in general, regardless.
Yes, we are (slowly) attempting to reduce the number of names per certificate, and the lower limit on the tlsserver profile is part of that. We have no concrete plans to reduce the limit on the classic profile, but I can't guarantee that we won't, either.
The vast majority of 100-SAN certs fall into two buckets:
domain collectors/squatters who could re-shard their names to fall onto 4x more certs without issue; and
users who should probably be getting a wildcard cert instead of putting 100 subdomains all on a single cert.
When I am capable the enumerate the subdomains in the domain I am responsible for, I prefer to have them listed explicitly in the certificates. Of course, I have wildcard certificate too, where the label on the last level is unknown, for example changes dynamically or outside of my control and would require extra coordination with my counterpart responsible for the service itself.
The third one is some shared infrastructure in some cloud services, where all domains on a specific server, gets a shared certificate. I know Cloudflare previously had 100 SAN certificates for their free tier.
It might be worth to check which >25 SAN certificates that are hosting companies or similiar, and look into different types of exceptions for these.
Wrong. You should not need to use different certificates since its the mailserver HOST that need to match the certificate, not the domain after @.
So if you have a MX that is yourdomain.com IN MX 10 "mail.example.com"
its the "mail.example.com" that needs to be in the certificate, thus a single mail server can host 100s of domains on a single SAN.
It's not me that's using these [mail hosts that offer custom domain smtp/imap etc often offer imap.yourdomain.com or mail.yourdomain.com etc, they are often very small local providers like an IT service provider etc]