Why should I care about X.509 certificates?

Last Modified: 7 October, 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?

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:

Certificates rely on public key crypto systems. 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 of the binding between a public key and its owner. There are many such Certification Authorities, such as VeriSign, GTE, Thawte 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:


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, such as keytool), or (2) you can ask someone else (a CA) to issue you one (either directly or using a tool such as keytool to generate the request). The main inputs to the certificate creation process are:

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 keytool or 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 keytool). 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:

  1. Version
    This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined.

  2. 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)

  3. Public Key
    This is the public key of the entity being named.

  4. 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.)

  5. Serial Number
    The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it generates.

  6. 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.

X.509 Version 1 has been available since 1988, is widely deployed, and is the most generic.

X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.

X.509 Version 3 is the most recent (1996) and supports the notion of extensions, whereby anyone can define an extension and include it in the certificate. Some common extensions in use today are: KeyUsage (limits the use of the keys for particular purposes such as "signing-only") and AltNames (allows other identities to also be associated with this public key, e.g. DNS names, Email addresses, IP addresses). Extensions can be marked critical to indicate that the extension should be checked and enforced/used. So, for example, if a certificate has the KeyUsage extension marked critical and set to "keyCertSign" then if this certificate is presented during SSL communication, it should be rejected, as the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL.

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.

The IETF PKIX working group is in the process of defining standards for the Internet Public Key Infrastructure. We are closely following this work, and are supporting the profile defined in Part I < draft-ietf-pkix-ipki-part1-04.txt > , as part of the X.509v3 support.


What Java API Can Be Used to Access and Manage Certificates?

The Certificate API, found in the java.security.cert package, includes the following:

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

There is a tool named keytool ( for Solaris ) ( for Windows ) that can be used to create public/private key pairs and self-signed X.509 v1 certificates, and to manage keystores. Keys and certificates are used to digitally sign your Java applications and applets (see the jarsigner( for Solaris ) ( for Windows ) tool).

A keystore is a protected database that holds keys and certificates for an enterprise. Access to a keystore is guarded by a password (defined at the time the keystore is created, by the person who creates the keystore, and changeable only when providing the current password). In addition, each private key in a keystore can be guarded by its own password.

Using keytool, it is possible to display, import, and export X.509 v1, v2, and v3 certificates stored as files, and to generate new self-signed v1 certificates.


Copyright © 1995-98 Sun Microsystems, Inc. All Rights Reserved.



Initially written by: David Brownell
Updated by: Hemma Prafullchandra

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