Problem - Kevin Tafuro

are updated periodically and should be downloaded frequently to avoid stale information.
Most CAs issue CRLs. (See Recipes 10.10 and 10.11 for details on where to
look for CRLs and how to obtain them.) Another solution is to interactively ask the
CA using the OCSP. (We discuss this protocol in Recipe 10.12.)
In general, a certificate is verified against a collection of other certificate material—
that is, CA certificates and CRLs. To verify a certificate, all of the certificates in the
chain must be known. Trusted certificates are certificates that are known to be valid
without having to perform signature verification on them; however, they could be
invalid for other reasons, as we will soon see. Untrusted certificates can also be
present in the hierarchy, in which case they must also be verified using trusted certificates.
There must always be at least one trusted certificate at the root of the hierarchy.
If there is not, the certificate cannot be considered valid.
All certificates in the certification path must be checked to ensure they are valid for
their assigned date. Every certificate has a beginning and an ending date for their
validity period, and if the current date is outside that range, the certificate cannot be
considered valid. Most people who have any familiarity with certificates usually realize
that certificates expire, but many do not realize that they can have validity dates
into the future and will not necessarily be valid yet at the point when they are presented.
Finally, you must check every certificate in the certification path to ensure that it has
not been revoked. Revocation status can be checked using a CRLor by consulting an
OCSP responder. It is best to be able to handle both types of revocation checks
because one or the other may not always be available or reliable.
Once the validity of every certificate in the certification path has been verified, the
basic verification tests are complete, but you are not done yet! You have only established
that the certificate was issued by a CA that you trust, is within its valid period,
and has not been revoked. Nothing has been done to verify that the entity that presented
it to you is actually the entity that owns it. The details of how to do this vary,
but in the most common case of a server presenting a certificate to a client, the hostname
of the server should be embedded in the certificate. The hostname in the certificate
can be compared to the hostname of the server that presented it (see Recipe 10.8).
If the hostnames do not match, the certificate should not be trusted.
In situations where it isn’t feasible to perform full certificate verification, an alternative
is to compare the certificate against a list of known good certificates. See Recipe
10.9 for a discussion of how to do this.
See Also
Recipes 10.8, 10.9, 10.10, 10.11, 10.12
524 | Chapter 10: Public Key Infrastructure
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.