Certificates and Certificate Authorities (CA)
A certificate is an electronic document that identifies an individual,a server, a company, or some other entity. A certificate also associates thatidentity with a public key. Like a driver’s license, a passport, orother commonly used personal IDs, a certificate provides generally recognizedproof of someone's or something's identity.
Certificate authorities, CAs, validate identitiesand issue certificates. CAs can be independent third partiesor organizations that run their own certificate-issuing server software. Themethods used to validate an identity vary depending on the policies of a givenCA. In general, before issuing a certificate, the CA mustuse its published verification procedures for that type of certificate toensure that an entity requesting a certificate is in fact who it claims tobe.
A certificate issued by a CA binds a particular publickey to the name of the entity the certificate identifies, such as the nameof an employee or a server. Certificates help prevent the use of fake publickeys for impersonation. Only the public key certified by the certificate workswith the corresponding private key possessed by the entity identified by thecertificate.
In addition to a public key, a certificate always includes the nameof the entity it identifies, an expiration date, the name of the CA that issuedthe certificate, a serial number, and other information. Most importantly,a certificate always includes the digital signature of the issuing CA. TheCA’s digital signature allows the certificate to function as a “letterof introduction” for users who know and trust the CA but don’tknow the entity identified by the certificate.
Any client or server software that supports certificates maintains acollection of trusted CA certificates. These CA certificates determine whichother certificates the software can validate, in other words, which issuersof certificates the software can trust. In the simplest case, the softwarecan validate only certificates issued by one of the CAs for which it has acertificate. It’s also possible for a trusted CA certificate to be partof a chain of CA certificates, each issued by the CA above it in a certificatehierarchy.
For information about CAs, see the following sections:
CA Hierarchies
Certificate Chains
Verifying a Certificate Chain
CA Hierarchies
In large organizations, it may be appropriate to delegate the responsibilityfor issuing certificates to several different certificate authorities. Forexample, the number of certificates required may be too large for a singleCA to maintain; different organizational units may have different policy requirements;or it may be important for a CA to be physically located in the same geographicarea as the people to whom it is issuing certificates.
It’s possible to delegate certificate-issuing responsibilitiesto subordinate CAs. The X.509 standard includes a model for setting up a hierarchyof CAs.
Figure5–3 Hierarchy of Certificate Authorities
Inthis model, the root CA is at the top of the hierarchy. The root CA’scertificate is a self-signed certificate. That is, thecertificate is digitally signed by the same entity, the root CA, that thecertificate identifies. The CAs that are directly subordinate to the rootCA have CA certificates signed by the root CA. CAs under the subordinate CAsin the hierarchy have their CA certificates signed by the higher-level subordinateCAs.
Organizations have a great deal of flexibility in terms of the way theyset up their CA hierarchies. Figure5–3 showsjust one example; many other arrangements are possible.
Certificate Chains
CA hierarchies are reflected in certificate chains. A certificatechain is a series of certificates issued by successive CAs. Figure5–4 shows a certificate chainleading from a certificate that identifies some entity through two subordinateCA certificates to the CA certificate for the root CA (based on the CA hierarchyshown in the following figure).
Figure5–4 Certificate Chain
A certificate chain traces a path of certificates from a branch in thehierarchy to the root of the hierarchy. In a certificate chain, the followingoccur:
Each certificate is followed by the certificate of its issuer.
In Figure5–4,the Engineering CA certificate contains the DN of the CA (that is, USA CA),that issued that certificate. USA CA’s DN is also the subject name ofthe next certificate in the chain.
Each certificate is signed with the private key of its issuer.The signature can be verified with the public key in the issuer’s certificate,which is the next certificate in the chain.
In Figure5–4, the publickey in the certificate for the USA CA can be used to verify the USA CA’sdigital signature on the certificate for the Engineering CA.
Verifying a Certificate Chain
Certificate chain verification is the processof making sure a given certificate chain is well-formed, valid, properly signed,and trustworthy. Directory Server software uses the following steps toform and verify a certificate chain, starting with the certificate being presentedfor authentication:
The certificate validity period is checked against the currenttime provided by the verifier’s system clock.
The issuer’s certificate is located. The source canbe either the verifier’s local certificate database (on that clientor server) or the certificate chain provided by the subject (for example,over an SSL connection).
The certificate signature is verified using the public keyin the issuer certificate.
If the issuer’s certificate is trusted by the verifierin the verifier’s certificate database, verification stops successfullyhere. Otherwise, the issuer’s certificate is checked to make sure itcontains the appropriate subordinate CA indication in the Directory Server certificatetype extension, and chain verification returns to step 1 to start again, butwith this new certificate.
Figure5–5 Verifying A Certificate Chain
Figure5–5 shows what happenswhen only Root CA is included in the verifier’s local database. If acertificate for one of the intermediate CAs shown in Figure5–6, such as Engineering CA, is found in the verifier’s local database,verification stops with that certificate, as shown in the following figure.
Figure5–6 Verifying A Certificate Chain to an IntermediateCA
Expired validity dates, an invalid signature, or the absence of a certificatefor the issuing CA at any point in the certificate chain causes authenticationto fail. For example, the following figure shows how verification fails ifneither the Root CA certificate nor any of the intermediate CA certificatesare included in the verifier’s local database.
Figure5–7 Certificate Chain That Cannot Be Verified
For general information about the way digital signatures work, see Digital Signatures.
