We all know that CRL and OCSP has come at its end. Also, there was CA/Browser Forum's Ballot SC-081v3 for adopting shorter certificate lifetimes and Let's Encrypt's own announcement of 6-day certificates.
What I wonder is this:
Are you aware that with, say, 10-day lifetimes, you will probably arrive at a renewal rate of 20 times of the current?
Currently, with 90 day lifetimes, you will probably have a renewal every 60 days - just because 30 days of safety margin will be sufficient when you monitor your certificates and get notified about a problem in your automation, when a certificate will expire in less than 30 days. With a 10-day certificate, you would have a reaction time of just 3 days if problems arise. This is not enough over a long weekend, if you do not have 24/7 support, so you will not renew every 7 days, but every 3 days. With 6-day-certificates, you will most likely renew once per day.
Is Let's Encrypt prepared to handle that kind of load?
Currently, there are limits in place, e.g. for new certificates for an exact set of hostnames, the latter cannot even be lifted on request. I think this will get problematic with shorter lifetimes: consider the case when someone uses wildcard certificates only via DNS-01 validation, e.g. because they do not want to have all specific hostnames exposed on the transparency list at crl.sh. If they have multiple sites at which those certificates are generated, they can have more than 10 of these and do not hit said limit.
With shorter renewal intervals, these limits will have to be lifted accordingly - or customers will run into problems.
Welcome @meyergru I am sure others will also reply but thought I'd start.
Yes, they are well aware And, Let's Encrypt has no plan for 10-day certs. Their plan is 6+ day for "shortlived" so as not to need revocation information. See: Profiles - Let's Encrypt
The OCSP infrastructure is resource-hungry so that gets freed up. I don't know all of their plans for load management but I am confident they have considered it well.
There has been no announcement about lifting that particular limit. If you are getting the identical cert from multiple servers you should look at getting it from one server and sharing it with the others. There are numerous strategies for this.
It is wasteful to get the identical cert multiple times. And, possibly introduces complexity and higher failure rates in your own infrastructure.
With "shortlived" certs from any CA you should also look at having fallback to an alternate CA in case of long outages or other issues. This doesn't replace the goal to simplify and consolidate certs. Switching to "shortlived" is not a simple plug and play from longer duration certs. A quote from the shortlived section of the profiles page I linked earlier:
We recommend this profile for those who fully trust their automation to renew their certificates on time. This profile is not for everyone. Because this profile results in much higher issuance volume (since certificates need to be renewed every few days, instead of every few months), it is currently locked behind an allowlist.
That is poor practice and unduly burdens the CA. Your ACME Client should support ARI and rely on that. If you can't fully trust your automation or have the staff to manage it you shouldn't use shortlived certs or find an automation that allows that. Some systems, like caddy server, already have fallback CA built-in. Options like CDNs can manage alternate CA and managed automation.
I believe that in time we may see more ACME Clients with such abilities. It is a significant change and the ecosystem will adjust accordingly.
With different physical servers, using the same certificate and "distributing" it may not be feasible. There are many services and tools which all use the ACME.SH or similar means to get certificates, yet are unable to be centrally provisioned otherwise. On the other hand, there are valid reaons why you would not want different certificates for each site. I, for once, have recently discovered, that port scans on IPv6 are actively used on domains I had certificates for. Those were not feasible with IPv6 if not for the exposure of specific names.
You kind of contradict yourself: You say Let'sEncrypt will not even offer 10 day certificates, yet with the accepted shortening in the next years they must - or use even shorter ones like 6 days.
As a matter-of-fact, 6 or 10 day certificates will be the only ones viable by 2029. So, anybody must use them, if they have 24/7 support or not. And if they cannot afford that (like many small businesses do), but still need 100% availability, what can they do besides "poor practice", if their reaction time to automation problems is reduced to 1-3 days, depending on what is considered normal for 6 or 10 day certificates?
P.S.: I know of backup CAs in Caddy, but automations may fail for various reasons at some point in time - I experienced a fair share of those. Besides that, the availability of the CA at hand will then be of concern, too. Not with Let'sEncrypt, but I have seen downtimes for ZeroSSL, for example. Those are not a problem for renewals due in 30 days, but certainly for 3 days.
Let's Encrypt offers 90-day certs and shortlived 6+ day certs are pending. That is 6d and some hours something like 6d18h I forget exactly. It does not mean 6 or more days. There is no LE announcement for certs with 10-day lifetimes.
No, 47 day certs will be available in 2029. The progression from the current "longer lived" certs will reduce to that. "shortlived" certs are a different scheme
Oh, I see, I misunderstood that. The ballot has reduced to re-use of validation data only to 10 days in section 4.2.1. The certificates themselved will only be limited to 47 days in section 6.3.2 as indicated here:
That would probably result in renewals every 30 days with two week of reaction period, which should be enough.
To provide a little bit of additional info: yes, we're very aware of the increased issuance load that accompanies shorter-lived certificates. We've standardized, helped develop, and deployed a whole new kind of CT log to support much higher issuance volumes. We're in the process of removing our OCSP infrastructure, which will free up compute, network, and database resources. And you'll soon see a blog post talking about the database changes we're making internally to allow our storage to scale with our issuance.
The advice up thread is very good: default certs will only be shortening to ~45 days over the next 4 years, you should only opt in to shortlived certs if you think your ACME client automation is reliable enough to support it, and having a backup CA is always a good idea.
Yep. Coming from my misunderstanding of 10 instead of the actual 47 days, I was thinking that the needed scaling factor would be much more for the discussed (and now invalid) reasons, namely around 20. For a "usual" future renewal rate of one in 30 days instead of 60, the scaling factor would only be 2.
This should also be O.K. for the current rate limits, so my concerns have been cleared.
what I worry about is how many clients are using hardcoded dates assuming 90 days cert by default:
I found some renew 30 days before expiry (so it'll renew every two weeks) or even 60 days after first signing (acme.sh, unless manually configured, so it will renew after two weeks already expired)
And, Let's Encrypt has no plan for 10-day certs. Their plan is 6+ day for "shortlived" so as not to need revocation information. See: