Click here to Skip to main content
15,860,972 members
Articles / Web Development / IIS

An Introduction to Mutual SSL Authentication

Rate me:
Please Sign up or sign in to vote.
4.79/5 (40 votes)
8 Feb 2012CPOL7 min read 719.2K   15.7K   94   38
Provides a brief introduction to mutual SSL authentication and its handshake messages
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. This article looks at SSL authentication (server --> client), Mutual SSL Authentication (server client), and has a demo project to help explain the theory.

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:

  1. A client requests access to a protected resource.
  2. The server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client’s credentials.
  6. If successful, the server grants access to the protected resource requested by the client.

Mutual SSL Authentication - Click to enlarge image

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.

  1. Client sends ClientHello message proposing SSL options.
  2. Server responds with ServerHello message selecting the SSL options.
  3. Server sends Certificate message, which contains the server's certificate.
  4. Server concludes its part of the negotiation with ServerHelloDone message.
  5. Client sends session key information (encrypted with server's public key) in ClientKeyExchange message.
  6. Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
  7. Client sends Finished message to let the server check the newly activated options.
  8. Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
  9. Server sends Finished message to let the client check the newly activated options.

SSL authentication handshake messages

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.

  1. Client sends ClientHello message proposing SSL options.
  2. Server responds with ServerHello message selecting the SSL options.
  3. Server sends Certificate message, which contains the server's certificate.
  4. Server requests client's certificate in CertificateRequest message, so that the connection can be mutually authenticated.
  5. Server concludes its part of the negotiation with ServerHelloDone message.
  6. Client responds with Certificate message, which contains the client's certificate.
  7. Client sends session key information (encrypted with server's public key) in ClientKeyExchange message.
  8. Client sends a CertificateVerify message to let the server know it owns the sent certificate.
  9. Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
  10. Client sends Finished message to let the server check the newly activated options.
  11. Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
  12. Server sends Finished message to let the client check the newly activated options.

Mutual SSL authentication handshake messages

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.

Mutual SSL handshake messages - Click to enlarge image

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.

No.33 - Corresponding to Section 2.2 - Item 1.

No.35 - It contains 4 messages, which are:

  • Server Hello - corresponding to Section 2.2 - Item 2.
  • Certificate - corresponding to Section 2.2 - Item 3.
  • Certificate Request - corresponding to Section 2.2 - Item 4.
  • Server Hello Done - corresponding to Section 2.2 - Item 5.

No.38 - It contains 5 messages, which are

  • Certificate - corresponding to Section 2.2 - Item 6.
  • Client Key Exchange - corresponding to Section 2.2 - Item 7.
  • Certificate Verify - corresponding to Section 2.2 - Item 8.
  • Change Cipher Spec - corresponding to Section 2.2 - Item 9.
  • Encrypted Handshake Message - corresponding to the Finish message listed in Section 2.2 - Item 10.

No.41 - It contains 2 messages, which are

  • Change Cipher Spec - corresponding to Section 2.2 - Item 11.
  • Encrypted Handshake Message - corresponding to the Finish message listed in Section 2.2 - Item 12.

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:

  1. Unzip the downloaded demo project anywhere on the file system.
  2. Open a Snap-in window
    • Start -> Run -> Type mmc
    • Add/Remove Snap-in... (Ctrl-M)
    • Add a Certificates snap-in for ‘My user account’
  3. Expand the (Trusted Root Certification Authorities)/Certificates node
  4. Right click the Certificates folder and choose All Tasks – Import
  5. Browse to the "Certificates" folder included in the demo project.
  6. Import the "MyServer.cer" and click through the remaining windows and finish.
  7. Repeat the step 4 and 5.
  8. Import the "MyClient.cer" certificate and click through the remaining windows and finish.
  9. Now, you should see the 2 imported certificates, which has the same details as the screenshot below (other irrelevant certificates are not shown here)

Certificate Store - Click to enlarge image

4.2 Build and Run the Solution

  1. Open the "MutualSslDemo.sln" solution in Visual Studio.
  2. Hit F5 to run the solution.
  3. Now, you shall see similar results as the one shown below:

SSL client and SSL server

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.

C#
// Mutual SSL authentication (requires client certificate)
   sslStream.AuthenticateAsServer(certificate, true, SslProtocols.Default, true);
// SSL authentication only (do not require client certificate)
   sslStream.AuthenticateAsServer(certificate, false, SslProtocols.Default, true);

History

  • 6th February, 2012: Initial version

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Singapore Singapore
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

 
Questioncentrilize ssl Pin
Member 392143615-Aug-18 9:55
Member 392143615-Aug-18 9:55 
GeneralMy vote of 5 Pin
Member 43208443-Nov-16 6:56
Member 43208443-Nov-16 6:56 
QuestionNot able to download the sample code Pin
Pravin.bgholap1026-Jul-16 1:06
Pravin.bgholap1026-Jul-16 1:06 
QuestionWebservice Pin
Member 1183710219-Nov-15 8:10
Member 1183710219-Nov-15 8:10 
QuestionIOException in MyClient.ReadMessage Pin
SgtWingHead7-Oct-15 21:23
SgtWingHead7-Oct-15 21:23 
GeneralMy vote of 5 Pin
Member 1161612519-May-15 4:17
Member 1161612519-May-15 4:17 
QuestionTLS *Optional* Mutual Authentication Pin
Member 1163860623-Apr-15 23:14
Member 1163860623-Apr-15 23:14 
QuestionNumber of certificates to be purchased. Pin
Kumara5-Jan-15 7:22
Kumara5-Jan-15 7:22 
QuestionCertificates are sent in the clear? Pin
Shopko29-Dec-14 12:55
Shopko29-Dec-14 12:55 
AnswerRe: Certificates are sent in the clear? Pin
Byron Jones22-Jul-15 18:01
Byron Jones22-Jul-15 18:01 
GeneralRe: Certificates are sent in the clear? Pin
Shopko23-Jul-15 8:01
Shopko23-Jul-15 8:01 
QuestionHow you have created certificate for demo project? Pin
Member 1126144125-Nov-14 1:55
Member 1126144125-Nov-14 1:55 
QuestionFacing Issues when establishing a connection in remote server Pin
Member 1121376320-Nov-14 19:11
Member 1121376320-Nov-14 19:11 
AnswerRe: Facing Issues when establishing a connection in remote server Pin
Member 1108166220-Nov-14 19:16
Member 1108166220-Nov-14 19:16 
QuestionSSPI error Pin
iuuyu27-Oct-14 21:50
iuuyu27-Oct-14 21:50 
BugServer shouldn't use ServicePointManager.ServerCertificateValidationCallback, it won't work Pin
deerchao9-Sep-14 23:40
deerchao9-Sep-14 23:40 
QuestionPermission to use graphics only Pin
Melissa West26-Aug-14 5:48
Melissa West26-Aug-14 5:48 
QuestionCant see TLSv1 package on WireShark Pin
afumetto28-Jan-14 22:47
afumetto28-Jan-14 22:47 
AnswerRe: Cant see TLSv1 package on WireShark Pin
afumetto28-Jan-14 23:26
afumetto28-Jan-14 23:26 
QuestionQuestion on import of "MyServer.cer" and "MyClient.cer" Pin
Chirantan Ghosh14-Jan-14 6:06
Chirantan Ghosh14-Jan-14 6:06 
Questionhow to generate digital certificates using visual studio 2012? Pin
alexander elton joshua gam19-May-13 9:19
alexander elton joshua gam19-May-13 9:19 
QuestionHow to determine is server requires client certificate Pin
Ian Bekker18-Apr-13 0:06
Ian Bekker18-Apr-13 0:06 
QuestionCryptographic exception was unhandled :The specified network password is not correct. Pin
Sebastian T Xavier16-Apr-13 0:25
Sebastian T Xavier16-Apr-13 0:25 
QuestionSSL Mutual Auth Pin
nikudale9-Apr-13 6:05
nikudale9-Apr-13 6:05 
Hi,

I am trying to use mention certificate in my own WCF service and WebSite consume this service.
For testing purpose, do i need to copy both cert on client and server machine. also for this i need Trusted CA cert or export these two under trusted root CA resolve my issue?.
GeneralMy vote of 5 Pin
Member 93618355-Mar-13 6:13
Member 93618355-Mar-13 6:13 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.