X.509 Certificates and Certificate Revocation Lists (CRLs)
Last Modified: 1 May, 2001
In One Sentence: What is a Certificate?
What Applications use Certificates?
How do I get a Certificate?
What is Inside an X.509 Certificate?
What Java API Can Be Used to Access and Manage Certificates?
What Java Tool Can Generate, Display, Import, and Export X.509 Certificates?
A public-key certificate is a digitally signed statement from
one entity, saying that the public key (and some other information)
of another entity has some specific value.
Let us expand on some of the key terms used in this sentence:
- Public Keys
These are numbers associated with a particular entity, and
are intended to be known to everyone who needs to have trusted interactions
with that entity. Public keys are used to verify signatures.
- Digitally Signed
If some data is digitally signed it has been stored with the
"identity" of an entity, and a signature that proves that entity knows about
the data. The data is rendered unforgeable by signing with the entitys' private key.
A known way of addressing an entity. In some systems the identity is
the public key, in others it can be anything from a Unix UID to an Email address
to an X.509 Distinguished Name.
A signature is computed over some data using the private key
of an entity (the signer).
- Private Keys
These are numbers, each of which is
supposed to be known only to the particular entity whose private
key it is (that is, it's supposed to be kept secret).
Private and public keys exist in pairs in all public key cryptography systems
(also referred to as "public key crypto systems").
In a typical public key crypto system,
such as DSA, a private key corresponds to exactly one public key.
Private keys are used to compute signatures.
An entity is a person, organization, program, computer, business,
bank, or something else you are trusting to some degree.
Basically, public key cryptography requires access to users' public keys.
In a large-scale networked environment it is impossible to guarantee that prior
relationships between communicating entities have been established or that a
trusted repository exists with all used public keys.
Certificates were invented as a solution to this public key distribution problem.
Now a Certification Authority (CA) can act as a Trusted Third Party.
CAs are entities (e.g., businesses) that are trusted to sign (issue)
certificates for other entities. It is assumed that CAs will only create
valid and reliable certificates as they are bound by legal agreements.
There are many public Certification Authorities, such as
Entrust, and so on.
You can also run your own Certification Authority using products such as
the Netscape/Microsoft Certificate Servers or the Entrust CA product for
Probably the most widely visible application of X.509 certificates
today is in web browsers (such as Netscape Navigator and Microsoft Internet
Explorer) 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 SSL.
Other technologies that rely on X.509 certificates include:
- Various code-signing schemes, such as signed Java ARchives, and
- Various secure E-Mail standards, such as PEM and S/MIME.
- E-Commerce protocols, such as SET.
There are two basic techniques used to get certificates:
The main inputs to the certificate creation process are:
Matched public and private keys, generated using some
special tools (such as keytool), or a browser.
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 can create one yourself (using the right tools, such as
- you can ask a Certification Authority to issue you one (either directly
or using a tool such as keytool to generate the request).
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 are 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 a browser that supports Certificate Signing Request generation).
to digitally sign this information, and send it to the CA.
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).
The X.509 standard 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:
- 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.
- Serial Number
- The entity that created the certificate is responsible for
assigning it a serial number to distinguish it from other
certificates it issues.
This information is used in numerous ways, for example when a
certificate is revoked its serial number is placed in a Certificate
Revocation List (CRL).
- Signature Algorithm Identifier
- This identifies the algorithm used by the CA to sign the certificate.
- 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.)
- 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 chosen 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.
This is the expected period that entities can rely on the public value, if
the associated private key has not been compromised.
- 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=Java Software Division, O=Sun Microsystems Inc, C=US
(These refer to the subject's Common Name, Organizational Unit,
Organization, and Country.)
- Subject Public Key Information
- This is the public key of the entity being named, together with an
algorithm identifier which specifies which public key crypto system this key
belongs to and any associated key parameters.
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 to particular
purposes such as "signing-only") and AlternativeNames (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.
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 use.
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".
IETF PKIX working group is in the process of defining
standards for the Internet Public Key Infrastructure.
We are closely following their work, and are supporting its
X.509 Certificate and CRL Profile, which is being specified.
The Certificate API, found in the
includes the following:
- the CertificateFactory class defines the functionality of a
certificate factory, which is used to generate certificate and certificate
revocation list (CRL) objects from their encoding.
- the Certificate class is an abstract class for managing a variety
It is an abstraction for certificates that have different
formats but important common uses. For example, different types of
certificates, such as X.509 and PGP, share general certificate
functionality (like encoding and verifying) and
some types of information like public key.
- the CRL class is an abstract class for managing a variety
of Certificate Revocation Lists (CRLs).
- the X509Certificate class is an abstract class for X.509 Certificates.
It provides a standard way to access all the attributes of an X.509 certificate.
- the X509Extension interface is an interface for an X.509 extension.
The extensions defined for X.509 v3 certificates and v2
CRLs (Certificate Revocation Lists) provide mechanisms
for associating additional attributes with users or public keys,
such as for managing the certification hierarchy, and for managing CRL
- the X509CRL class is an abstract class for an X.509 Certificate
Revocation List (CRL).
A CRL is a time-stamped list identifying revoked certificates.
It is signed by a Certification Authority (CA) and made freely
available in a public repository.
- the X509CRLEntry class is an abstract class for a CRL entry.
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. For examples, see the "EXAMPLES" section of the keytool
documentation ( for Solaris )
( for Windows ).