站内搜索: 请输入搜索关键词
当前页面: 在线文档首页 > JDK 5 Documentation v1.1.8, Java 2 SDK 英文文档

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?

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 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:


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:

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:

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

  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.

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

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


Copyright © 1996, 1997 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA 94043-1100 USA. All rights reserved.

Written by: David Brownell

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