SSL mutual authentication

ssl_mutual_auth.pngA browser connecting to the secure server will use the SSL protocol to connect and verify the servers 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 sendsClientHellomessage proposing SSL options.

  1. Server responds withServerHellomessage selecting the SSL options.
  2. Server sendsCertificatemessage, which contains the server’s certificate.
  3. Server requests client’s certificate inCertificateRequestmessage, so that the connection can be mutually authenticated.
  4. Server concludes its part of the negotiation withServerHelloDonemessage.
  5. Client responds withCertificatemessage, which contains the client’s certificate.
  6. Client sends session key information (encrypted with server’s public key) inClientKeyExchangemessage.
  7. Client sends aCertificateVerifymessage to let the server know it owns the sent certificate.
  8. Client sendsChangeCipherSpecmessage to activate the negotiated options for all future messages it will send.
  9. Client sendsFinishedmessage to let the server check the newly activated options.
  10. Server sendsChangeCipherSpecmessage to activate the negotiated options for all future messages it will send.
  11. Server sendsFinishedmessage to let the client check the newly activated options.

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

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.

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.

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.

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 -servernameexample.com-connectexample.com:443 -key client-cert.key -cert client-cert.crt

Below is an example of two-way SSL authentication on the BIG-IP systemand how to configure mutual or two-way (mutual) authentication using a Client SSL profile to protect application traffic.

ssl-one-way-auth.pngOne-way authentication

Using one-way authentication, clients perform SSL handshakes when initiating a new connection with SSL protected applications.

During the SSL handshake, the protected application sends its public SSL certificate to the remote client for validation (referencing the photo on the right the remote client is shown as Server).

The remote client (Server) validates the application’s public SSL certificate by searching for the signing Certificate Authority (CA) certificate in its trusted CA store.

If the remote client (Sever) is unable to validate or find the signing CA for the public SSL certificate, it should not complete the SSL handshake and abandon the new connection attempt.

ssl-two-way-auth.pngTwo-way authentication

Two-way authentication is a less popular method for protecting application traffic as it requires an additional layer of security. When using two-way authentication, clients perform a slightly modified SSL handshake when initiating a new connection with SSL-protected applications. During the modified SSL handshake, the protected application sends its public SSL certificate to the remote client for validation and requests that the remote client sends its Client SSL certificate for validation as well. Both the remote client and protected application validate the SSL certificates they receive by searching for the signing CA certificates in their respective trusted CA stores. If the remote client or the protected application is unable to validate the received SSL certificate, they should not complete the SSL handshake and abandon the new connection attempt.

REFERENCE: