First of all, thank you to everyone at Let's Encrypt and ISRG for the enormous, ongoing work that keeps the CA running. We genuinely appreciate it.
I'd like to confirm my understanding of the Generation Y rollout and then ask whether a shorter chain is still obtainable. My understanding (please correct me if I'm wrong):
As of 2026/06/03, every ACME profile that issues server-authentication certificates (classic, tlsserver, shortlived) issues from the new "Generation Y" (YR/YE) or "ISRG Root X2".
As a result, the served chain is now 4 certificates deep, e.g., end-entity <- YR1 <- ISRG Root YR <- ISRG Root X1.
Consequently, --preferred-chain "ISRG Root X1" yields the 4-cert chain, because the only X1-anchored chain offered now routes through the cross-signed ISRG Root YR.
There is no longer an offered alternative of the form end-entity <- R13 <- ISRG Root X1.
Is the above correct?
My question / request:
Is there any ACME profile (or any --preferred-chain combination) that can still produce a 3-certificate chain anchored at ISRG Root X1, i.e., end-entity <- R13 <- ISRG Root X1 or end-entity <- E7 <- ISRG Root X1, without the addition of a cross-signed ISRG Root YR link — for server authentication use?
The reason I ask is that we operate a large fleet of IoT / embedded devices. They have strict TLS buffer limits and fixed trust stores, and they are highly sensitive to both handshake byte size and chain depth. The extra intermediate in the 4-cert chain pushes a non-trivial number of devices past their limits. In short, the longer chain risks breaking a large portion of already-deployed IoT systems that cannot easily be fixed remotely.
We completely understand and support the long-term goal behind the Generation Y transition. We're only hoping to learn whether a supported "short chain" option (anchored at the already-trusted X1) still exists, or is planned, for use cases like ours during the transition period.
(We're still investigating this on our side, but our current understanding is that switching to the ECDSA chain cross-signed by ISRG Root X2 might help, since it has smaller bytes. We'd welcome any correction here.)
Thank you very much for your time and, again, for everything you do.
if it's for buffer size using ECDSA would work: I think even X1-X2-root YE-YE1-leaf can be shorter than old x1-R13-leaf due to size being smaller:
btw you should consider days with small memory size for public key to be numbered, because post quantum algorithms are much, much larger (2KB per sig for mldsa-44)
Yes, ECDSA signatures are much smaller, and usually therefore faster too. If ISRG Root X2 is in your device's trust store, then that's a good choice if you need short handshakes.
It may also be that your use case is specialized enough that making your own private PKI rather than trying to use the public WebPKI would make more sense for you. The public WebPKI needs to adapt quickly to changes (post-quantum being what's in the news lately, but holes are starting to be poked in SHA-256, and who knows what the next round of cryptography might need to bring). At the very least, you should probably load a private root under your control into these device's trust store to use as a backup so you can always connect to reconfigure them regardless of what public CAs offer.
Thank you for the detailed and helpful answer! That fully clarifies the situation. We'll evaluate the ECDSA chain and also consider it for the longer term. Thanks again!
It occurred to me last night that if you're customizing the devices' trust stores anyway, you might want to add Root YE (and/or YR) to them. I think that the ACME servers offer an alternate chain rooted at them, and that'd lead to even smaller handshakes.
But whatever CAs you end up using (and there should be more than one, since a root might need to be replaced at any time), they will likely also be rotating their root every few years and so you'll need to stay apprised of the changes and ensure your devices' root stores are updated accordingly.
And also be aware the post-quantum encryption is on the way, and while you don't need to (and can't really) do anything about it yet, your devices may need to continue to be updated as changes happen in order to stay secure.