Authentication Procedure

This is what typically happens in a client-server environment when a user on the client tries to gain access to the server using certificate authentication:

The client requests access from the server to a specific user account, and also sends the user's certificate containing a public key to the server.
The server checks the CA signature in the certificate and consults a local database to see if the CA is trusted. If not, the certificate is rejected and the user is not authenticated.
The server checks the validity of the certificate, for example, by consulting a certificate revocation list (CRL) published by the CA. If the certificate has been revoked or has expired, the certificate is rejected.
The client signs a value with the user's private key.
The server verifies the signature with the user's public key.
If the signature is successfully verified, the user is authenticated, and the server can move on to authorizing the user, or giving access to the relevant parts of the system.

Steps 1–5 above form the process of identity checking in certificate authentication. Step 4 is the proof of possession.

The identity checking process above is not very different from that used in public-key authentication, but the difference lies in scalability rather than security, and can be summarized as follows:

Public-key authentication

Check if the received public key is trusted by consulting, for example, a local database.
Require proof that the remote entity has the corresponding private key and knows the passphrase.

Certificate authentication

Check if the received certificate is issued by a trusted CA, if it is valid, and whether it has been revoked.
Require proof that the remote entity has the corresponding private key and knows the passphrase.

It is important to note that, as is the case with public-key authentication, the security of certificate authentication is no stronger than the security policy employed by the CA in the process of identity establishment. It is imperative that the CA employs thorough procedures to establish the identity of the entity wishing to enroll a certificate. If the CA does not live up to this responsibility, users can end up connecting to unsecured servers and servers will risk allowing access to malicious users. Therefore users and administrators alike should choose carefully which CAs to trust, and should take steps to ensure that the CA's security policy is at a sufficiently high level. If "anyone" can get a certificate from the CA, trusting that CA is a security hazard.