I’m not too sure really. I suppose this is the reason Windows tends to use a different format (PFX) for distributing certificates with their proper paths between machines. I thought I knew both Windows and Linux, I’ve learned something new today. As far as I can see, Windows is planned to be supported by Let’s Encrypt automation but it isn’t yet. So further down the line when it is, this might be an issue for cross-platform people like me, if for example, one wanted to use the same certificate on both a Linux machine and a Windows machine. Hopefully once your root certificate is present in most browsers, this won’t be as much an issue. The language would probably need to be shortened but the long speak of it is:
When Windows encounters a certificate it cannot match up to an issuer in it’s trust store in a PEM format (commonly used with Linux), it will first check the extended properties for a download URL for the issuer. If the issuer is not in the trust store (checked via public key material), it will check the downloaded issuer’s certificate’s extended properties for another download URL, and so on, until either it reaches a root in it’s trust store, if not it reports an error. Only if the certificate does not include a download URL will it look further down a presented chain file for the rest of the certificate chain. In other words, it does the opposite of most modern web browsers.
This is NOT the case if it encounters a certificate in a Windows PFX format, it will ALWAYS use the full chain provided in the file first. Therefore you should always use a tool on Linux to export a certificate and chain into a PFX file before attempting to use (or indeed make sense of it) on Windows. EDIT: to the original poster I am sorry for hijacking this thread, in my defense it does still relate to times where a certificate might not appear trusted, even if it has morphed into a discussion in Windows 