IIS 7.5 chain trust problem

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

My domain is: jandrozd.eu

I ran this command: https://www.ssllabs.com/ssltest/analyze.html?d=jandrozd.eu&hideResults=on

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

Hi @drozja,

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.

Have you checked whether anyone connecting has a client that’s known to be incompatible at https://letsencrypt.org/docs/certificate-compatibility/?

If the errors are from clients that are expected to be compatible, please post the exact errors messages that the browsers are displaying. Thanks!

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):

Android screenshot:

Note, its different url, but the same webserver and same certificate. I can see same issue for all domains included in certificate.

Device information: http://prntscr.com/jiq413

@schoen I think the devices should be compatible according to your list. More information above on screenshots.

Oh, thanks for this information.

If you look at

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.

1 Like

Ok @schoen I used zero ssl web client to obtain a certificate. Understood the point.

What can i do to get certificate signed by second (DST) intermediate?

It is already signed. You just have to use the DST-signed intermediate in your chain instead of the ISRG-signed one.

That file is available here:


(It should also have been available as a download from ZeroSSL, but maybe you didn’t notice it or it wasn’t clearly explained.)

If you put that file into your chain, I think the problems should go away!

@schoen Thank you very much! I removed ISRG intermediate from chain, restarted IIS and its working now! Thank you much for your effort!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.