IIS 8.5 building incorrect chain with Lets Encrypt Authority X3

78

I was able to reproduce this issue in an AWS instance running Windows Server 2012 R2 and IIS 8.5, and I believe I may have a fix.

Steps to reproduce:

  • Configure IIS and install an old certificate issued from the X1 intermediate.
  • Run on another machine (replacing the IP address with the IP address of your IIS server):
$ openssl s_client -connect 50.18.147.177:443 -showcerts </dev/null 2>/dev/null | grep ' [si]:'
 0 s:/CN=ada679.le-test.hoffman-andrews.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Note that the issuer field of the end-entity certificate (the first one) matches the subject field of the issuer certificate (the second one).

  • Remove the old certificate, and install a new one issued from the X3 intermediate.
  • On another computer, run (again):
$ openssl s_client -connect 50.18.147.177:443 -showcerts </dev/null 2>/dev/null | grep ' [si]:'`
 0 s:/CN=ada679.le-test.hoffman-andrews.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Note that the new end-entity certificate has an Issuer field pointing to the X3 intermediate, but the certificate chain provided in the handshake offers only the X1 intermediate. This is a misconfiguration, and will cause the site to generate errors in some browsers (browsers with the X3 intermediate already cache may successfully load the site).

I tried running certutil -urlcache * delete in PowerShell on the Windows machine. As others have reported, this was insufficient to fix the misconfiguration.

Then I added a Certificates console to the Microsoft Management Console (MMC) following these instructions. When prompted to choose an account, I chose “My user account.” I then navigated within that console to “Console Root > Certificates (Local Computer) > Intermediate Certification Authorities > Certificates” (shown below).

You can see in the screenshot that “Let’s Encrypt Authority X1” was present there. I removed it. After that, runnning the OpenSSL command once more produced correct results:

$ openssl s_client -connect 50.18.147.177:443 -showcerts </dev/null 2>/dev/null | grep ' [si]:'
 0 s:/CN=ada679.le-test.hoffman-andrews.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Note that the issuer field of the end-entity certificate now matches the subject field of the intermediate certificate provided in the chain.

Please let me know if this fixes, or fails to fix, your problem. Note that since browsers may cache intermediates themselves, the most reliable test for the fix is an openssl command like the one above, or using SSL Server Test.

1 Like