Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.
Honest reply: because the infrastructure isn't ready to support 1-day certificates yet. If your cert is only valid for one day, and renewal fails on a Saturday, then your site is unusable until you get back to work on Monday and do something to fix it. There are things that can be done to mitigate this risk, like using an ACME client which supports fallback between multiple CAs, but the vast majority of sites out there today simply aren't set up to handle that yet.
The point of the CA/BF settling on 47-day certs is yes, to strongly push automation, but also to still allow time for manual intervention when automation fails.
FWIW, we're acutely aware of the operational risks of super short lifetimes and frequent renewals. That's why our `shortlived` profile is clearly documented as only being appropriate for orgs that have high operational maturity and an oncall rotation. We carry pagers too, and if LE goes down for 48 hours, we'll be desperately trying not to take out a huge chunk of the Internet.
Yep! Should be available to the general public (as long as you're using an ACME client that can be configured to request a specific profile) later this week.
It's a good question! I know that our first root (ISRG Root X1) used that naming scheme simply because it was cross-signed by IdenTrust's root (DST Root CA X3) which used that same scheme. But where they got the scheme from, I don't know.
Using Y to denote the "next generation" of roots is a scheme I came up with in the past year while planning our YE/YR ceremony, so it's certainly not something that people were thinking about when they named the first roots.
Certificates that look like renewals -- for the same set of names, from the same account -- are exempt from rate limits. This means that renewing (for example) every 30 days instead of every 60 days will not cost any rate limit tokens or require any rate limit overrides.
Organizations with many frontends/loadbalancers all serving the same site tend to adopt one of four solutions:
- Have one node with its own ACME account. It controls key generation and certificate renewal, and then the new key+cert is copied to all nodes that need it. Some people don't like this solution because it means you're copying private keys around your infrastructure.
- Have one node with its own ACME account. The other nodes generate their own TLS keys, then provide a CSR to the central node and ask it to do the ACME renewal flow on their behalf. This means you're never copying keys around, but it means that central node needs to (essentially) be an ACME server of its own, which is a more complex process to run.
- Have one ACME account, but copy its account key to every node. Have each node be in charge of its own renewal, all using that shared account. This again requires copying private keys around (though this time its the ACME key and not the TLS key).
- Give every node its own ACME account, and have each node be in charge of its own renewal.
The last solution is arguably the easiest. None of the nodes have to care about any of the others. However, it might run into rate limits; for example, LE limits the number of new account registrations per IPv6 range, so if you spin up a bunch of nodes all at once, some of them might fail to register their new accounts. And if your organization is large enough, it might run into some of LE's other rate limits, like the raw certificates-per-domain limit. Any of the above solutions would run into that rate limit at the same time, but rate limit overrides are most easily granted on a per-account basis, so having all the nodes share one account is useful in that regard.
Another factor in the decision-making process is what challenge you're using. If you're using a DNS-based challenge, then any of these solutions work equally well (though you may prefer to use one of the centralized solutions so that your DNS API keys don't have to live on every individual node). If you're using an HTTP-based challenge, you might be required to use a centralized solution, if you can't control which of your frontends receives the HTTP request for the challenge token.
Anyway, all of that is a long-winded way to say "there's no particularly wrong or right answer". What you're doing right now makes sense for your scale, IMO.
"CT Logs" are Certificate Transparency Logs, which are cryptographically provable append-only data structures hosted by trusted operators. Every certificate issued is publicly logged in two or more CT Logs, so that browsers can ensure that CAs aren't lying about what certs they have or have not issued.
Reducing the lifetime of certificates increases the number of certificates that have to be issued, and therefore the number of certs that are logged to CT. This increases the cost to CT operators, which is unfortunate since the set of operators is currently very small.
However, a number of recent improvements (like static-ct-api and the upcoming Merkle Tree Certs) are making great strides in reducing the cost of operating a CT log, so we think that the ecosystem will be able to keep up with reductions in cert lifetime.
Please don't suggest pinning a publicly-trusted intermediate. The CA may change which intermediate they're using at any time for any reason with no warning, and then the app which pinned that intermediate is hosed.
It depends what intermediate you pin, but the CA can also choose to change the root certificate they use at any time like Let's Encrypt did in 2024 when the CA that signed their cross signed certificate stood to expire. Plus, depending on where you get your certificates from, the reseller certificate may already be an intermediate rather than its own root.
You should probably pin the highest certificate in the chain that's going to stay current for as long as possible. Or, if the goal is just "I don't want people snooping around in my app's traffic" rather than "I want to protect against a rogue CA being used to hijack my customers' traffic", reuse the private key in the CSR and pin that, it'll get the job done.
(Disclaimer: I am tech lead of Let's Encrypt software engineering)
I'm also concerned about LE being a single point of failure for the internet! I really wish there were other free and open CAs out there. Our goal is to encrypt the web, not to perpetuate ourselves.
That said, I'm not sure the line of reasoning here really holds up? There's a big difference between this three-hour outage and the multi-day outage that would be necessary to prevent certificate renewal, even with 6-day certs. And there's an even bigger difference between this sort of network disruption and the kind of compromise that would be necessary to take LE out permanently.
So while yes, I share your fear about the internet-wide impact of total Let's Encrypt collapse, I don't think that these situations are particularly analogous.
