Request inclusion of `Root YR` and `Root YE` for Windows platforms

Feature Requests
1

Kindly request inclusion of Root YR and Root YE for Windows platforms.
This allows Microsoft Edge to display abbreviated certificate chain paths.

2

I believe they're in the process of requesting inclusion in all the major trust stores, yes.

Why would that… matter?

Like, if you knew all your users were using the Microsoft trust store you could configure your server to not send as many cross-signs. There are definitely advantages to new roots being distributed widely. I just wouldn't have had a short display of chain paths from someone looking at it in Edge on my list.

3

As you mentioned, browsers can ultimately build a complete trust chain through cross-signing with the legacy Let’s Encrypt root certificate. I put forward this suggestion merely to ensure certificates issued under YR and YE display more favorably in Microsoft Edge.

Furthermore, Firefox and Chrome have already implemented a 15-year sunset policy for legacy TLS root certificates. It remains uncertain whether Microsoft will follow this approach. Should Microsoft adopt comparable rules, this year will represent the optimal window for YR and YE to be included in Microsoft’s root certificate program.

4

You don't need to remind Let's Encrypt about the Microsoft root program :slight_smile:

They are well aware and have said a number of times they will be submitting these new roots to various stores. I am not expert in that timeline but my understanding is that can take many months or even a year or more from start to finish.

From their blog: New "Generation Y" Hierarchy of Root and Intermediate Certificates - Let's Encrypt

We’ll be submitting the new roots for inclusion in the Apple, Chrome, Microsoft, Mozilla, and other root programs shortly thereafter. We look forward to updating you again when the new hierarchy is officially included in those trust stores!

You could also view the API category in this forum. There are several posts about the Y hierarchy. See: API Announcements - Let's Encrypt Community Support

5

As an aside, a fun potential side effect to watch out for is on windows servers talking to non-windows-native clients.

Servers like IIS use current trust chains rather than relying solely on a pre-configured chain. If your server trusts the new roots in preference to the old ones (e.g. disable the old ones) then the automatically built chain for serving via TLS will use the new roots rather than the cross-sign (the default).

If the client requesting from that server doesn't yet trust the new roots and can't auto build a path via the cross-sign (windows native schannel based clients generally can) then the cert will be untrusted.

6

@webprofusion Good reminder and perhaps I am taking this a bit off-topic but ...

Won't it have to become standard practice for IIS admins to configure their systems to send longer chains? I mean the Chrome root store is now encouraging root rotation every 5 years (see here)

Public CA can't readily ignore what Chrome store requires so longer chains linking to very fresh roots will become more common. At least how I see it. What do you think?

7

It's handled by windows (schannel) internally, IIS admins generally don't configure anything other than set the certificate to use and possibly update their TLS protocols/cipher suites. Windows does serve the longer chain by default (in this case, either by design or by quirk) so you'd have to go out of your way to limit that. That may or may not be where this thread was originally headed.

8

Regarding Windows Server and Schannel (IIS, Kestrel etc.), I'm currently using the following approach, which I believe should allow to serve longer chains (using cross-signed roots) as long as possible to maximize compatibility with clients, and which I think should not have negative effects (trust issues) on outbound connections:

  • Whenever Let's Encrypt issues new Roots or is about to start issuing from them (e.g. Root YR/YE in 2025, Root ZR/ZE in 2030, Root AR/AE (?) in 2035, ...):
    • Import/add the cross-signed root (eg. Root YR/YE, also X2) to the Intermediate Certification Authorities folder in the LocalMachine trust store (Powershell Path: Cert:\LocalMachine\CA).
      (Also, import/add new cross-signed roots for the previous root generation which LE issues, so that they can continue to be used after the 7 year validity period of the original cross-signed roots expires.)
    • Import/add the self-signed root (eg. Root YR/YE) to the Untrusted Certificates folder in the LocalMachine trust store (Powershell Path: Cert:\LocalMachine\Disallowed\).
  • Whenever a cross-signed root is about to expire without a replacement (e.g. ISRG Root X2 in 2032, ISRG Root YR/YE in 2037, Root ZR/ZE in 2042, ...):
    • Remove the corresponding self-signed root from the Untrusted Certificates folder (Powershell Path: Cert:\LocalMachine\Disallowed\).

By adding the self-signed root to the untrusted folder, it will prevent Windows (Schannel) from using that root to build a certificate chain, even after that root becomes available and is distributed into the Windows Root CA store (until it is removed again from the untrusted folder).
At the same time, by adding the cross-signed root to the intermediate folder, it will allow Windows to use that for building the chain, not only for serving the certifcate to clients, but also when making outbound (client) connections to servers that already serve the shorter chain (like https://valid.ye.test-certs.letsencrypt.org/).

With this approach, the path to the YE intermediates should currently look like this in the server, even when the new Root YE/YR are added to the trusted root store in the meanwhile, and so should also server these intermediates to the client:
path-to--ye1

(For example, when I manually added the self-signed Root YE to the trusted roots store for testing purposes, Windows used it to build chains for YE1/YE2/YE3, even though the cross-signed Root YE was present in the intermediate CA store, and so IIS would also serve the shorter chain. However, e.g. for ISRG Root X2, it would use the cross-signed root, even though the self-signed was in the trusted roots store.

This is also mentioned here: Let's Encrypt YE/YR Roots on Windows | Certify The Web Docs

9

Yes I wrote that document (I should probably review it again). This is one of the techniques I was alluding to, the other is to uncheck it's enabled Certificate Purposes. However that's only if you want to force the short chain to be served, which also reduces compatibility with clients that don't yet trust those roots.

Windows can be pretty dynamic as it will get updates, store trusted intermediates it encounters etc, however these can be disabled, http can be blocked etc and that can culminate in preventing otherwise automatic root/intermediate trust.