Generate Certificate Chains for Testing Java Applications

JavaFAQ Home » Security

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

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 any length.

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.

More below.

Custom Search