Certificate validation, Ca hierarchies and certificate chains, Root ca certificates – Allied Telesis AT-S63 User Manual

Page 582: Certificate revocation lists (crls)

Advertising
background image

Chapter 27: PKI Certificates and SSL

582

Section IV: Security

Certificate

Validation

To validate a certificate, the end entity verifies the signature in the
certificate, using the public key of the CA who issued the certificate.

CA Hierarchies and Certificate Chains

It may not be practical for every individual certificate in an organization
to be signed by one certification authority. A certification hierarchy may
be formed, in which one CA (for example, national headquarters) is
declared to be the root CA. This CA issues certificates to the next level
down in the hierarchy (for example, regional headquarters), who
become subordinate CAs and issue certificates to the next level down,
and so on. A hierarchy may have as many levels as needed.

Certificate hierarchies allow validation of certificates through certificate
chains and cross-certification. If a switch X, which holds a certificate
signed by CA X, wishes to communicate securely with a switch Y, which
holds a certificate signed by CA Y, there are two ways in which the
switches can validate each other’s certificates. Cross-certification occurs
when switch X validates switch Y's CA (CA Y) by obtaining a certificate for
switch Y's CA which has been issued by its own CA (CA X). A certificate
chain is formed if both CA X and CA Y hold a certificate signed by a root
CA Z, which the switches have verified out of band. Switch X can validate
switch Y’s certificate (and vice versa) by following the chain up to CA Z.

Root CA Certificates

A root CA must sign its own certificate. The root CA is the most critical
link in the certification chain, because the validity of all certificates
issued by any CA in the hierarchy depends on the root CA’s validity.
Therefore, every device which uses the root CA’s certificate must verify it
out-of-band.

Out-of-band verification involves both the owner of a certificate and the
user who wishes to verify that certificate generating a one-way hash (a
fingerprint) of the certificate. These two hashes must then be compared
using at least one non-network-based communication method.
Examples of suitable communication methods are mail, telephone, fax,
or transfer by hand from a storage device such as a smart card or floppy
disk. If the two hashes are the same, the certificate can be considered
valid.

Certificate

Revocation Lists

(CRLs)

A certificate may become invalid because some of the details in it
change (for example, the address changes), because the relationship
between the Certification Authority (CA) and the subject changes (for
example, an employee leaves a company), or because the associated
private key is compromised. Every CA is required to keep a publicly
accessible list of its certificates which have been revoked.

Advertising