Author: Kaushal Kumar Panday (kaushalp@microsoft.com)
SSL/TLS certificates are commonly used for both encryption and identification of the parties. In this blog post, I’ll be describing Client Certificate Authentication in brief.
Client Certificate Authentication is a mutual certificate based authentication, where the client provides its Client Certificate to the Server to prove its identity. This happens as a part of the SSL Handshake (it is optional).
Before we proceed further, we need to understand
Client Certificates |
Client Certificate is a digital certificate which confirms to the X.509 system. It is used by client systems to prove their identity to the remote server. Here is a simple way to identify where a certificate is a client certificate or not:
Below is a screenshot of a sample Client Certificate:
Refer RFC 5246
Authentication & Authorization |
In Computer Science, Authentication is a mechanism used to prove the identity of the parties involved in a communication. It verifies that “you are who you say you are“. Not to be confused with Authorization, which is to verify that “you are permitted to do what you are trying to do“.
There are several types of authentication. Here is a list of authentication widely used on IIS (in no specific order:(
NOTE: As the SSL Handshake happens before HTTP communication, Client Certificate Authentication takes the highest precedence over any other type of authentication that takes place over HTTP protocol. |
Kerberos, Client Certificate Authentication and Smart Card Authentication are examples for mutual authentication mechanisms. Authenticationis typically used for access control, where you want to restrict the access to known users. Authorization on the other hand is used to determine the access level/privileges granted to the users.
On Windows, a thread is the basic unit of execution. Any task performed by the user is executed by the thread under the context of a specific account/identity. Authentication is one of the ways used to determine the thread identity, whose privileges will be used by the thread for execution.
Client Certificate Authentication in SSL/TLS Handshake |
I have already discussed SSL Handshake in one of my blog posts. Browse to:
http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx
Here is a screenshot describing the SSL/TLS Handshake:
NOTE:
|
Design Problems |
We know that the server sends the list of Distinguished CA names as a part of SERVER HELLO. The RFC never mandates the list of Distinguished CA Names should contain Root CA or Intermediate CA certificates. Here is a snippet of this section defined in the RFC5246:
certificate_authorities
A list of the distinguished names [X501] of acceptable |
Refer the below blog post for information on Root & Intermediate CA certificates:
http://blogs.msdn.com/b/kaushal/archive/2013/01/10/self-signed-root-ca-and-intermediate-ca-certifica...
This can lead to a problem where few systems require Root CA‘s while few require Intermediate CA‘s to be present in the list sent in the SERVER HELLO. This makes the communicating parties incompatible on certain occasions.
Both the implementations are debatable. On one hand the list sent by the server cannot exceed a certain limit (on windows the size is 12,228 bytes). If exceeded, the auth will fail. The list of Intermediate CA’s always exceeds the list of Root CA by 2-3 folds or even higher. This is one of the reasons why some systems send the ROOT CA’s in the list of Distinguished CA Names. On the other hand, the Intermediate CA names are readily available in the client certificate provided by the user, so it makes it easier during the certificate chain validation, therefore some systems prefer this over the previous one. Both have their own merits.
One example I have personally encountered is Apple‘s Safari browser communicating to a site hosted on IIS 7 or higher which requires Client Certificate for authentication. Safari expects a list of Intermediate CA‘s in the SERVER HELLO. On the other hand, IIS sends only Root CA‘s in that list. As a result the authentication fails as the client is unable to provide a client certificate to the server.
A solution to the above problem is to configure IIS to not send any the CA list in the SERVER HELLO. To achieve this follow the Method 3 described in the support article below:
https://support.microsoft.com/en-us/kb/933430/
The above article requires you to add a registry key, SendTrustedIssuerList, which is set to 0.
As a result the server doesn’t send any list to the client, but requires it to pass a client certificate. The client will present the complete list of client certificates to choose from and it will proceed further as expected.
NOTE: In Windows Server 2012 and Windows 8, changes were made to the underlying authentication process so that:
Further read: https://technet.microsoft.com/en-in/library/hh831771.aspx |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.