Demystifying Certificate Requirements in Mutual TLS

Understanding Certificates and SSL/TLS long ago became an IT fundamental.

Somehow, the industry seems to have not noticed.  In my quest to take fewer calls on this stuff, here is my attempt to help demystify all the certificates involved in Client SSL/Mutual TLS.  I seem to be spending 2+ hours a day on the phone talking web and server admins through this stuff.

The reason I am doing this is because Google failed me.  There are a lot of docs that focus on all the other aspects of the SSL/TLS negotiation, but none of them focuses on the certificates and what they do for us. Microsoft has one of the better papers on SSL/TLS, but there is a lot lacking around the certificates and the SSL/TLS handshakes are overly summarized.

Here is the handshake that MS shows us.

While this may be a four message handshake, there are a few different conversations taking place, simultaneously, in the handshake.  The conversations and their certificate requirements are more easily understood when they are pulled out of the stick context of the message format.

I will say that I am doing a bit of summarizing.  SSL/TLS has four major components: authentication, message integrity, key negotiation and encryption.  This post focuses heavily on the authentication aspect.  I am lumping SSL and TLS together as the basic functions of the negotiations are the same, only the implementation details vary a bit.  I am also leaving out a bit about session key generation. 

I break the handshake down into 4 different conversations.

A.      Hellos

a.       The client tells the server that it wants to go secure and offers the suite of ciphers it supports.

b.      The server selects a cipher from the list.

c.       No certificates are involved here.

B.      Server Certificate presentations

a.       The server sends over the SSL certificate AND the chain. 

b.      The server must have the private key for the SSL certificate.

c.       If the chain, (CA hierarchy) is not sent, negotiation MUST fail.

d.      The client SHOULD perform full cert and chain validation against these certs, making sure they chain to a Root CA that is trusted explicitly by the client.

C.      Key Exchanges

a.       The client and server exchange data that allows the negotiation of session encryption keys.

b.      If EDH is used, then the RSA/DSS key is used to block MITM of the key negotiation.

c.       If RSA key negotiation is used, the client encrypts its initial key material with the public key on the server SSL certificates, assuming cert and chain validation succeeded.

D.      Client Certificate  presentations

a.       The server issues a Certificate Request.  This lists the key types allowed on the certificate and a list of Distinguished Names (DNs).  These DNs are used as a hint to help the client determine which of its many possible certificates is the “right” one.

b.      The client selects a certificate, for which it MUST have the private key, and sends the certificate to the server.

c.       The client sends data that is signed using its private key, proving it holds the certificate in question.

d.      The server checks the signature.  If the signature passes, the server may be configured to pass/fail the client based on data in the certificate.  Often the certificate serial number or Subject DN must match a static list, or the certificate must be one that is on file.  The decision to pass/fail the client cert is not specified in any RFC.

 

 

More below

Certificates Needed

	Client	Server
A - Hellos	None	None
B - Server Certificate	Root CA Cert for Trust	SSL Cert and Chain to send
C - Key Exchange	Public key from Server Cert	Private key for Server Cert
D - Client Auth	Client Cert and Private key	Client cert for explicit trust or CA cert to implicit trust.  Cert values MAY be checked.

 

Client and Server Perspective

One often forgotten part of this is that when there are two parties, the role of client and server may change.   For instance, let's say A pushes a full DB copy every night to B, and then B pulls deltas hourly during the day. In this scheme, at night, B is the server, but during the day, B is the client.  This means that both parties need a cert and a server cert with chain, and they need to know how to implicitly or explicitly trust other clients, and they need Root CA certs so they can trust the server cert when they are the client.

Summary

Take the time to understand how your connections are established and it is fairly easy to figure out which certificates are used when. When it comes to figuring out what is wrong, you can usually figure out the issue by where the handshake fails.  The handshake failures usually can only be seen via packet captures.