Extended InCommon SSL Certificate Example

Generate a keypair and CSR using the gencert script and, using the InCommon Certificate Service, provision and install an InCommon SSL certificate for an Apache HTTP Server (httpd) on RHEL 6

Beginning on Feb. 1, 2011, a new Intermediate CA is used to sign InCommon-issued certificates. In the text that follows, substitute this new certificate,CN=InCommon Server CA, for the CN=COMODO High-Assurance Secure Server CA certificate mentioned.

More recently, SHA-2 certificates from Comodo use yet another set of intermediate certificates. The examples that follow again are generically correct, but the details on the names and numbers of the intermediate CA's will differ with these new SHA-2 certs.

To begin, let's generate a private key, a certificate signing request (CSR) for the public key, and a self-signed certificate (generated but not used in our case) for the host test.training.berkeley.edu:

sudo gencert test.training.berkeley.edu
Generating RSA private key, 2048 bit long modulus ...
[CSR is displayed to standard output and stored as described below]

The keypair is created and stored as noted in the following table. The gencert tool also creates a self-signed certificate for convenient testing purposes and stores it in the /etc/pki/tls/certs directory. This file, test.training.berkeley.edu.cert, is not further used in our case.

Item

Directory

Filename

private key

/etc/pki/tls/private

test.training.berkeley.edu.key

public key CSR

/etc/pki/tls/certs

test.training.berkeley.edu.csr

self-signed certificate (not used)

/etc/pki/tls/certs

test.training.berkeley.edu.cert

At this point, the Comodo-signed InCommon certificate can be provisioned using the InCommon CA Certificate Manager application with the generated CSR file content (or with the copied-and-pasted standard output text from the gencert script). In the e-mail that you then receive from cert-manager.com (or by using the View control button for an approved certificate entry within the Certificate Manager application) you'll see various links for downloading your certificate. Download and store the certificate files according to the following table:

Link Label

Download and store to:

Filename

X509 Certificate only, Base64 encoded

/etc/pki/tls/certs

test_training_berkeley_edu_cert.cer

X509, Base64 encoded

(any temp/working directory)

test_training_berkeley_edu.cer

Note that the second file (test_training_berkeley_edu.cer) is a certificate bundle file (a concatenated set of certificates stored in a single file) containing three certificates in base64 format. We will use a subset of that text file to create a new certificate bundle file for Apache with the Root and Intermediate CA certificates reordered into the standard RFC 5246 preferred order (see below).

To examine the individual certificates provided (and to simplify the later creation of a new Root/Intermediate bundle file), open as a source file the test_training_berkeley_edu.cer certificate bundle file using your favorite text editor. Now save the text components corresponding to each certificate into three new files named cert1.cer (topmost certificate in the source file), cert2.cer (middle certificate in the source file), and cert3.cer (bottom certificate in the source file).

To verify the identities of the various certificate files, use a certificate manager such as found with the common web browsers to import and view the certificates, or use the openssl utility to examine the Subject and Issuer fields of each individual certificate:

openssl x509 -noout -subject -issuer -in cert1.cer
subject= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network
    /CN=AddTrust External CA Root
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network
    /CN=AddTrust External CA Root

openssl x509 -noout -subject -issuer -in cert2.cer
subject= /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited
    /CN=COMODO High-Assurance Secure Server CA [old data; now CN=InCommon Server CA]
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network
    /CN=AddTrust External CA Root

openssl x509 -noout -subject -issuer -in cert3.cer
subject= /C=US/postalCode=947201500/ST=California/L=Berkeley
    /street=200 California Hall #1500
    /O=University of California at Berkeley
    /OU=Training/OU=PlatinumSSL
    /CN=test.training.berkeley.edu
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited
    /CN=COMODO High-Assurance Secure Server CA

We can conclude that cert1.cer corresponds to the self-signed Root CA certificate in this chain, cert2.cer corresponds to the Intermediate CA certificate signed by the Root CA, and cert3.cer corresponds to the server certificate signed by the Intermediate CA that was issued by the InCommon CA in response to the submitted CSR.

Combining Subject and Issuer information into a single table shows the complete chain of trust in certificate validation order, starting with the server certificate, then the Intermediate CA, and ending with the self-signed Root CA:

Certificate file

Certificate Type

Subject

Issuer

cert3.cer

Server

CN=test.training.berkeley.edu

CN=InCommon Server CA

cert2.cer

Intermediate CA

CN=InCommon Server CA

CN=AddTrust External CA Root

cert1.cer

Root CA

CN=AddTrust External CA Root

CN=AddTrust External CA Root

All three of these certificates (the Root CA and Intermediate CA two certificates to be bundled within a single file) are made available to the Apache HTTP Server along with the private key file generated initially. This will allow the Server to assert the entire certificate trust chain to an SSL/TLS client application such as a web browser.

Comparing these three certificates to the second downloaded file shows that it contains only a single component of the certificate trust chain: the X509 Certificate only file (saved as test_training_berkeley_edu_cert.cer) contains the server certificate alone, and is identical in content to the cert3.cer file generated above.

Further, if you were to download the file labeled X509 Intermediates/root only, you would find that it contains the root CA certificate plus the intermediate CA certificate in that order in a certificate bundle file. However, since the standard RFC 5246 preferred order is different, we create our own certificate bundle file instead (see below).

Note that the bundle files as provided by the InCommon CA has recently changed to include the intermediate and root CA certificates in two sequences to fit more environments: X509 Intermediates/root only, Base64 encoded and X509 Intermediates/root only Reverse, Base64 encoded. Note also that the TLS standard (see the quotation at the end of the page below) permits omitting the self-signed Root CA certificate from the asserted chain of certificates. Thus, another deployment option is to install as the Apache Certificate Chain File just the Intermediate CA certificate file (cert2.cer) rather than the certificate bundle file consisting of both the Intermediate and Root CA certificates (the contents of cert2.cer plus cert1.cer combined in that order into a single file) as recommended by the Comodo KB articles cited in this document.

Install for Apache HTTP Server with mod_ssl

There are two certificate files that the Apache HTTP Server configuration file for SSL will reference in addition to the server's own private key file (SSL Certificate Key File):

  1. an SSL Certificate File containing the signed certificate bearing the server's public key
  2. an SSL Certificate Chain File containing the bundle of certificates bearing the public keys for the Intermediate and Root CAs.

In the previous section we identified the individual certificate files as:

Subject

Certificate Type

Filename

AddTrust External CA Root

Root CA

cert1.cer

InCommon Server CA

Intermediate CA

cert2.cer

test.training.berkeley.edu

Server

cert3.cer

To create an SSL Certificate Chain File (a certificate bundle file) in the standard RFC 5246 preferred order for use with Apache HTTP Server, copy cert2.cer and cert1.cer into a new file, CA-bundle.cer, in that order, and copy the newly created bundle file to the standard installation location:

cat cert2.cer cert1.cer > CA-bundle.cer sudo cp CA-bundle.cer /etc/pki/tls/certs

We now have the three files in place that Apache HTTP Server 2.x needs to implement SSL on RHEL 6. In the syntax of the Apache configuration file, these are defined as in the following excerpt, including first a directive to enable the SSL support engine. These statements typically occur within a <VirtualHost> section:

[excerpt from /etc/httpd/conf.d/ssl.conf]

<VirtualHost>
...
SSLEngine on
SSLCertificateKeyFile /etc/pki/tls/private/test.training.berkeley.edu.key
SSLCertificateFile /etc/pki/tls/certs/test_training_berkeley_edu_cert.cer
SSLCertificateChainFile /etc/pki/tls/certs/CA-bundle.cer
...
</VirtualHost>

Note that private key files (test.training.berkeley.edu.key in our example) contain sensitive information which content should only be readable by the account starting the Apache HTTP Server, typically the root account on RHEL 6. If not already set for your private key files, use chmod to set restrictive permissions, for example:

sudo chmod 0400 /etc/pki/tls/private/*

Refer to the Comodo KB article Certificate Installation: Apache & mod_ssl for additional details on the Apache configuration steps.

For advanced reading on the general topic of the Transport Layer Security (TLS) protocol, the current generation of SSL technology for the Internet, refer to the TLS RFC, where one can find such things as the certificate chaining order definition:

certificate_list

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.