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 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 bejks
.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 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'.
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).
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.pemImport 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
- 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: "Certificate reply does not contain public key for <blade>" |
|
The keytool utility is not responsive for a long time (typically more than 2 minutes) |
|
Comments
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 ): tell the audience of this page that there is an exception to this "rule"...
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.
Thank you for clarification!
Log in or register to comment.