Crypto 101: Digital Certificates

A certificate is a data package that completely identifies an entity, and is issued by a Certification Authority (CA) only after that authority has verified the entity's identity. The data package includes the public key that belongs to the entity. When the sender of a message signs the message with its private key, the recipient of the message can use the sender's public key (retrieved from the certificate either sent with the message or available elsewhere on the network) to verify that the sender is legitimate.

The X.509 protocol defines the following structure for public-key certificates:

Version

Serial Number

Signature Algorithm

Issuer Name

Period of Validity Not Before Date Not After Date

Subject Name

Subject's Public Key Algorithm Public Key

Extensions

Signature

The version field identifies the certificate format. The serial number is unique within the CA. The Signature Algorithm identifies the algorithm used to sign the certificate. Issuer is the name of the CA. The period of validity is a pair of dates; the certificate is valid during the time period between the two. Subject is the name of the user to whom the certificate is issued. The subject's public key field includes the algorithm name and the public key itself. The last field is the CA's signature.

In order for digital certificates to be effective, the users of the network must have a high level of trust in the certificate. But what happens if someone doesn't trust the CA - perhaps the person has never heard of the CA before. This problem is addressed in the certifying process by something called the hierarchy of trust.

The concept of hierarchy of trust is simply that the process must begin with some certifying authority that everyone agrees is trustworthy. This ultimate authority is called the root authority. The root authority then can certify other CAs below it, who can then certify CAs below them, etc. This is illustrated on the following diagram:

When someone receives a certificate that has been issued by a first- or second-tier CA, he or she can verify that the CA that signed the certificate has been certified by a CA at the tier above it and that, in turn, that CA has been certified by the one above it, and so on until a chain of trust exists between the lower level CA (or a user certificate) and the root CA. For example, in the preceding diagram, it can be verified that CA #4 was certified by CA #1 and that CA #1 was certified by the root CA. This means that when a certificate from a lower-level CA is passed along with the encrypted message, all of the certificates in its chain of trust up to the root should be passed along with it.

A certificate request is a signed data package that contains a person's information such as name, email address, company name etc, and his/her public key. A certificate request is generated by a person wishing to obtain a certificate from the CA. Certificate requests are signed by the person's private key to prevent tampering with during transmission.

When the CA receives a certificate request it extracts a person's name and public key information and performs a certain procedure aimed at verifying that the public key really belongs to the person whose name is included in the certificate request. If the verification process is successful, the CA issues the certificate and sends it to the requestor.

Certificates can also be revoked, either because the user's key has been compromised, the CA's key has been compromised, or because the CA no longer wants to certify the user. Each CA maintains a list of all revoked but not expired certificates. When Alice receives a new certificate she should check to see if it has been revoked. She can check a database of revoked keys on the network or locally cached list or revoked certificates.