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.
Identity
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.
Signature
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.
Entity
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 , , , 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 your organization.
Probably the most widely visible application of X.509
certificates today is in web browsers (such as Mozilla Firefox and
Microsoft Internet Explorer) that support the TLS protocol. TLS
(Transport Layer Security) 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 TLS.
Other technologies that rely on X.509 certificates include:
Various code-signing schemes, such as signed Java ARchives, and
Microsoft Authenticode.
Various secure E-Mail standards, such as PEM and S/MIME.
There are two basic techniques used to get certificates:
you can create one yourself (using the right tools, such as
keytool), or
you can ask a Certification Authority 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:
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 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:
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.
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,
(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".
The
working group is in the process of defining standards for the
Internet Public Key Infrastructure. We are closely following their
work, and support the X.509 Certificate and CRL Profile,
which is specified in .
The Certificate API, found in the java.security.cert
package, includes the following:
the CertificateFactory class defines the functionality
of a certificate factory, which is used to generate certificate,
certificate revocation list (CRL), and certification path objects
from their encoding.
the Certificate class is an abstract class for managing
a variety of certificates. 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
distribution.
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.
In JDK 1.4, new classes were added to support building and
validating chains of certificates, or certification paths. These
classes are described in further detail in the PKI Programmer's Guide.
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 v3
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. 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 v3 certificates. For examples, see the
"EXAMPLES" section of the keytool documentation ( for Solaris ) (
for Windows
).
