SSL client

SSL client authentication allows a server to confirm a client's identity by using the same techniques of public key cryptography as those used for server authentication to validate that a client's certificate is valid and has been issued by a certificate authority (CA) listed in the server's list of trusted CAs. This confirmation could be important, for example, if a bank is sending confidential financial information to a customer and the bank wants to verify the recipient's identity.

You can configure a server application to require Client authentication. Then, when the server requests client authentication through the SSL handshake, the client sends the server a certificate and digitally signed data to authenticate itself. The server uses this digitally signed data to validate the certificate's public key and to authenticate the identity that the certificate claims to represent.

To authenticate the binding between the public key and the person or entity that the certificate has identified as containing the public key, the server uses the following steps to authenticate the client's identity:
  1. Determines whether the user's public key validates the user's digital signature by checking that the digital signature can be validated with the public key in the certificate. If the validation can occur, the server has established that the public key asserted to belong to a particular person or entity matches the private key used to create the digital signature, and that the data was not tampered with since it was signed. The binding between the public key and the distinguished name (DN) specified in the certificate has not been established. The server must complete steps 3 and 4 to validate the binding between the public key and the DN.
  2. Validates the current date to ensure it is within the validity period. The client checks the server certificate's validity period. If the current date and time are not within a valid range, the authentication process does not continue any further. If the current date and time are within the certificate's validity period, the client goes to step 3.
  3. Determines whether the issuing CA is a trusted CA. Each server maintains a list of trusted CA certificates. This list determines which certificates the server will accept. If the DN of the issuing CA matches the DN of a CA on the server's list of trusted CAs, the issuing CA is considered a trusted CA and the server continues with step 4. If the issuing CA is not on the server's list of trusted CA certificates, the client is not authenticated unless the server can verify a certificate chain that contains a CA that is on the list. You have the ability to control which certificates are trusted or not by controlling the lists of CA certificates maintained by the clients and servers.
  4. Determines whether the issuing CA's public key validates the client certificate issuer's digital signature. The server uses the public key from the CA certificate to validate the CA digital signature on the certificate that is being presented. If the certificate information changed since it was signed by the CA, or the public key for the CA certificate does not correspond to the private key used by the CA to sign the server certificate, the server does not authenticate the user's identity. If the CA digital signature is validated, the server handles the user's certificate as a valid letter of introduction from that particular CA and continues. The server now considers the client authenticated and will continue with the connection.
  5. Checks a certificate revocation list (CRL) to see if the certificate has been revoked.
Related information: