On a Windows 2003 SP2 server I could not open the https://zoek.officielebekendmakingen.nl website, although telnet to the url on port 443 succeeded.
All I got was this lousy error:
Checking the obvious, no proxyserver enabled, TLS/SSL protocols enabled and also the steps mentioned in http://support.microsoft.com/kb/956196 gave no solution.
Debugging / sniffing / monitoring showed correct SYN-SYNACK-ACK handshake to the webserver but SSL session handshake failed. Okay, so there must be something wrong with certificates.
On a working system you can see the certificate being all okay:
Okay, so let’s export the root certificate and verify it on the failing server:
This certificate has an nonvalid digital signature and The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered.
I highlighted the interesting part: Signature algorithm….. On the working client it shows sha256RSA and the failing client 1.2.840.113518.104.22.168.
Let’s ask mr. Microsoft what this OID is: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381133(v=vs.85).aspx (CRYPT_ALGORITHM_IDENTIFIER structure).
szOID_RSA_SHA256RSA and that’s sha256 with RSA encryption, just like the working server can tell us. But why can’t the failing server validate this certificate based on a sha256RSA (SHA2) hash algorithm?
Here’s where the following MSKBs come to the rescue:
http://support.microsoft.com/kb/968730 - Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption.
http://support.microsoft.com/kb/938397 - Applications that use the Cryptography API cannot validate an X.509 certificate in Windows Server 2003.
In Microsoft Windows Server 2003, applications that use the Cryptography API (CAPI) cannot validate an X.509 certificate. This problem occurs if the certificate is secured by the Secure Hash Algorithm 2 (SHA2) family of hashing algorithms. Applications may not work as expected if they require the SHA2 family of hashing algorithms.
Additionally, when you evaluate a certificate that uses the SHA2 family of hashing algorithms, you may receive the following message:
This problem occurs because the Cryptography API 2 (CAPI2) in Windows Server 2003 does not support the SHA2 family of hashing algorithms. CAPI2 is the part of the Cryptography API that handles certificates.
To add support for SHA2 you need the above hotfix 968730 and (obviously) add the missing rootCA certificates in the trusted certificate store, after reboot the server can use the SHA2 certificate and access the website.
*pfew* that was a toughie.
Some more background information can be found in the Windows PKI Blog post “SHA2 and Windows”: http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx
If you have hotfix KB968730 installed and apply KB2641690 (crypt32.dll update) it seems to break SHA2 support, re-applying KB968730 seems to fix it.