Problem - Kevin Tafuro

There is no way to digitally verify the authenticity of a self-signed certificate because
the issuer and the subject are the same, which is why it has become common practice
to provide these certificates with the software that uses them. When self-signed
certificates are included with an application, the software author generally obtains
them by some physical means. For example, Thawte (now a part of VeriSign) provides
its root certificates on its web site, free and clear, but strongly advises anyone
making use of them to confirm the certificate fingerprints with Thawte via telephone
before using or distributing them.
To verify the authenticity and validity of a given certificate, each certificate in the
chain must also be verified, from the issuer of the certificate all the way up to the
root certificate. If any certificate in the chain is invalid, each certificate below it in the
chain must also be considered invalid. Invalid certificates typically have either
expired or been revoked (perhaps due to certificate theft). A certificate is also most
certainly considered invalid if it has been tampered with or if the signatures on the
certificate do not match the ones that should have been used to sign it, indicating
that an attacker has tampered with the contents.
The decision about whether to employ a certificate hierarchy more complex than a
single root CA depends on many factors. These factors and their trade-offs are well
beyond the scope of this book. Entire books have been devoted to PKI, and we
strongly recommend that you consult one or more of them to assist you in making an
informed decision. Again, we strongly recommend Planning for PKI, cited at the
beginning of this recipe.
X.509 certificates
The most widely accepted format for certificates is the X.509 format, first introduced in
1988. There are three versions of the format: X.509v1, X.509v2, and X.509v3. The
most recent revision to the standard was introduced in 1996, and most, if not all, modern
software now supports it. A large number of changes were made between X.509v1
and X.509v3, but perhaps the most significant feature introduced in the X.509v3 standard
is its support for extensions.
Version 3 extensions allow a certificate to contain additional fields beyond those
defined by previous versions of the X.509 standard. The additional fields may be
standard in X.509v3, such as the basicConstraints or keyUsage extensions, or they
may be completely nonstandard, perhaps recognized by only a single application.
Each extension has a name for its field, a designation indicating whether the extension
is critical or not, and a value to be associated with the extension field. When an
extension is designated as being critical, software that does not recognize the extension
must reject the certificate as being invalid. If the extension is noncritical and
unknown to the certificate user, it may be ignored.
The X.509v3 standard defines numerous extensions in an effort to consolidate the
more frequently appearing extensions implemented by third parties. One such exam-
512 | Chapter 10: Public Key Infrastructure
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.