Hello, I have problems with trust on some devices. For example, some Android devices and Windows Phone 8.1 do not trust my certificate. I installed all intermediates (2) and verified by SSL labs test. It seems IIS sends just one intermediate, ignoring the second. Can anyone help me to resolve this issue? I tried even to get a renewed certificate - did not help. It works on almost all browsers, except Safari on Mac OS X, some Chrome versions on Android and my Windows Phone 8.1
It produced this output: One path is correct, but IIS is not sending secondary path intermediate certificate. Both intermediates are imported to local computer account.
My web server is (include version): IIS 7.5
The operating system my web server runs on is (include version): Windows Server 2008 R2
Your chain is correct. The chain should not include the root certificate, which is not considered an “intermediate certificate”. Let’s Encrypt chains use only one intermediate certificate, not two.
If you send the root certificate to a device that already trusts it, it doesn’t give the device any new information.
If you send the root certificate to a device that doesn’t trust it, the device doesn’t believe it merely as a result of receiving it.
Unlike intermediate certificates, root certificates have to be preinstalled or else they have no effect.
So, SSL Labs is correct that your chain is already complete.
Hi @schoen Thanks for very fast reply. I do not want to include root in chain, I understand the process.
Here the screen of chain - from ssl labs test: http://prntscr.com/jipsa8 You can see there are two paths and second intermediate is marked with “extra download”. So far this is the only issue i was able to find with SSL test.
Strange is, that i had old X1 expired intermediate installed on the server and this caused chain problems elsewhere. I removed it, it worked fine and second day it stopped working on some mobile devices.
Below screenshot from my Windows Phone 8.1 (Edge) and also from Android device (one of my friends device):
you can see that there are two different versions of the Let’s Encrypt X3 intermediate certificate. One of them is issued by the ISRG root CA and the other is issued by the DST root CA (which is operated by IdenTrust).
Currently the ISRG root CA is relatively new and is not trusted by all browsers, while the DST (IdenTrust) root CA has been around for some time and is trusted by almost all browsers.
If you serve the ISRG-signed version of the intermediate, then you get guaranteed trust only in browsers that recognize that root. Confusingly, you may also get trust in some browsers that store copies of previously-seen intermediates and that happen to have a copy of the DST-signed version of the intermediate.
It looks like your site is at least sometimes serving the ISRG-signed Let’s Encrypt X3 intermediate rather than the DST-signed Let’s Encrypt X3 intermediate. This would account for most or all of the browser errors that you’re seeing.
Normally system administrators should never have to download any files from https://letsencrypt.org/certificates/, because Let’s Encrypt client applications can automatically give you the recommended intermediate certificate to use. For example in Certbot you would automatically get chain.pem and fullchain.pem which would contain the DST-signed Let’s Encrypt X3 intermediate, because that’s the one that sites are currently recommended to use! Other clients should have similar concepts and facilities.
