Certificate validation, Certificate revocation lists (crls) – Allied Telesis AT-S63 User Manual

Page 799

Advertising
background image

AT-S63 Management Software Menus Interface User’s Guide

Section IX: Management Security

799

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