I have a site that has been bound to a new SSL certificate with SAN (4 additional names). The certificate has a 2048-bit key.
The problem is that it works on some browser/OS combinations but not on others.
- IE7 / Win XP - fail
- IE6 / Win 2003 - fail
- IE8 / Win XP / Corporate proxy - OK
- IE8 / Win 7 / OTHER Corporate proxy - fail
- IE9/10 / Win 7 - OK
- Chrome / Win 7 - OK
- Firefox / Win 7 - OK
- Chrome / Android - OK
Note: The two corporate proxies are very different organisations, in two separate countries.
I have installed Fiddler on the IE6 / Win 2003 (2nd on the list) and have captured this from the Inspectors\Raw tab:
IE6:
CONNECT sorry.site.not.disclosed:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM; .NET4.0C; .NET4.0E)
Host: sorry.site.not.disclosed
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
A SSLv2-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Major Version: 2
Minor Version: 0
Random: EA AE EB C5 20 0C 46 90 7F C1 E0 EE 47 BE 05 63
SessionID: empty
Ciphers:
[10080] SSL2_RC4_128_WITH_MD5
[700C0] SSL2_DES_192_EDE3_WITH_MD5
[30080] SSL2_RC2_128_WITH_MD5
[60040] SSL2_DES_64_WITH_MD5
[20080] SSL2_RC4_128_EXPORT40_WITH_MD5
[40080] SSL2_RC2_128_EXPORT40_WITH_MD5
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Compression:
(not specified)
Extensions:
none
Chrome:
CONNECT sorry.site.not.disclosed:443 HTTP/1.1
Host: sorry.site.not.disclosed
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Major Version: 3
Minor Version: 2
Random: 51 4A 0D 68 FE C4 50 A9 26 43 9E 1A C2 E9 05 5C FE 5F CF 37 4D 20 96 FF 0E 2F 5E EB 16 C1 F2 20
SessionID: empty
Ciphers:
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0088] TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
[0087] TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[C00F] TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
[0084] TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
[0035] TLS_RSA_AES_256_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0045] TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
[0044] TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
[0066] TLS_DHE_DSS_WITH_RC4_128_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[C00C] TLS_ECDH_RSA_WITH_RC4_128_SHA
[C00E] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
[0096] TLS_RSA_WITH_SEED_CBC_SHA
[0041] TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[002F] TLS_RSA_AES_128_SHA
[C012] TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[C00D] TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
[FEFF] SSL_RSA_FIPS_WITH_3DES_EDE_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Extensions:
server_name sorry.site.not.disclosed
renegotiation_info 00
elliptic_curves 00 06 00 17 00 18 00 19
ec_point_formats 01 00
SessionTicket TLS empty
NextProtocolNegotiation empty
channel_id(GoogleDraft) empty
status_request 01 00 00 00 00
When testing using SSLLabs, e.g. https://www.ssllabs.com/ssltest/analyze.html?d=mail.google.com
The site shows ONLY two options under cipher suites, and supports only TLS 1.0:
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 No
SSL 2.0 No
Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA)
I have contacted Verisign (Australia) and the chap claims that all Verisign certificates support SSLv1, v2, v3, TLS.
So why does the IIS server not present it? Using a SELF-SIGNED wildcard certificate, I was able to get the same IIS server to report on SSLLabs:
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0 INSECURE Yes
Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) 256
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
SSL_DES_192_EDE3_CBC_WITH_MD5 (0x700c0) 168
SSL_RC4_128_WITH_MD5 (0x10080) 128
Where to look next?
On all Windows 2008 R2 servers that I've seen ssl v2 has been enabled by default and I've had to go and disable it myself. Doing so (disabling it) hasn't seemed to break IE6... obviously the machine has been hardened by someone
Qualys has a very decent online SSL scanner that will tell you exactly what protocols and even cipher suites you have enabled, and if there are any other cert errors and what renegotiation is allowed - https://www.ssllabs.com/ssltest/ - perhaps an overly limited combination of ciphers and protocols has been chosen.
When you say it fails - what do you mean? That there is a certificate error? Is the root CA trusted on the older client machines?
It is possible in IE to disable SSL v3 and other protocols, on those machines throwing errors, check in Tools / Internet Options / Advanced tab and see if SSL 3 and TLS 1 is checked.
Check the values of the following reg keys
see http://support.microsoft.com/kb/977377 and http://support.microsoft.com/kb/980436