Letsencrypt certificates will not allow Windows XP clients to connect to IIS

1

Problem
I noticed that when a letsencrypt issued certificate is installed on IIS, Windows XP clients (e.g. IE, wininet, winhttp using schannel) are unable to connect. I would like to emphasis that this does not just affect Windows XP users using IE but any application on Windows XP / Windows 2003 which uses Schannel (WinInet, WinHTTP, etc).

Analysis
SSL Labs: SSL Report: the following ciphers are offered:
letsencrypt certificate:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
Only ciphers with FS are offered.

When a certificate issued from any other CA is used, the ciphers are as following:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
Notice that ciphers without FS are offered.

Cause
The problem is not with the lack of support of SNI on Windows XP but with the certificate policy. The working certificates allow the following purposes:
Ensures the identity of a remote computer
Proves your identity to a remote computer
1.3.6.1.4.1.36305.6.1.2.2.1

letsencrypt certificate purpose:
Ensures the identity of a remote computer
2.23.140.1.2.1
1.3.6.1.4.1.44947.1.1.1

You will notice that the “Proves your identity to a remote computer” purpose is absent, supposedly blocked by the certificate chain for the letsencrypt issued certificate. As a result IIS will disable all non PF ciphers.

Solution
The issued certificate allows the “Proves your identity to a remote computer” enhanced key usage, however it seems that a certificate in the chain does block this purpose. Are there any plans to fix this?

2 Likes
2

WinXP does not support “SHA2” (notably SHA-256) certificate signatures
see MIcrosoft KB968730
Windows XP is EOL since July 2015 and will not receive updates and fixes.
SHA1 support deprecated by major browsers and they will indicate SHA1 signed certs as insecure in mid 2016

sorry, there is no way for WinXP and its Schannnel. If you still use Windows XP - use software that will support modern certificate signatures

And, not sure about behavior of the IIS, but taking nginx and apache - certificate does not affect anyhow cipher selection, it only proves the identity

3

@Lulu: Please do not spread false information if you have no clue what you are talking about.

4

“Proves your identity to a remote computer” is how windows displays certificates with a Client Authentication (1.3.6.1.5.5.7.3.2) Enhanced Key Usage field. This is not related to the cipher selection between client and server, or to the cipher suite the server offers.

Which version of Windows are you using on the IIS server? Did you take a look at tools like IIS Crypto, which should allow you to change the cipher suite being offered by the server?

5

I have created a new issue on Let’s Encrypt GitHub to clarify Windows XP support. I also found the likely problem why Windows XP doesn’t accept the Let’s Encrypt intermediate certificate. See https://github.com/letsencrypt/letsencrypt/issues/1660

EDIT: The Let’s Encrypt FAQ has been updated for the time being with “Most platforms that trust that root should trust Let’s Encrypt certs. One notable exception is Windows XP, which currently doesn’t accept our intermediate.”

All hope is not lost, Josh Aas was assigned to the issue and it may be possible to create a new compatible intermediate certificate.

3 Likes