In Figure 2–2, certificate-based authentication is set in the following steps.
The client software maintains a database of the private keys that correspond to the public keys published in any certificates issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session—for example, the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication. After entering this password once, the user doesn’t need to enter it again for the rest of the session, even when accessing other SSL-enabled servers.
The client unlocks the private-key database, retrieves the private key for the user’s certificate, and uses that private key to digitally sign some data that has been randomly generated for this purpose on the basis of input from both the client and the server. This data and the digital signature constitute “evidence” of the private key’s validity. The digital signature can be created only with that private key and can be validated with the corresponding public key against the signed data, which is unique to the SSL session.
The client sends both the user’s certificate and the evidence, the randomly generated piece of data that has been digitally signed, across the network.
The server uses the certificate and the evidence to authenticate the user’s identity.
At this point the server may optionally perform other authentication tasks, such as checking that the certificate presented by the client is stored in the user’s entry in an LDAP directory. The server then continues to evaluate whether the identified user is permitted to access the requested resource. This evaluation process can employ a variety of standard authorization mechanisms, potentially using additional information in an LDAP directory, company databases, and so on. If the result of the evaluation is positive, the server allows the client to access the requested resource.