The Setup

Server Setup

• Wild card server certificate is installed in IIS (server level). Wild card is required, because we’re using multiple host names are configured.

• The Certificate Authority is added to the Trusted Root Certification Authorities store (Local Machine)

• Website binding is configured to use https with the server certificate for SSL

• Website is configured to require SSL and to require client certificates

• Client certificate mapping is configured in order to map an individual client certificate to a specific Windows account. Configurable via this extension.
  

       This extension actually changes this configuration:

• An Allow authorization rule is configured for this Windows account

• Anonymous Authentication is enabled (Client Certificate is anonymous authentication)

• WCF service is configured for transport security

Client Setup

• The Certificate Authority is added to the Trusted Root Certification Authorities store (Local Machine)

• Client Certificate (containing private key) is added to the Personal certificate store (Local Machine).  This is required for the WCF client

• Client Certificate (containing private key) is added to the Personal certificate store (Current User).  This is required for browsing to the service via IE

• WCF Client is configured for transport security, providing Client Certificates:

Problem Solving

The issue

When browsing to the service, for a particular web server, we’re not prompted to select a client certificate. Instead, we get this exception:

The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web Server recognizes.

Troubleshooting

We configured another web server with exactly the same setup, which worked fine.  But still it didn’t work on that particular web server. Handy tools / commands during troubleshooting:

• netsh http show sslcert
• SSL Diagnostics

At the end, a warning in the System Event Log gave the solution. This entry is only written to the Event Log for the first call after the IIS service is restarted. That’s why we didn’t discover this Event Log warning earlier.

When asking for client authentication, this server sends a list of trusted certificate authorities to the client.  The client uses this list to choose a client certificate that is trusted by the server.  Currently, this server trusts so many certificate authorities that the list has grown too long.  This list has thus been truncated.

Root cause

During the handshake protocol for client certificate authorization, the server sends a list of Trusted Root Certification Authorities to the client.  The client will in this case only provide Client Certificates, issued by one of these Trusted Root Certification Authorities.  The problem was that the Trusted Root Certification Authorities list was too long on that particular server, so it was truncated before sent to the client.  Unluckily, our Root Certificate Authority was truncated from the list, so the handshake failed.

Solutions

There are two solutions to solve this issue:

• The first solution is to clean up the Trusted Root Certification Authorities store (Local Machine) and remove all unnecessary certificates. Be aware that you don’t remove certificates that are required by Windows.
• A second solution is to configure Schannel to no longer send the list of trusted root certification authorities during the TLS/SSL handshake process.  This can be done by adding this registry entry on the web server

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL

Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False)

Result

When browsing to the service, we’re now promoted for our Client Certificate. Now we can access the service: