Hi,
In the event that any Windows Server administrators encounter client errors after renewing their certificates against the new "generation Y" hierarchy, I've started to put together an article describing the potential problems and workarounds, specific to Windows:
The problem is not specific to Certify The Web, it's more around how Windows services typically use the built in windows chain building when talking TLS, and this can mean services like IIS will serve the new chain if the server trust store trusts the new [self-signed] roots.
If a client (curl, browsers etc) does not yet trust the new roots and has no alternative path building it may not be able to communicate with the service if the server elects to use the new chain. This is not configurable in IIS etc and using a "Preferred Chain" option will have no effect.
For services like Apache/nginx etc they will continue to work normally.
Currently this should only affect systems which renewing using Let's Encrypts tlsserver and shortlived profiles. Other systems will start to be affected in May when the 'classic' profile switches over.
6 Likes
As an aside, I should also add that if you are on Linux etc and your certificate is using the new chain to Root YR or Root YR (not the cross-signs to ISRG Root X1/X2), any clients with no independent path building will either trust the new roots or they won't.
So for those if you plan to issue using tlsserver or shortlived you probably either need to set your preferred chain or update your client trust stores.
Note the default chain provided by LE includes the cross-signs to X2 and X1
But, yes, if someone chose a shorter alternate chain they need to ensure all TLS clients' trust stores include at least one of the included roots.
I submitted a Feature Request to have the alternate Gen Y chains documented: Update Certificates Chains section for Gen Y Hierarchy
You can discover the chains by reviewing the ACME Client's API results. I mention this for others as I know you know how to do that @webprofusion 
Personally I would avoid relying on specific alternate chains until they are documented.
4 Likes
Thanks for sharing this. This mainly affects Windows servers that rely on the OS trust store, especially IIS, where the new Let’s Encrypt YE/YR roots may not yet be trusted by some clients. For now, using the older chain where possible or ensuring clients have updated root certificates seems to be the safest workaround. Apache/Nginx setups appear largely unaffected as you mentioned.