Content received from: http://JavaFAQ.nu/java-article575.html
Generate Certificate Chains for Testing Java Applications
Friday, October 29, 2004 (00:00:00)
If you're developing Java software that relies on public key infrastructure
(PKI) for security, you often need to create digital-certificate chains (also
known as certification paths) for testing purposes. This is a relatively simple
task but one for which clear documentation is scarce. This article describes how
to create arbitrary-length certificate chains using the open source OpenSSL
toolkit (see Resources). You'll also learn about some common certificate
attributes and examine a sample program that reads certificates into a Java
Digital certificates: A quick overview
This article assumes that you're familiar with PKI basics, so I'll give you just
a quick overview of the purpose and structure of digital certificates to help
clarify the concept of a certificate chain.
The primary use for digital certificates is to verify the origin of signed data,
such as e-mail and JAR files. Verifying the signed data with a certificate lets
the recipient know the origin of the data and if it has been altered in transit.
A digital certificate contains, at a high level, a distinguished name (DN) and a
public key. The DN identifies an entity -- a person, for example -- that holds
the private key that matches the public key of the certificate. You tie the two
together by signing the certificate with a private key and placing the signature
in the certificate.
A certificate signed by the private key that matches the public key of the
certificate is known as a self-signed certificate. Root certification authority
(CA) certificates fall into this category. User certificates are often signed by
a different private key, such as a private key of the CA . This constitutes a
two-certificate chain. Verifying that a user certificate is genuine involves
verifying its signature, which requires the public key of the CA, from its
certificate. But before the public key of the CA can be used, the enclosing CA
certificate needs to be verified. Because the CA certificate is self signed, the
CA public key is used to verify the certificate.
A user certificate need not be signed by the private key of the root CA. It
could be signed by the private key of an intermediary whose certificate is
signed by the private key of the CA. This is an instance of a three-certificate
chain: user certificate, intermediary certificate, and CA certificate. But more
than one intermediary can be part of the chain, so certificate chains can be of
Another point worth noting is that a certificate can contain additional
information, known as extensions. Extensions can specify the use of the
certificate, among other things. Certain extensions can be very important,
depending on the use of the certificate.
Learn how to create digital-certificate chains to test your software. IBM Software Engineer, Paul H. Abbott, clarifies this seldom-do*****ented process by showing you how to use the freely available OpenSSL toolkit to create a certificate chain of any length. He also describes common certificate attributes and shows you some sample Java code for reading the certificates you create into a Java keystore.