Why should I care about X.509 certificates? - JDK 5 Documentation v1.1.8, Java 2 SDK 英文文档

Why should I care about X.509 certificates?

Last Modified: 9 February, 1997

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?
What Java Tool Can Generate, Display, Import, and Export X.509 Certificates?

In One Sentence: What's a Certificate?

An identity 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 that proves that entity knows about the data.
A signature is computed from some data and the private key of an entity.
Private Keys are numbers that are supposed to be known only to a particular entity (i.e., kept secret). A private key is always associated with a single public key.

Certificates rely on public key encryption technologies. To understand 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 Certification Authority (CA). These are entities (e.g., businesses) that are trusted to sign (issue) certificates for other people (entities). They usually have some kind of legal responsibilities for their vouching for the binding between a public key and its owner. There are many such Certification Authorities, such as VeriSign, GTE, and so on.

What Applications use Certificates?

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

Other technologies that rely on X.509 certificates include:

Various secure E-Mail standards, such as PEM and S/MIME.
E-Commerce protocols such as SET.
Various code-signing schemes, such as Microsoft AuthentiCode and signed Java ARchives (JAR files).

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 issue you one. The main inputs to the certificate creation process are:

Matched public and private keys, generated using some special tools (such as javakey). Only the public key is ever shown to anyone else. The private key is used to sign data; 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 issue a certificate for you, you will normally need to provide proof to show correctness of the information.

If you're asking a CA to issue you a 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 that provides trusted third-party CA services. It might be your Internet Service Provider, or some other organization.) The CA will then generate the certificate and return it.

If you're generating the certificate yourself, you'll take that same information, add a little more (dates during which the certificate is valid, a serial number), and just create the certificate using some tool (such as javakey). Not everyone will accept self-signed certificates; one part of the value provided by a CA is to serve as a neutral and trusted introduction service, based in part on their verification requirements, which are openly published in their Certification Service Practices (CSP).

What's Inside an X.509 Certificate?

X.509 defines what information 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:

Version
This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Version 1 has been available since 1988, and is widely deployed.
Subject Name
The name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. This is the Distinguished Name (DN) of the entity, for example,
```
    CN=Java Duke, OU=JavaSoft, O=Sun Microsystems Inc, C=US
```
(These refer to the subject's common name, organizational unit, organization, and country)
Public Key
This is the public key of the entity being named.
Issuer Name
The X.500 name of the entity that signed the certificate. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate. (Note that in some cases, such as root or top-level CA certificates, the issuer signs its own certificate.)
Serial Number
The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it generates.
Validity Period
Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate.

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 1996) added the notion of extensions, of which keyUsage (limits the use of the keys for particular purposes such as "signing-only") and AltNames (allows other Names, e.g. DNS names, Email addresses, IP addresses) are very popular.

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.

What Java Tool Can Generate, Display, Import, and Export X.509 Certificates?

There is a new JDK 1.1 tool named javakey (for Solaris) (for Windows) for

managing a database of entities (people, companies, etc.), their public and private keys and certificates, and an indication as to which entities are "trusted".
generating digital signatures for Java ARchive (JAR) files, which contain arbitrary data, including class files, images, sounds, etc.

Using javakey, it is possible to display, import, and export certificates stored as files, and to generate new certificates.

Please send comments to: java-security@java.sun.com