Unsupported content

 

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Securing communication with CA certificates

This topic was edited by a BMC Contributor and has not been approved.  More information.

When you install an Application Server, the installation procedure provisions the Application Server with a self-signed certificate. However, some organizations might choose to use a CA-issued certificate or certificate chain rather than the default self-signed certificate.

When you perform this procedure, you set up a keystore that takes the place of the bladelogic.keystore created automatically when you install the Application Server. (A keystore contains certificates and a private key. A trust store only contains certificates.)

If the certificate you are importing includes a URL for an OCSP Responder, the client attempts to verify the revocation status of the Application Server certificate. If you do not want clients to verify a certificate's revocation status, do not provision the Application Server with a certificate that includes an OCSP URL.

After you provision Application Servers with CA-issued certificates, you should import those certificates into client trust stores. For more information about that procedure, see Importing CA-issued certificates into clients.

Instructions for importing the certificate differ, depending on whether the certificate authority can generate the key and request or the certificate authority can only sign CSRs and does not have the ability to export a key.

To import a certificate when the certificate authority can generate the key and request

  1. Obtain a certificate chain from a certificate authority.
  2. Import the certificate and its corresponding private key into a keystore file on the Application Server.
    Ideally, your certificate authority should create a certificates and private keys and output them using the JKS format. If your CA cannot create a JKS file and instead provides a PKCS12 file, you must convert your certificates and private keys into JKS. There are various tools for performing this type of conversion. For example, you can use Java's keytool utility, which is available on any machine where the Authentication Server is installed. If you are importing a certificate with the Authentication Server's version of keytool, you might enter a command like the following:

    <path to keytool>/keytool -importkeystore -srckeystore <bladelogic.p12>
        -destkeystore <bladelogic.keystore> -srcstoretype pkcs12 -deststoretype jks
        -srcalias <pkcs12Alias> -destalias blade
    

    In this command:

    • <path to keytool> will be inside the BMC Server Automation installation path. For example, C:\Program Files\BMC Software\BladeLogic\NSH\jre\bin on Windows or /opt/bmc/bladelogic/NSH/br/java/bin on Unix), 

    • <bladelogic.p12> is the file being imported.

    • <bladelogic.keystore> is the name of the keystore file you are creating. This file should be stored in the /deployments directory for the Application Server that is being updated, such as <installDirectory>/br/deployments/_template

    • <pkcs12Alias> is the alias under which the certificate and private key are stored.

    Note

    No matter what method you use to import the certificate, the alias you use to identify the certificate must be blade and the format of the keystore must be jks.

    When you enter the command shown above, you are prompted for a destination keystore password. This is the password used to encrypt the keystore. When you use the blasadmin utility to set up keystores for cooperating Application Servers, you must provide this password. The command shown above also prompts you for the source keystore password, which is the password originally used to create the PCKS12 file.

To import a certificate when the certificate authority only signs CSRs (but does not export a key)

  1. Generate a new keystore file

    <path to keytool>/keytool --genkey -alias blade -keyalg RSA -keystore <keystore>
        -storepass <password> -dname "CN=<hostname>" -keypass <password>
        -validity <validity> -keysize <keysize> -storetype jks
    
    

    In this command:

    • <path to keytool> will be inside the BMC Server Automation installation path. For example, C:\Program Files\BMC Software\BladeLogic\NSH\jre\bin on Windows or /opt/bmc/bladelogic/NSH/br/java/bin on Unix)

    • <keystore> is the file name of the keystore to be created.
    • <password> is the password for the keystore and key (they should be the same)
    • <hostname> is the hostname that you want to appear in the certificate.
    • <validity> is the length in days that the certificate is valid for.
    • <keysize> is the size/strength of the key. 
    • The alias must be 'blade'.
  2. Generate a certificate request

    <path to keytool>/keytool -certreq -alias blade -keystore <keystore>
        -file <csr> -storepass <password> -keypass <password>

    In this command, <csr> is the file name that will hold the Certificate Signing Request.

  3. Get the CSR signed by the CA and download the certificate (.pem or .crt file) with either the CA chain (typically a PKCS7, .p7b file) or a list of root, intermediary, and signing certificates (two, three, or more .pem or .crt files).

    Note

    If the CA only supplies PEM files with the root and intermediary certificates, you can create a certificate chain PKCS7 (.p7b) file by performing the following commands with the CA chain certificate files supplied by the CA. The following example assumes that your certificate is named signed_cert.pem and you have three CA certificates from your CA:

    cat root_cert.pem intermediate_cert.pem signing_cert.pem <any other intermediate cert> > ca_certs_chain.pem
    openssl crl2pkcs7 -nocrl -certfile signed_cert.pem -out certs.p7b -certfile ca_certs_chain.pem

  4. Import the .p7b file into the keystore.

    <path to keytool>/keytool -importcert -keystore <keystore> -file <p7b file> 
        -storepass <password> -keypass <password> -alias blade -storetype jks
    

    In this command <p7b file> is the file name that contains the CA-signed certificate request and the CA chain.

    Note

    They keytool utility included with the Application Server should be used in all steps above that reference they keytool command. Ensure that you use a fully qualified path name when running the command, or ensure that you are using that keytool binary in the commands above and not some other keytool binary found in the system's path.

Using the new keystore

  1. The new keystore must be updated in all deployments (_spawner, _launcher, default, _pxe, and any other named deployments).
  2. If you are using a multi-Application Server environment, copy the JKS file that you generated in step 2 from this Application Server to all cooperating Application Servers, in all deployment directories. 
  3. If a new password is needed, update the password for each cooperating Application Server. For information about this process, see Synchronizing keystore files of multiple Application Servers.

Troubleshooting issues with CA certificates

You might encounter issues during the import of CA certificates due to problems in the use of the keytool utility. Use the following troubleshooting steps to resolve these issues.

SymptomTroubleshooting steps
You receive the following error when importing the certificate to the keystore: 
"Certificate reply does not contain public key for
<blade>"
  1. Navigate to the java directories where the keytool utility is located, and locate the java.security file in /NSH/br/java/lib/security (on UNIX or Linux) or \NSH\jre\lib\security (on Windows).
  2. To back up the java.security file, temporarily rename it.
  3. Download the java.security file attached to this page, and store it in the same folder. This file will temporarily replace the original java.security file.
  4. After successfully importing the CA certificates into bladelogic.keystore, delete the temporary java.security file that you downloaded from this page (as instructed in step 3) and rename the original file back to java.security (to undo step 2).
The keytool utility is not responsive for a long time (typically more than 2 minutes)
  1. Navigate to the java directories where the keytool utility is located, and locate the java.security file in /NSH/br/java/lib/security (on UNIX or Linux) or \NSH\jre\lib\security (on Windows).
  2. Open the java.security file using any text editor, and change the securerandom.source setting to the following value:
    securerandom.source=/dev/./urandom
Was this page helpful? Yes No Submitting... Thank you

Comments

  1. N A

    You write: "A keystore contains certificates and a private key. A trust store only contains certificates." - but then, why is "client_keystore.pkcs12.PEM" named keystore? In fact it just containts one or more certificates according to the environment.

    Solution 1 (the best): rename the file in future versions

    Solution 2 (more realistic (wink) ): tell the audience of this page that there is an exception to this "rule"...

    Jul 24, 2014 04:24
    1. Bill Robinson

      the pkcs12 format can hold the CA chain.  if you are using CA-signed certs you could load the ca chain into this file and you would not get the popup message to accept the cert from the appserver the first time you connect the gui.

       

      so it is a keystore, but since practically no one uses ca-signed certs for the gui connection, or if they do they don't load them into they keystore it ends up only holding the key from the appserver.

      Jul 24, 2014 04:29
      1. N A

        Thank you for clarification!

        Jul 24, 2014 04:50