Digital Certificates 101

Digital certificates are files that contain information that a Certificate Authority's (CA's) certificate server signs. If the certificate holder trusts the CA, the holder assumes the information in a certificate is valid.

A CA is a trusted organization that can serve as a certificate server. It can be a group within a company that uses certificates internally, or it can be a third-party vendor such as VeriSign of Mountain View, California, (http://www.verisign.com) that provides signed certificates for a fee. CAs will eventually include state and possibly local government organizations. (For more information about certificates and CAs, see Tao Zhou, "You Can Be a Web Certification Authority," October 1997.)

Certificates typically use a public key system in which each certificate owner receives a public and private key from the CA. Anyone can receive the public key to decrypt information that the private key encrypts or to verify a digital signature that the private key generates. An owner's public key typically exists as part of a certificate that a CA has digitally signed.

Complex environments with multiple CAs might include hierarchical certification and cross-certification in which a certificate has multiple associated signatures. In the simple case, a high-level CA authorizes a low-level CA to create certificates by providing the latter with a signing certificate. The low-level CA can then sign new certificates. Users that trust the high-level authority can accept these certificates because the users can trace the trust relationship back to the high-level CA. This type of CA relationship occurs in a public key infrastructure (PKI) architecture. For information about PKI, see Tao Zhou, "Public Key Infrastructure in Win2K," January 1999. You can implement a PKI within a large organization with multiple certificate servers and CAs. One or more global PKIs will eventually be implemented, but this work is still in its infancy.

Two public key systems exist: X.509 and Network Associate's pretty good privacy (PGP). Netscape and Microsoft certificate servers use X.509. Whereas PGP uses cross-certification, X.509 uses a hierarchical PKI. Both approaches provide similar features and capabilities but use different encryption methods.

Certificates are typically text files that contain independent-data and data-dependent signatures. The public and private keys use the independent data to generate or verify the signatures. A mismatch identifies a bad key or bad data.

Certificates can contain arbitrary information, but they include required fields, such as a certificate number and an expiration date. The certificate number makes looking up the certificate easy, and the expiration date makes verifying the certificate easy. The alternative is to check a Certificate Revocation List (CRL) that the certificate server maintains. A certificate is valid if a trusted CA has properly signed the certificate, the certificate's expiration date hasn't passed, and the certificate isn't on a CRL.

You can reissue certificates, in which case they have a new number and expiration date. Organizations must balance the length of time users will need a certificate with the security consequences of long expiration dates. For example, a high-security environment might reissue certificates daily, but most organizations do so monthly or yearly. The alternative to reissuing certificates often is to keep CRLs up to date, which is usually easy within an organization but difficult across multiple organizations.