Securing communication with CA certificates
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
- Obtain a certificate chain from a certificate authority.
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 bladeIn 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.
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)
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 jksIn 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'.
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.
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).
Import the .p7b file into the keystore.
<path to keytool>/keytool -importcert -keystore <keystore> -file <p7b file>
-storepass <password> -keypass <password> -alias blade -storetype jksIn this command <p7b file> is the file name that contains the CA-signed certificate request and the CA chain.
Using the new keystore
- The new keystore must be updated in all deployments (_spawner, _launcher, default, _pxe, and any other named deployments).
- 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.
- 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.
Symptom | Troubleshooting steps |
---|---|
You receive the following error when importing the certificate to the keystore: |
|
The keytool utility is not responsive for a long time (typically more than 2 minutes) |
|