if we left cross sign cert alone and create a new 90-day certificate in August, than in DST-cert's view it's a leaf certificate that with lifetime extends after CA's expire date. I'm not sure if that's allowed? I look though CA/B BR but cannot find rule that forbid this, but it still makes me worry.
I noticed the other day that the cross-signed ISRG Root X2 is listed as an Intermediate certificate (for obvious reasons):
Additionally, the self-signed ISRG Root X2 just dropped out of space (no logged at date):
Well, even once the ACME server stops serving the DST Root X3 chain to clients, one could still configure one's web server to serve the R3-signed-by-DST intermediate to users. I think that browsers will just not accept such a chain after the R3-signed-by-DST expiration, so I don't think there's actually a problem from a compliance perspective.
Hm, did I miss the announcement?
Yep... R3 is a go!
Remember that all conversations about the expiration of DST Root CA X3 (and therefore the expiration of our X3 and R3 cross-signed intermediates) are really conversations about the upcoming Chain Switch, not conversations about the switch from X3 to R3. If we had not done this changeover today, all the same issues regarding expiration in mid-late 2021 would still exist with X3, so it's an orthogonal issue. We do plan to change our default chain on Jan 11th, and disallow issuance from the cross-signed R3 entirely in early summer. But please keep conversations about those events (and their necessity) to other threads, so that this one can remain clear and concise for folks who have questions about today's X3-to-R3 switch.
The specifics of the confusion (from which this very topic came) can be found here:
Ah, Discourse didn't give any hint of new posts in that topic. I guess the API announcement section is regarded as a regular section and I should have manually selected notifications on new posts...
Also, I'm wondering how many clients are out there with a hardcoded intermediate now setting a broken chain. No new threads up till now about that..
We're wondering the same thing! That's one reason for the announcement thread: so that someone whose site seems to be broken by this change can see the announcement and our explanation of exactly this failure mode there.
But we're also spot-checking domains which have renewed their certs since this changeover to see if they've properly updated their full chain, and trying to identify commonalities (acme clients, hosting providers, etc) between any such domains.
So now that R3 is live in production (hooray!), I still don't see any changes in staging. (Or at least, a staging certificate that I just issued and one I tried a couple weeks ago are both signed by the same "Fake LE Intermediate X1".) Is there still a change expected in staging relating to this change?
This guess of mine was apparently wrong, as the CPS section 7.1 still says that the CN of intermediates will be
Let's Encrypt Authority X<n>. Is this a problem, or is that part of the CPS not actually authoritative but just describing the initial intermediates and not necessarily all active intermediates?
We decided not to change the staging certificate yet. We will probably sign a new root and intermediates for staging tests when we start testing our multi-issuer support (rsa and ecdsa roots), but that is still a while away.
Good catch! I'll make sure we get that updated.
Don't forget the part about OCSP URIs in the intermediates, as they are gone for R3/R4 and E1/E2 as far as I remember.
Hello. Sorry for my noob question.
Is there any chance for the new certificate (R3) to support the old (X3) intermediate cert? Maybe somehow via alternate URL or something like that? We have a problem with some of our clients who hardcoded the certificates issuer footprint on their end, so they now can't establish a connection with the new certificates.
No, that's not really how it works. Any system getting a new certificate needs to also download the intermediate that it was signed with and configure the server to serve it alongside the certificate. Anyone who is trying to validate that a certificate is actually signed by Let's Encrypt needs to check the full certificate chain and validate it against a root certificate, not any specific intermediate certificate. While they did just change the intermediate for the first time in a long while, it could have changed at any point and can change again at any point (such as if the disaster-recovery intermediates start getting used).
If you really need to track the intermediates for some reason (which I guess maybe some DANE implementations do?) then you need to subscribe to the API Announcements to get notified about upcoming new intermediates so you can be proactive about adding them to your system. But there are several that could be used so you'd need to be prepared for certificates that are signed by any of them.
Thanks for the clarification.
That was an unfortunate and ill-considered design then.
And while I just gave this advice, it might not have actually given people much time to prepare. There was a notification on the blog on Sept. 17, but the only notice on the API Announcements category said that it might happen as soon as that day. So it may be that if you want to learn of new intermediates with enough time to add them to your systems that you need to watch both the API Announcements and the blog, though I don't see any good way to get notified of new blog posts (though one might be able to easily integrate with the RSS feed of it somehow).
For intermediate changes in particular, you should not hardcode the intermediate to use, but should use the
Link: rel="up"header from the ACME protocol, since intermediates are likely to change.
when I first wrote a client several years ago, very very very few clients implemented this. i don't think certbot did this for quite some time either.