How does SSL mutual authentication work?

Customers may add secure socket layer (SSL) certificates to their websites to secure their information. A browser connecting to the secure server will use the SSL protocol to connect and verify the server’s certificate. However, customers can also use Mutual Authentication to have both the client and server use signed certificates to authenticate each other. With Mutual Authentication, both client and server will provide signed certificates for verification.

How Mutual Authentication Works

Client sends ClientHello message proposing SSL options.

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

How the Client and Server Accomplish Each of the Checks for Client Authentication

1. Digital Signature:  The client sends a "Certificate Verify" message that contains a digitally signed copy of the previous handshake message.  This message is signed using the client certificate's private key.  The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate).  Once the digital signature is validated, the server knows that the public key belonging to the client matches the private key used to create the signature.
2. Certificate Chain:  The server maintains a list of trusted Client Authorities (CAs), and this list determines which certificates the server will accept.  The server will use the public key from the CA certificate (which it has in its list of trusted CAs) to validate the CA's digital signature on the certificate being presented.  If the message digest has changed or if the public key does not correspond to the CA's private key used to sign the certificate, the verification fails and the handshake terminates.
3. Expiration Date and Validity Period:  The server compares the current date to the validity period listed in the certificate.  If the expiration date has not passed and the current date is within the period, then this check succeeds.  If it is not, then the verification fails and the handshake terminates.
4. Certificate Revocation Status:  The server compares the client certificate to the list of revoked certificates on the system.  If the client certificate is on the list, the verification fails and the handshake terminates.

Additional Information

Verify the Client Certificate with auth-root

Run the following command to verify the client certificate:

openssl verify -purpose sslclient -CAfile auth-root.crt testcert.crt

Test Connection with Client Cert

Run the following command to test the connection with the client:

openssl s_client -servername example.com -connect example.com:443 -key client-cert.key -cert client-cert.crt