Why should I care about X.509 certificates?

You may already be hearing about X.509 certificates. If you have, this document can explain to you what they do for you. If you haven't heard people talking about X.509 certificates, you may want to read this document to learn more about the Internet security tools they facilitate. There are several parts to this document:

• In One Sentence: What's a Certificate?
• What Applications use Certificates?
• How do I get a Certificate?
• What's Inside an X.509 Certificate?

---

In One Sentence: What's a Certificate?

A certificate is a digitally signed statement from one entity, saying that the public key of some other entity has some particular value.

In case you don't understand that sentence, here are a few definitions:

• Public Keys are numbers associated with a particular entity, and are intended to be known to everyone who needs to have trusted interactions with that entity.
• An entity is a person, organization, program, computer, business, bank, or something else you're trusting to some degree.
• If some data is digitally signed it has been stored with the name of an entity, and a signature which proves that entity knows about the data.
• A signature is computed from some data and the private key of an entity.
• Private Keys are secret numbers which are supposed to be known only to a particular entity. One is always associated with a single public key.

Certificates rely on public key encryption technologies, with RSA currently being the most popular such technology. To undertand certificates, you don't need to know much beyond the facts that (a) private and public keys are paired, (b) private keys are used to sign, and (c) public keys are used to verify signatures.

One other term that comes up a lot is Certificate Authority (CA). These are entities (e.g. businesses) which are trusted to sign (issue) certificates for other people. They usually have some kind of legal responsibilities.

---

What Applications use Certificates?

Probably the most widely visible application of X.509 certificates today is in web browsers (such as Netscape Navigator) which support the SSL protocol. (SSL is a security protocol which provides privacy and authentication for your network traffic.) These browsers only use this protocol with web servers which support it.

Various secure E-Mail standards, such as PEM and S/MIME, also rely on X.509 certificates.

E-Commerce protocols such as SET rely on X.509 certificates.

The various code signing initiatives also build on X.509.

---

How do I Get a Certificate?

There are two basic techniques used to get certificates: [1] you can make one yourself (using the right tools), or [2] you can ask someone else (a CA) to make one for you. The main inputs to certificate creation process are:

• Matched public and private keys, generated using some special tools. Only the public key is ever shown to anyone else. The private key is used to sign things; if someone knows your private key, they can masquerade as you ... perhaps forging legal documents attributed to you!
• You need to provide information about the entity being certified (e.g. you). This normally includes information such as your name and organizational address. If you ask a CA to create a certificate for you, you will normally need to prove this information is correct.

If you're asking a CA to provide your certificate, you provide your public key and some information about you. You'll use a tool (such as Netscape Navigator 3.0) to digitally sign this information, and send it to the CA. (That CA might be a company like Verisign or BBN which only provides CA services. It might be your Internet Service Provider, or some other organization.) The CA will then create the certificate and return it.

If you're generating the certificate yourself, you'll take that same information, add a little more (dates when the certificate is valid, a serial number), and just create the certificate using some tool. Not everyone will accept self-signed certificates; one part of the value provided by a CA is to serve as a neutral introduction service, based in part on their documentation requirements.

---

What's Inside an X.509 Certificate?

X.509 defines a bunch of data that can go into a certificate, and describes how to write it down (the data format). All X.509 certificates have the following data, in addition to the signature:

1. Version ... identifies which version of the X.509 standard applies to this certificate, which affects what data may be stored in it. Version 1 has been available since 1988, and is widely deployed.
2. Entity Name ... the name of the entity whose key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet.
3. Public Key ... This is the public key of the entity being named.
4. Issuer Name ... the X.500 name of the entity which signed the certificate. This is normally a CA. Using this certificate implies trusting the entity which signed this certificate. (Note that in some cases, such as CA certificates, the issuer signs its own certificate.)
5. Serial Number ... The entity which created the certificate is responsible for assigning it a serial number to distinguish it from other certificates which it creates.
6. Validity Period ... Any certificate is valid only for a limited amount of time. This period is described by a start date and an end date, and can be as short as a few seconds or almost as long as a century.

Those base features are part of X.509 v1, the first version. X.509 v2 added features including certificate revocation lists (CRLs) used by CAs to say that particular certificates should no longer be trusted. X.509 v3 (in 1995) added features like restrictions on certificate use (such as "signing-only" certificates) and new kinds of names (including DNS style ones).

All the data in a certificate is encoded using two related standards called ASN.1/DER. Abstract Syntax Notation 1 describes data. The Definite Encoding Rules describe a single way to store and transfer that data. People have been known to describe this combination simultaneously as "powerful and flexible" and as "cryptic and awkward". There seems to be no groundswell of opinion suggesting that something other than ASN.1/DER be used; the existing infrastructure works, and can be readily evolved.