Implementing SSL certificates

Server Name Indication (SNI)

Proper implementation of SSL certificates is required for being able to access MVMA services from another host in your network after installation. 

Starting with version 9.2.00, MVMA supports the Server Name Indicator (SNI) extension to the Transport Layer Security (TLS) protocol by which a client indicates the host name to which it is trying to connect in a request (for example, see RFC 3546). Therefore, you must provide certificates for each host name under which MVMA services should be available to MVMA user in the network. By default, MVMA installs its services with SNI enabled with a self-signed certificate in its keystore that is assigned to localhost as the host name, meaning that MVMA is available only if localhost appears in the host name in the URLs for accessing MVMA. Therefore, by default, MVMA is initially available only from within a browser running on the same system that MVMA is installed on.

To make MVMA in your network available from any browser by using the original host name in the URLs, you must add a certificate assigned to the name of the host where MVMA was installed. 

For example, to add a self-signed certificate to the MVMA keystore to make MVMA available under the host name mvmahostname, open a console to the MVMA installation directory and perform the following step:

(Windows platform) Run

(Linux platform) Run

To adjust this example to your network environment, replace mvmahostname with the network host name of the MVMA 9.2 installation system.

Using your own certificate

To configure MVMA to use your own certificate, place that certificate in a keystore and provide the associated configuration to the application.
If you have a keystore already configured with your SSL certificate, follow these steps:

1. Open <install_directory> /configuration/services/org.apache.felix.http.cfg in a text editor.
2. Change the value of the key org.apache.felix.https.keystore so that it points to your keystore file.

3. Set the value of the key org.apache.felix.https.keystore.password to the password of your keystore. You can encode this password by running the following command and pasting the output into this field:
   (Windows) <install_directory>/bin/encodePassword.bat(Linux) <install_directory>/bin/encodePassword.sh

   Important 

   You must include the OBF prefix when using an obfuscated password. Do not use the MD5 password.

4. If required, add a org.apache.felix.https.keystore.key.password property and set as the password for your certificate. You can encode this password by running the following command and pasting the output into this field:
   (Windows) <install_directory>/bin/encodePassword.bat
   (Linux) <install_directory>/bin/encodePassword.sh

Using the keytool utility to create a keystore

If you have a certificate but do not have a keystore, use the keytool utility to create a keystore. You can then insert your certificate into the keystore. MVMA uses this certificate.

Creating a keystore can be a very complicated process; the following procedure details the basic steps only:

1. Make sure that you have a valid certificate and you know the password for the certificate.
2. Run the command <install_directory> /jre/<JRE platform>/ bin/keytool -importcert -keystore mykeystore.jks -file cert.pem
3. When prompted, enter a password for the keystore, and confirm it by re-entering it.
   You can now use this keystore in the MVMA configuration. You can use the encodePassword utility to conceal your passwords.

Keytool examples

This section includes examples of listing certificates in a jks keystore, and printing a certificate to see the certificate chain.

Listing certificates in jks keystore

Run the keytool with the -list parameter. You can use -v to get more verbose output.

Listing certificates in a JKS also forces you to verify that the keystore is of a supported type.

To get a summary of the certificates and keys currently stored in a keystore or truststore run the following command:

keytool --list -keystore keystore.jks -storepass bmcsoftware

To get a detailed list of the certificates and keys kept in a keystore or truststore, use the -v option as in the following command:

To print a certificate to see the certificate chain

Run the keytool with the -printcert switch against a certificate file. You can use the -v switch to get more verbose output. 

To print a self-signed certificate (owner and issuer are the same), use the following command:

$ keytool -printcert -file bmmadminhttps.pem -v

To print a certificate not self-signed

Use the following command example from TIBCO EMS certificates:

keytool -v -printcert -file client.cert.pem

To follow the certificate chain, you can typically follow the certificate chain with the same certificate the issuer in the previous certificate was referring to: