Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual page 18

Chapter 1. Introduction to Public-Key Cryptography
a Server"
requires SSL.
assumes that the client has a valid certificate that can be used to identify the client to the server.
Certificate-based authentication is preferred to password-based authentication because it is based on
the user both possessing the private key and knowing the password. However, these two assumptions
are true only if unauthorized personnel have not gained access to the user's machine or password,
the password for the client software's private key database has been set, and the software is set up to
request the password at reasonably frequent intervals.
NOTE
Neither password-based authentication nor certificate-based authentication address
security issues related to physical access to individual machines or passwords. Public-
key cryptography can only verify that a private key used to sign some data corresponds to
the public key in a certificate. It is the user's responsibility to protect a machine's physical
security and to keep the private-key password secret.
These are the authentication steps shown in
a Server":
1. 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, such as 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 does not need to enter it again for the rest of the
session, even when accessing other SSL-enabled servers.
2. The client unlocks the private-key database, retrieves the private key for the user's certificate,
and uses that private key to sign data randomly-generated from input from both the client and the
server. This data and the digital signature are 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.
3. The client sends both the user's certificate and the randomly-generated data across the network.
4. The server uses the certificate and the signed data to authenticate the user's identity.
5. The server may 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 evaluates 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 or company databases. If the result of the evaluation is positive, the server
allows the client to access the requested resource.
Certificates replace the authentication portion of the interaction between the client and the server.
Instead of requiring a user to send passwords across the network continually, single sign-on requires
the user to enter the private-key database password once, without sending it across the network. For
the rest of the session, the client presents the user's certificate to authenticate the user to each new
server it encounters. Existing authorization mechanisms based on the authenticated user identity are
not affected.
8
Figure 1.5, "Using a Certificate to Authenticate a Client to a Server"
Figure 1.5, "Using a Certificate to Authenticate a Client to
also