Technical information about certificates

Certificates come in three flavors: personal certificates, which a user presents to gain access to some restricted service; site certificates, which a Web server presents to a browser as a proof of identity of the site and as a means to establish secure communication with the browser; and certification authority certificates, usually self-signed, which are used to verify the signatures of certificates issued by that CA.

A digital certificate typically contains the holder's public key, the time period for which it is valid, the holder's name and address, and issuer contact information. Additionally, this is digitally 'signed' by the issuer in such a manner that forgery is difficult and presentation of the certificate establishes its authenticity as having been issued by the particular issuer.

While the X.509 certificate standard is the predominant in the industry as of this writing, other proposals have been introduced. This section concentrates on X.509 and its variants.

An X.509 certificate contains an entity's:

• common name (personal name, or in the case of a server, the hostname)

• company name

• organizational name

• organizational unit name

• city where located

• state where located (spelled out)

• country where located (two-letter code)

• other identifying information as appropriate; perhaps an e-mail address

It also contains all of the above information for the issuer of the certificate.

It contains as well:

• the starting validity date ('notBefore'),

• the expiration date ('notAfter'),

• the serial number, which is a unique number given by the issuer,

• a version number, which determines the certificate standard that it adheres to.

Last but not least, it contains the entity's public key.

The certificate is digitally 'signed' by the issuer. First the certificate is converted into a standardized form and then given as the input to a hash function, which produces as output a short string, often 16 or 20 bytes long, known as the hash or fingerprint of the certificate. You might think of a hash function as performing a compression -- with lots of data loss! -- of the certificate. The hash function is difficult to reverse, so that someone cannot easily find another certificate that produces the same output when run through the hash function. This fingerprint is then encrypted with the issuer's private key.

A user who wants to check that the signature is valid gets a copy of the issuer's certificate, which has the issuer's public key. He or she then decrypts the string using the public key. Now he or she converts the certificate to the standardized form, runs it through the hash function, and checks to see that the result is the same as the decrypted string. If not, then the signature was a forgery.

Certificate specifications

The X.509 standard itself is available in an older form from 1993.

Peter Gutmann has put together an X.509 Style Guide which discusses the finer points of implementing X.509-style certificate handlers.

Netscape has introduced its own set of extensions to the X.509 specification.

RSA has a whole set of Public-Key Cryptography Standards (PKCS).