submit an ISRG Root X3 allowlist form for those wanting to upgrade their RSA issuance.
Currently, the root ISRG Root X2 is for full ECDSA issuance.
We should have a RSA root (ISRG Root X3) that does not rely on an expired root certificate (DST Root CA X3).
Currently, RSA issuance is broken because the root certificate DST Root CA X3 has expired.
In a few previous OpenSSL/LibreSSL implementations, it was resulting in TLS failures, so it still results in TLS failure if the end-user or devops engineer has not updated his SSL/TLS libraries.
I think proprietary SSL/TLS implementations (such as the ones of Microsoft) still reject a TLS certificate if the root certificate has expired / is not trustworthy. And they would also have handshake failures on a ECDSA certificate as they don't support ECDSA ciphers. Correct me if I'm wrong.
I seriously advocate for an ISRG Root X3 RSA certificate cross-signed by ISRG Root X1.
Given that there's already a self-signed ISRG Root X1, what would be the purpose of having an ISRG Root X3 cross-signed by ISRG Root X1? Such an ISRG Root X3 would require that either the self-signed ISRG Root X1 or the cross-signed ISRG Root X1 be in the user's trust store, which effectively causes ISRG Root X3 to simply extend the chain with no real benefit.
There is already an alternate signing chain provided by the Letsencrypt CA for those TLS client implementations that do not handle correctly if an intermediate certificate is signed by the expired DST Root CA X3.
It’s an unfortunate circumstance that some implementations (incorrectly) fail when presented with the zombie-signed X1-by-DSTX3. A compliant path building algorithm should recognize the intermediate (R3/R4/E1/E2) is signed by the X1 root which it has to trust.
If it doesn’t trust X1 or the zombie-sign, then that’s a different problem and let’s encrypt will not be trusted.
Most systems now trust X1 directly unless they’re not updated in years (most often a problem with old android). As a server operator you can use the alternate chain to omit the DST zombie-sign if you don’t need it.
The zombie-sign itself is going to expire at some point, at which point this will be simplified: Either you trust X1 or you don’t.
The browsers are pushing for shorter-lived roots so we’ll probably have to make a new root cross-signed by X1 for them soon too, which means a new set of short-or-long chain options, with X1 being the longer chain.
That is automatic for the RSA certificates selecting the alternate chain. Does selecting the alternate chain work the same way for the ECDSA certificates?
I don’t know offhand actually which chains are default and available as alternates. One of the reasons the ecdsa is still not GA is figuring out what chains are available for certs issued from it.
What's wrong with the short chain which ends in the non-cross-signed ISRG Root X1? In essence, your proposed ISRG Root X3 is technically exactly the same as ISRG Root X1: it does not have any added benefit.
Can you share some details on this? Will this affect existing root certificates, or only new ones?
The Mozilla trust store contains roots with enddates as far as 2046, so it will take many years for a shorter-lifetime policy to come in full effect, unless existing ones will be limited, too.
The Mozilla and possibly Chrome are planning to shorten the lifetime of existing root certs by distrusting them before they expire (and in many cases, the expiry date on a root isn’t actually enforced - the zombie-signed X1 root is an example of that!)
Here’s the discussion from Mozilla. I believe the current plan is to limit roots to 15 years. Chrome's root program has suggested even shorter timelines.
So in practice that would mean many CA's will have to issue new roots to satisfy upcoming CA/B requirements, but they can keep a cross-sign from "deprecated but widely trusted" roots to retain compatibility with older clients? That is, longer chains will become the norm?
