How to add a custom certificate into OpsCenter

How to add a custom certificate into OpsCenter

Article: 100038205
Last Published: 2019-07-23
Ratings: 6 8
Product(s): NetBackup

In a default install a keystore is created which contains a self signed certificate for the Opscenter hostname. If custom certificates need to be used by Opscenter, a new keystore needs to be created that contains these custom certificates.

The keystore which contains these certificates is at the following location (referred to below as keystore_path )

Windows: <install_path>\OpsCenter\gui\Security\keystore
Linux: /opt/SYMCOpsCenterGUI/Security/keystore

The tool to create/update the keystore is “keytool”, which is located at the path below (referred to below as path_to_keytool )

Windows: <install_path>\OpsCenter\server\jre\bin\keytool
Linux: /opt/SYMCOpsCenterServer/jre/bin/keytool

Notes on KeyStore password for Opscenter 8.1.1 and later

For OpsCenter 8.1 and earlier, the default keystore was created with the password "opscenter", so Tomcat was already configured to use that password to open the keystore.

However, from OpsCenter 8.1.1, a random password is used, so if a custom keystore is created with the default “opscenter” password, the tomcat configuration will not contain the correct password to open the keystore

So if a new custom keystore is created for OpsCenter 8.1.1 (or later) then either

  1. The new keystore is created using the same password as the existing random one, _or_
  2. the configuration is updated to use the keystore password used, if different.

For a), the current password can be seen in the file below, and this should be used in the steps below in place of "opscenter" when creating a new keystore.

Windows: <install_path>OpsCenter\gui\config\jskey
Linux: /opt/SYMCOpsCenterGUI/config/jskey

For b) any password can be used, so long as this is then updated in the configuration to match.

For an upgrade with existing custom certificates, the keystore already exists (so has a password set) so only option b is possible

For the purposes of this document, the keystore password used in the steps below is listed as  "opscenter", so the steps can be used unmodified for OpsCenter prior to 8.1.1 - if a different password is used, the parameter following "-storepass" will need to be modified accordingly.

Note on alias use:

The alias name for the opscenter key/certificate does not affect operation, but its use must be consistent; the steps below use "opscenter" for simplicity

Steps to upgrade OpsCenter with pre-existing custom certificates/keystore

If a custom keystore already exists prior to an upgrade, this should be backed up prior to the upgrade, and copied back in afterwards, as a custom keystore is not retained during an upgrade

Also, the password for the current keystore should be confirmed before the upgrade, as that will also be needed to be re-entered post upgrade

Before upgrade:

  1. Copy keystore_path to a backup location [outside of the OpsCenter folder structure]

  2. Confirm password used on current keystore (CurrentPassword) is known by testing

    path_to_keytool -list -keystore keystore_path

    If password is not known, it can be found as follows:

    1. Open the file below on the existing install:

      Windows: <install_path>\OpsCenter\gui\webserver\conf\server.xml
      Linux: /opt/SYMCOpsCenterGUI/webserver/conf/server.xml

    2. Locate the keystore and password section:

      keystoreFile="keystore_path" keystorePass="CurrentPassword”

    3. Make a note of “CurrentPassword”

Then upgrade OpsCenter as normal.

Post Upgrade:

  1. Stop the OpsCenter WebServer service.

  2. Copy keystore from the backup location to keystore_path

  3. Update configuration with the password for the pre-existing keystore:
    1. Open the below file in a text editor:

      Windows: <install_path>\OpsCenter\gui\webserver\conf\server.xml
      Linux: /opt/SYMCOpsCenterGUI/webserver/conf/server.xml

    2. Locate the keystore and password section:

      keystoreFile="keystore_path" keystorePass="RandomPassword"

    3. Replace "RandomPassword" with "CurrentPassword" as noted above.

  4. Start the OpsCenter WebServer service.

Steps to create a new keystore containing custom certificates:

  1. Stop the OpsCenter WebServer service.

  2. Rename or move the keystore file: keystore_path

  3. Create a new keystore with a public/private key pair for opscenter

    path_to_keytool -genkey -alias opscenter -keyalg RSA -keysize 2048 -keystore keystore_path -storepass opscenter

    Notes:

    • When prompted for your first/last name use the name of the OpsCenter server, not the name of the person creating the certificate.
    • press RETURN when prompted for a key password to ensure it is the same as the keystore password (tomcat needs them to be the same)
  4. Generate a certificate signing request (CSR) and store it in a file (certnew.req)

    path_to_keytool -certreq -keysize 2048 -alias opscenter -keystore keystore_path -file certnew.req -ext san=DNS:OpsCenter_Server_Name -storepass opscenter

    Notes:

    • Replace OpsCenter_Server_Name with the same name of the OpsCenter server as specified above. If more than one Subject Alternative Name is required, add it as a comma separated list, e.g  “-ext san=DNS:OpsCenter_Server_Name,DNS:OpsCenter_ShortName”
    • Subject Alternative names are only required if planning to use chrome 58+ or similar, as this browser requires the Subject Alternative Name (san) to be set as well as the common name , but it is best to include them to ensure the certificate will work in the largest range of browsers
  5. Send this certificate signing request to your chosen certificate signing authority website.

    You should receive the corresponding signed OpsCenter certificate as well any other certificates in the certificate chain (i.e. root + any intermediates). These certificates need to be saved as individual files in Base-64 encoded X.509 format (.cer). If the other certificates in the chain are received in a single file (e.g. p7b format) these should be extracted and saved as individual certificate files (.cer) as appropriate. If in doubt how to do so, please contact your certificate issuer.

    NOTE: Please ensure that your signing infrastructure returns a certificate that corresponds to the Certificate Signing Request that was sent – if this is not done, the public key in the CSR and the issued certificate will not match, and the certificate will not be able to be imported later

    For this example, it is assumed you have a three layer certificate infrastructure (root + one intermediate) and have saved the certificates received in files called certnew.cer, root.cer and intermediate.cer

  6. Import the root certificate into OpsCenter:

    path_to_keytool -import -alias root -file root.cer -keystore keystore_path -storepass opscenter

    Note:
    • When prompted to trust this certificate, type: "yes", or otherwise it will not be imported
  7. Import any intermediate certificates

    path_to_keytool -import -alias intermediate -file intermediate.cer -keystore keystore_path -storepass opscenter

    Note:
    • Repeat the above for any other intermediate certificates (if more than one, start at the one closest to the root, and use a different alias for each, e.g. intermediate_1, intermediate_2)
    • If there are no intermediate certificates (i.e. certificate was signed by the root CA), there would have been none to extract above, and this step would not be needed.
  8. Import the OpsCenter certificate:

    path_to_keytool -import -alias opscenter -file certnew.cer -keystore keystore_path -storepass opscenter

  9. Verify the keystore now contains the new certificates:

    path_to_keytool -list -keystore keystore_path -storepass opscenter

    (this should show a “trustedCertEntry” entry for the root and any intermediates, and a “PrivateKeyEntry” entry for the opscenter cert.)

  10. [Opscenter 8.1.1 and later only]

    If the password for the keystore is not the existing random password, the configuration needs to be updated with the password used:

    1. Open the below file in a text editor

      Windows: <install_path>\OpsCenter\gui\webserver\conf\server.xml
      Linux: /opt/SYMCOpsCenterGUI/webserver/conf/server.xml

    2. Locate the keystore and password section:

      keystoreFile="keystore_path" keystorePass="RandomPassword"

    3. Replace "RandomPassword" with "opscenter"
  11. Start the OpsCenter WebServer service

Testing the new certificate

  1. If it is not already present, import the root certificate signing authority certificate into the browser being used – different browsers store their CAs in different places
  2. Close and re-open browser
  3. Connect to OpsCenter using the name specified when the key was created [step 3 in previous section], or one of its specified Subject Alternative Names
  4. Verify that certificate warning message is no longer displayed

Renewing the custom certificate

As the custom certificate is generated outside of OpsCenter, the certificate cannot be auto renewed by OpsCenter itself, so the custom certificate will need to be updated prior to its expiry. To do so, a new certificate signing request (CSR) will need to be created for the existing public key, and this new CSR will need to be signed by the external CA to generate an updated certificate which is then imported

  1. Generate a certificate signing request (CSR) and store it in a file (certnew.req)

    path_to_keytool -certreq -keysize 2048 -alias opscenter -keystore keystore_path -file certnew.req -ext san=DNS:OpsCenter_Server_Name

    Notes:

    • Replace OpsCenter_Server_Name with the same name of the OpsCenter server as specified above. If more than one Subject Alternative Name is required, add it as a comma separated list, e.g “-ext san=DNS:OpsCenter_Server_Name,DNS:OpsCenter_ShortName
    • Subject Alternative names are only required if planning to use chrome 58+ or similar , as this browser requires the Subject Alternative Name (san) to be set as well as the common name , but it is best to include them to ensure the certificate will work in the largest range of browsers

       

  2. Send this certificate signing request to your chosen certificate signing authority website., and save the updated certificate in the file certnew.cer
  3. If the intermediate or root CA certificates being used have changed, these new certificates need to be imported (with different aliases to the previous ones) before the new OpsCenter certificate can be imported

    path_to_keytool -import -alias root_2 -file root.cer -keystore keystore_path
    path_to_keytool -import -alias intermediate_2 -file intermediate.cer -keystore keystore_path

    Note: If the renewed certificate is signed by the same intermediate/root CAs as the original, then this step is not required as the keystore already contains the root/intermediate certificates

  4. Import the renewed OpsCenter certificate:

    path_to_keytool -import -alias opscenter -file certnew.cer -keystore keystore_path
  5. Stop and restart the OpsCenter Webserver service. OpsCenter will then use this updated certificate which can be checked with a browser.

Was this content helpful?