Knowledge Base

There are cases where a Microsoft IIS and other Windows-based TLS servers will provide a certificate chain that is only trusted by updated clients.

 

These servers do not have the ability to specify specific certificate chains to provide during the TLS handshake.

 

These Windows servers will make their own determination of the certificate chain to serve, based on the trust-store of the server itself.

 

In most cases, this trust-store is fully updated and therefore the server will not consider older clients - even when a CA has cross-certificates that provide trust for millions of older or legacy clients.

 

As all public CAs are required to move to single-purpose hierarchies, and rotate root certificates more frequently - cross-certification is vital, but unfortunately IIS servers make this difficult to support.

 

While this should be considered a bug, Microsoft seem to believe this is by design, and offer workarounds on their KB:

 

https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails

 

The fix is to move the newer Sectigo R46 and E46 roots into the servers 'Disallowed' store or to disable those roots entirely. They even suggest disabling the Windows Automatic Root Updates.

 

We have created .reg files that can be simply executed on the server to move the roots to the 'Disallowed' store and fix the problem.

There is also a .reg file that will restore the roots if needed.

 

Applying these .reg files, or following the Microsoft-provided instructions will force the IIS server to provide a certificate path in the TLS handshake that will work for all clients and browsers, not just those that have recently updated (cross-certs from the newer Sectigo R/E46 roots to the older USERTrust RSA and ECC roots will be used).