Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION, Administration Manual

Page: 520 / 554

Appendix B. Introduction to Public-Key Cryptography
498
HSMEGDAWgBTy8gZZkBhHUfWJMzYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSMKvsuj/vwbf91o3j3
UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
-----END CERTIFICATE-----
B.4.6. How CA Certificates Establish Trust
CAs validate identities and issue certificates. They can be either independent third parties or
organizations running their own certificate-issuing server software, such as the Certificate System.
Any client or server software that supports certificates maintains a collection of trusted CA certificates.
These CA certificates determine which issuers of certificates the software can trust, or validate. In the
simplest case, the software can validate only certificates issued by one of the CAs for which it has a
certificate. It is also possible for a trusted CA certificate to be part of a chain of CA certificates, each
issued by the CA above it in a certificate hierarchy.
The sections that follow explains how certificate hierarchies and certificate chains determine what
certificates software can trust.
•
Section B.4.6.1, “CA Hierarchies”
•
Section B.4.6.2, “Certificate Chains”
•
Section B.4.6.3, “Verifying a Certificate Chain”
B.4.6.1. CA Hierarchies
In large organizations, responsibility for issuing certificates can be delegated to several different CAs.
For example, the number of certificates required may be too large for a single CA to maintain; different
organizational units may have different profile requirements; or a CA may need to be physically
located in the same geographic area as the people to whom it is issuing certificates.
These certificate-issuing responsibilities can be divided among subordinate CAs. The X.509 standard
includes a model for setting up a hierarchy of CAs, shown in
Figure B.6, “Example of a Hierarchy of
Certificate Authorities”
.