I recently noticed that you've introduced new profile selection (detailed here: Announcing Certificate Profile Selection - Let's Encrypt) as part of moving towards requiring "single-purpose" issuance hierarchies. It seems that more significant changes have also been made to Pebble (see PR #472).
Our application relies on certificates that include both the Server Authentication and Client Authentication EKUs. Does this move toward single-purpose hierarchies mean you’ll no longer issue certificates containing both EKUs? Are there any plans on removing the classic profile in the future? If so, are there any recommended mitigations?
And Let's Encrypt needs to abide to these root programs as well. Otherwise the browsers might decide to untrust the Let's Encrypt root certificate(s).
If the root programs indeed require a completely different issuance hierarchy, this might not be something Let's Encrypt is willing to facilitate. Also, the Chromium blog about this also mentions that client authentication is best done using a private CA instead of a public one, so I'm pretty sure Let's Encrypt won't go there.
So for now I guess you're safe, but you should plan for future, inevitable changes in the requirements in certificate root stores.
Note that it might be that root certificate stores will choose a "natural" change over due to the expiry of root certificates instead of forcing CAs in some way. I.e., if a new root CA needs to be included the new root might not be able to facilitate the client auth EKU, but the older root should be able to do that for some time on, as usually there is significant overlap in older/newer roots.
We are currently working on finalizing plans an announcements, which should be up in March.
But we will be announcing an approximately 1-year deprecation notice for the client authentication EKU to be compliant with Chrome’s June 2026 deadline.
If your application relies on the client authentication EKU, you should begin migrating.
Other CAs may still offer combined client/server certificates from roots that aren’t trusted by Chrome, but you’ll have to ask them for their plans. Private PKIs are an option, especially for client certs. I’m not in a position to know what’s best for your application.
Also wouldn't shock me if other CAs eventually offered both client and server certificates, just as separate certificates from separate roots. It's still pretty early; Let's Encrypt is more up front about their future plans than most other CAs seem to be.
I just want to clarify something from @mcpherrinm's post above:
Chrome has set a deadline of June 2026 for compliance with their policy. Expect ALL publicly trusted CAs to follow suit. You will either have to migrate your application to comply with this change by that date OR you will have to migrate your application to use non-publicly trusted certs. Chrome is currently responsible for about 2/3 of web traffic, so the odds of CAs not complying with this change are near zero.
It's possible, but I would think free CAs won't do that. Why would they? Client authentication is best done with a private CA, why invest a lot of money into something that's neither recommended nor your core business.
Commercial CAs? Well, that's a different story altogether I'd say. They'd sell anything, even if it's not recommended.
Can you perhaps shed some light on something I'm wondering? I don't see any deadline in the linked Chromium page (Moving Forward, Together), so I'm curious: what is required to be compliant with the Chrome root store? Does that also include intermediates or just the end leaf certificates?
