How to create and configure certificates for HTTPS access when using intermediate CA certs in RSA Identity Governance & Lifecycle

[#1]

Article Number

000033886

Applies To

RSA Product Set: RSA Identity Governance & Lifecycle 
RSA Version/Condition: 7.0.x, 7.1.x, 7.2.x
 

Issue

Your organization uses an in-house or commercial certificate authority (CA) which will be signing the appliance certificate for HTTPS access to the user interface. The keytool utility is limited in how it can create and import private keys into keystore files, making it difficult to properly setup a trust chain within the keystore used by RSA Identity Governance & Lifecycle when using CA signed certificates.
 

Task

The steps in this article include how to:

1. Generate a keypair using openSSL.
2. Generate a certificate signing request (CSR) using that keypair in openSSL that you will give to your CA, who will return to you a signed certificate, a root CA certificate, and zero or more intermediate CA certificates which form the signing chain.
3. Combine all certificates into one file in their chaining order by copying the contents of each certificate into a new file.
4. Import the keypair and cert chain into a new keystore using Keystore Explorer.
5. Save the new keystore, backup the existing keystore, and replace the existing keystore with the new keystore.

Resolution

Execute the commands below as the root user.

1. To generate a keypair you can use openSSL. There are many options available for generating keys, but here is a simple example:

   
   openssl genrsa -out host-key.pem -aes256 -passout pass:Av3k5a15num83r0n3 2048

   This will generate a new file, named host-key.pem, containing the private key. This key MUST be kept private. It is suggested that you encrypt the key file, as is done in the example command above.

2. To generate a CSR from the private key generated in step 1, use the following openSSL command:

   
   openssl req -new -sha256 -key host-key.pem -passin pass:Av3k5a15num83r0n3 -out root-csr.csr

   This will generate a CSR based on the keypair generated in step 1.

3. Send the CSR generated in step 2 to your CA to have it signed.  he CA will return to you a certificate for the host (end-point) as well as a root CA certificate and possibly some intermediate CA certificates. Typically these certificates will be in PEM format (base-64 encoded DER), with a file extension of .pem, .cer, .crt, or possibly others. For the purpose of this RSA Knowledge Base Article we will assume the CA returns to you a certificate named host-certificate.cer.

4. Note that each certificate provided by the CA forms a trust chain that represents the signing order in which the CA signed each certificate. This chain is of the form root CA certificate > zero or more Intermediate CA certificate(s) > Host certificate (referred to as end-point or leaf).  There may not be intermediate CA certificates, but if there are, they must be included in the chain in the correct order. We must copy the contents of each certificate into a new file, which we will call chain-certificate.pem, in the order in which they signed each other. If you open each certificate in a text editor, you will find the certificate data is wrapped in a BEGIN and END header/footer as illustrated here: 

   
   -----BEGIN CERTIFICATE-----
   <BASE64 ENCODED DATA>
   -----END CERTIFICATE-----

   In order to build the chain file (chain-certificate.pem), copy the contents of the certificate file, including the header and footer lines, into a new file. The first item in that new file should be the contents of the root CA certificate, followed by the first intermediate certificate, followed by any other intermediate certificates, and then lastly, the host certificate. For example, the chain file for a certificate signed by a CA using two intermediate certificates would look something like this:

   
   -----BEGIN CERTIFICATE-----
   <Root CA Certificate Data>
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   <Intermediate CA Certificate 1 Data>
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   <Intermediate CA Certificate 2 Data>
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   <Host Certificate Data>
   -----END CERTIFICATE-----
   

   If in doubt as to the order in which certificates were signed, the certificates can be examined (double click in Windows) and the subject and issuing fields inspected. The issuing field of the certificate will match the subject field of the certificate which signed it. Root CA certificates will be self-signed, meaning the issuing and subject fields will match. When this step is completed, you will have a number of certificate files provided by your CA, the newly created chain-certificate.pem, and the host-key.pem file generated in step 1 which contains the private key .

5. Download and install Keystore Explorer, if you haven't already.  Keystore Explorer is a free, open-source, GUI replacement for the Java command-line utility keytool. It overcomes some of the limitations of keytool, such as the ability to import public/private key-pairs. To use Keystore Explorer:
   1. Run Keystore Explorer.
   2. When prompted, choose Create a new KeyStore.  
   3. Choose type JKS.  
   4. In the new keystore, choose Tools > Import Key Pair.  
   5. Select OpenSSL as the type.  
   6. If you encrypted your private key file with a password (as in step 1 by adding the -aes256 and -passout parameters), check the Encrypted Private Key box and enter the password used for the Decryption Password field.  
   7. For the OpenSSL Private Key File field, select the host-key.pem file generated in step 1.  
   8. For the Certificate(s) File, select the chain-certificate.pem created in step 4.  
   9. Click Import .  
   10. When prompted for an alias name, use server. There should now be an entry in the keystore named server.  Verify that the chain order is correct by double-clicking the entry and inspecting the Certificate Hierarchy at the top of the details. The hierarchy should reflect the signing order, with the root CA certificate listed at the top, and the host certificate listed at the bottom, with any intermediate CA certificates listed imbetween.  
   11. Use File > Save as, and save the keystore as aveksa.keystore.

Perform the remaing steps as the oracle user:

6. Backup the existing keystore used byRSA Identity Governance & Lifecycle (note the ticks are true ticks, not apostrophes):

   
   cp $AVEKSA_HOME/keystore/aveksa.keystore $AVEKSA_HOME/keystore/aveksa.keystore.backup_`date +%F_%T`

7. Replace the $AVEKSA_HOME/keystore/aveksa.keystore on the appliance with the one created in Keystore Explorer (setp 5).

8. Restart RSA Identity Governance & Lifecycle:

acm restart

9. Ensure that the root CA certificate provided by your CA is trusted on the system from which you intend to access RSA Identity Governance & Lifecycle, then test the connection to ensure it validates the new certificate as trusted. This root CA certificate can also be set up to be trusted by the RSA Identity Governance & Lifecycle server by following the instructions in the RSA Identity Governance & Lifecycle Installation Guide for your version on how to import certificates into the Java cacerts file.

Notes

Note that to properly validate a host, the host certificate CN should match the address used to access the site. If the CN of the certificate does not match the name used to access the source, your browser will not be able to validate the certificate.