SSL server

SSL server authentication allows a client to confirm a server's identity by using standard techniques of public key cryptography to validate that a server's certificate is valid and has been issued by a certificate authority (CA) listed in the client's list of trusted CAs. This confirmation could be important, for example, if the client is sending a credit card number over the network and wants to verify the receiving server's identity.

A client uses the following steps with the server's certificate to authenticate a server's identity.
  1. Determine whether the issuing CA is a trusted CA. Each client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client's list of trusted CAs, the issuing CA is considered a trusted CA and the client continues with step 3. If the issuing CA is not on the client's list of trusted CA certificates, the server is not authenticated unless the client can verify a certificate chain that ends in a CA that is on the list.
  2. Determine whether the issuing CA's public key validates the issuer's digital signature. The client uses the public key from the CA certificate to validate the CA digital signature on the server certificate that is being presented. If the server 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 client does not authenticate the server'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.
  3. Validate 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. If the current date and time are within the certificate's validity period, the client goes to step 4.
  4. Determine whether the domain name in the server's certificates matches the domain name of the server. By performing this step, the client is confirming that the server is truly located at the same network address as specified by the domain name in the server certificate. If the domain names do not match, the client will refuse to authenticate the server or establish a connection. If the domain names do match, the client continues with step 5. The client has now determined that the server certificate is valid.
  5. Check for a certificate revocation list (CRL) to see if the certificate has been revoked.
  6. Authenticate the server. The client continues with the SSL handshake. If for some reason the client does not reach this step, the server that the certificate has identified is not authenticated and no connection is established. If the server requires client authentication, the steps provided in SSL client are completed.

The server is now ready to use its private key to decrypt the secret session key that the client sends during the SSL handshake. Otherwise, the SSL session is ended.