000033886 - How to create and configure certificates for HTTPS access when using intermediate CA certs in RSA Via Lifecycle and Governance

Document created by RSA Customer Support Employee on Sep 19, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000033886
Applies ToRSA Product Set: RSA Identity Governance and Lifecycle (RSA G&L)
RSA Version/Condition: 7.0
IssueYour organization uses an in-house or commercial certificate authority (CA) which will be signing the appliance certificate for HTTPS access to the GUI.  Keytool 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 G&L when using CA signed certificates.
TasksThe 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.
  3. Give the CSR 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.
  4. Combine all certificates into one file in their chaining order by copying the contents of each certificate into a new file.
  5. Import the keypair and cert chain into a new keystore using Keystore Explorer.
  6. Save the new keystore, backup the existing keystore, and replace the existing keystore with the new one.
  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.  The 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 article we will assume the CA returns to you a certificate named host-certificate.cer.
  4. Note that each certificate provided by the CA form 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'll 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: 
    -----END CERTIFICATE-----

    In order to build the chain file 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 last, the host certificate.  For example, the chain file for a certificate signed by a CA using two intermediate certificates would look something like:
    <Root CA Certificate Data>
    -----END CERTIFICATE-----
    <Intermediate CA Certificate 1 Data>
    -----END CERTIFICATE-----
    <Intermediate CA Certificate 2 Data>
    -----END 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.
  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 between.  
    11. Use File > Save as, save the keystore as aveksa.keystore.
  6. Backup the existing keystore used by Aveksa (note the ticks are true ticks, not apostrophes):
    cp /home/oracle/keystore/aveksa.keystore /home/oracle/keystore/aveksa.keystore.backup_`date +%F_%T`

  7. Replace the /home/oracle/keystore/aveksa.keystore on the appliance with the one created in Keystore Explorer.  
  8. Restart Aveksa.  
acm restart

  1. Ensure the root CA certificate provided by your CA is trusted on the system from which you intend to access Aveksa then test the connection to ensure it validates the new UI certificate as trusted.  This root CA certificate can also be set to trusted by the Aveksa server by following the instructions in Appendix A of the RSA Via Lifecycle and Governance Installation Guide V7.0, for how to import certificates into the Java cacerts file.
NotesNote 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.