The SSL Handshake
812 Red Hat Certificate System Administrator’s Guide • September 2005
2.
Is today’s date within the validity period?
The server checks the certificate’s validity
period. If the current date and time are outside of that range, the authentication process
won’t go any further. If the current date and time are within the certificate’s validity
period, the server goes on to Step 3.
3.
Is the issuing CA a trusted CA?
Each SSL-enabled server maintains a list of trusted
CA certificates, represented by the shaded area on the right side of Figure K-3. 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 answer to this question
is yes, and the server goes on to Step 4. If the issuing CA is not on the list, the client
will not be authenticated unless the server can verify a certificate chain ending in a CA
that is on the list. Administrators can control which certificates are trusted or not
trusted within their organizations by controlling the lists of CA certificates maintained
by clients and servers.
4.
Does the issuing CA’s public key validate the issuer’s digital signature?
The server
uses the public key from the CA’s certificate (which it found in its list of trusted CAs in
Step 3) to validate the CA’s digital signature on the certificate being presented. If the
information in the certificate has changed since it was signed by the CA or if the public
key in the CA certificate doesn’t correspond to the private key used by the CA to sign
the certificate, the server won’t authenticate the user’s identity. If the CA’s digital
signature can be validated, the server treats the user’s certificate as a valid “letter of
introduction” from that CA and proceeds. At this point, the SSL protocol allows the
server to consider the client authenticated and proceed with the connection as described
in Step 6. Red Hat servers may optionally be configured to perform Step 5 before Step
6.
5.
Is the user’s certificate listed in the LDAP entry for the user?
This optional step
provides one way for a system administrator to revoke a user’s certificate even if it
passes the tests in all the other steps. The Red Hat Certificate System can automatically
remove a revoked certificate from the user’s entry in the LDAP directory. All servers
that are set up to perform this step will then refuse to authenticate that certificate or
establish a connection. If the user’s certificate in the directory is identical to the user’s
certificate presented in the SSL handshake, the server goes on to step 6.
6.
Is the authenticated client authorized to access the requested resources?
The
server checks what resources the client is permitted to access according to the server’s
access control lists (ACLs) and establishes a connection with appropriate access. If the
server doesn’t get to step 6 for any reason, the user identified by the certificate cannot
be authenticated, and the user is not allowed to access any server resources that require
authentication.
Summary of Contents for CERTIFICATE 7.1 ADMINISTRATOR
Page 1: ...Administrator s Guide Red Hat Certificate System Version7 1 September 2005 ...
Page 22: ...22 Red Hat Certificate System Administrator s Guide September 2005 ...
Page 128: ...Cloning a CA 128 Red Hat Certificate System Administrator s Guide September 2005 ...
Page 368: ...ACL Reference 368 Red Hat Certificate System Administrator s Guide September 2005 ...
Page 460: ...Constraints Reference 460 Red Hat Certificate System Administrator s Guide September 2005 ...
Page 592: ...CRL Extension Reference 592 Red Hat Certificate System Administrator s Guide September 2005 ...
