1. Introduction

Mutual SSL authentication or certificate based mutual authentication refers to two parties authenticating each other through verifying the provided digital certificate so that both parties are assured of the others' identity. In technology terms, it refers to a client (web browser or client application) authenticating themselves to a server (website or server application) and that server also authenticating itself to the client through verifying the public key certificate/digital certificate issued by the trusted Certificate Authorities (CAs). Because authentication relies on digital certificates, certification authorities such as Verisign or Microsoft Certificate Server are an important part of the mutual authentication process. From a high-level point of view, the process of authenticating and establishing an encrypted channel using certificate-based mutual authentication involves the following steps:

A client requests access to a protected resource.

The server presents its certificate to the client.

The client verifies the server’s certificate.

If successful, the client sends its certificate to the server.

The server verifies the client’s credentials.

If successful, the server grants access to the protected resource requested by the client.

2. Background

Mutual SSL authentication works similar to SSL (Secure Socket Layer) authentication, with the addition of client authentication using digital signatures. Thus, SSL authentication and Mutual SSL authentication also informally known as 1-way SSL authentication and 2-way SSL authentication, respectively. As a developer, if you're interested in developing or be able to debug the mutual SSL authentication effectively, it can be very useful to understand the intricacies of the handshake messages happening under the hood.

2.1 SSL authentication (server --> client)

In SSL authentication, the client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. In this aspect, both client and server use 9 handshake messages to establish the encrypted channel prior to message exchanging.

2.2 Mutual SSL Authentication (server <--> client)

Whereas in mutual SSL authentication, both client and server authenticate each other through the digital certificate so that both parties are assured of the others' identity. In this aspect, both client and server use 12 handshake messages to establish the encrypted channel prior to message exchanging.

3. Capture and Analyze

To help readers better visualize what's happening under the hood, I've enhanced a code example taken from the Microsoft website so that both client and server are capable of authenticating each other using the mutual SSL authentication. The code sample is very simple, and I won't illustrate much here. Basically, what it does is the client application sends a "Hello from the client." message to the server and the server application replies with a "Hello from the server." message, right after the mutual SSL authentication is completed successfully.

To capture the handshake messages transacted between the client and server, I use one of the popular and open-source packet analyzer tools called WireShark. It is a powerful and easy to use packet capture and analyzer tool, which can captures messages over a hundred of protocols. To learn more about how you can make use of this tool, please visit its website.

However, due to the lack of supported Loopback Interface in Windows operating system, I've to setup the client and server application running on two different machines in order to use Wireshark to capture their handshake messages. The handshake messages captured while running the applications are shown in the screenshot below, and the IP address "10.5.3.28" and "10.5.3.18" in the Source or Destination columns represents "The Client" and "The Server", respectively.

For analysis and verifying purposes, the handshake messages that we're concerned about are summarized and listed below:

No.30, 31 and 32 are the TCP (Transmission Control Protocol) handshake messages.

Messages from No.81 onwards are application data messages exchange between the client and server.

4. Using the Code

The demo project included in this article, which is available for download at the top of this article, is intended to be run locally as opposed to the captured one shown above. This is because the certificates included in the demo project are generated for "localhost" use only. If you would like to try it out, please follow the steps outlined below to get it up and running on your workstation.

4.1 Install the Client and Server Certificate

Follow the steps outlined below to install the client and server certificates into the Windows certificate store:

Unzip the downloaded demo project anywhere on the file system.

Open a Snap-in window

Start -> Run -> Type mmc

Add/Remove Snap-in... (Ctrl-M)

Add a Certificates snap-in for ‘My user account’

Expand the (Trusted Root Certification Authorities)/Certificates node

Right click the Certificates folder and choose All Tasks – Import

Browse to the "Certificates" folder included in the demo project.

Import the "MyServer.cer" and click through the remaining windows and finish.

Repeat the step 4 and 5.

Import the "MyClient.cer" certificate and click through the remaining windows and finish.

Now, you should see the 2 imported certificates, which has the same details as the screenshot below (other irrelevant certificates are not shown here)

4.2 Build and Run the Solution

Open the "MutualSslDemo.sln" solution in Visual Studio.

Hit F5 to run the solution.

Now, you shall see similar results as the one shown below:

Of course, you can switch between the Mutual SSL authentication and SSL authentication behavior in the demo project (MyServer) by setting the argument "clientCertificateRequired" of the SslStream.AuthenticateAsServer function to true and false, respectively.

Share

About the Author

Elvin Cheng is currently living in Woodlands, Singapore. He has been developing applications with the .NET Framework, using C# and ASP.NET since October 2002. Elvin specializes in building Real-time monitoring and tracking information system for Semi-conductor manufacturing industry. During his spare time, he enjoys reading books, watching movie and gym.

Comments and Discussions

When two servers are exchanging messages using Mutual Auth, How many certificates needs to be purchased and setup? Is it 2? First cert purchased (after generating CSR) for the server and configured on the server. Second Certificate purchased for client and configured on client server

If I'm understanding this correctly, certificates are sent in the clear between the client and the server before the ChangeCipherSpec handshake message is used to start the encrypted session. If this is indeed the case, what stops a man-in-the-middle attack where a hacker intercepts the client's certificate as it is transmitted to the server? That byte stream could then be used to fake the client's identity by another system.

I'm working on using certificate-based mutual authentication now for a web portal, and it seems like the SSL handshake is fairly insecure for this. Is there another authentication protocol that sits on top of an already-established SSL session?

Thank you for Demo project,it is working fine in same machine but it won't be the real time scenario right?
Reason behind this problem is u have created server certificate with CN as localhost so it's working fine in same machine not in distributed.so i have decided to create certificate with CN with proper host name please guide me regarding how to create certificates such as cer,pfx,spc and pvk..
Need to establish client server communication using SSLStream.
I have created certificate using Makecert and used below link as a reference
http://www.codeproject.com/Tips/159604/SSL-MakeCert-pvk-pfx-Client-Server-Certificate-Gen.
After creation imported ca,server and client certificate to trust store still am getting exception as "The remote certificate is invalid according to the validation procedure." in server and client.

Hi,
Thanks for the wonderful code.
I tried to run the client code in one machine and server code in another machine. I used to generate two certificates from each machines to share with opponent. I run the appication. I am not able to establish a connection.

In the process of testing custom certificates (not installed to OS), I found it doesn't work for server side to use ServicePointManager.ServerCertificateValidationCallback to validate custom certs. If that is what you wanted, just use the SslStream constructor parameter (RemoteCertificateValidationCallback userCertificateValidationCallback) to specify your expected actions to be taken, just like client side.

Hi, thanks a lot about article. But i need to ask about TLS package on WireShark.
I use 2 computer with different ip address and run WireShark. But i can only see TCP package. In your image i can see TLSv1 package. Can you help me about this issue?
Thanks