Administer > Manage Certificates

Manage Certificates

This topic includes the following sections:

NNMi 10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of 10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded Environment to Use the New Keystore, skip to Use Certificates with the JKS Repository.

A certificate identifies the web server to the browser. This certificate can be self-signed or signed by a CA (Certificate Authority). The nnm-key.p12 file stores private keys and certificates with their corresponding public keys. The nnm-trust.p12 file contains certificates from other parties that you expect to communicate with, or from Certificate Authorities that you trust to identify other parties. NNMi includes a self-signed certificate in both of the nnm-key.p12 and nnm-trust.p12 files.

To use certain NNMi features, NNMi management servers need to share their certificates with one another. This chapter contains configuration instructions for copying these certificates among NNMi management servers and using the nnmcertmerge.ovpl script to merge these certificates into the nnm-key.p12 and nnm-trust.p12 files. This chapter also contains instructions to replace an expired certificate with a new self-signed or CA-signed certificate.

An administrator can disable HTTP and other unencrypted access from the network to NNMi.

About NNMi Certificates

This section describes useful terminology to help you work with certificates. Familiarize yourself with the terms mentioned in the following table.

Certificate Terminology

Concept

Description

Keystore and Truststore

Truststore: NNMi truststore is the file in which you store public keys from sources that you want NNMi to trust.

In a newly installed instance of NNMi, the name of the truststore file is nnm-trust.p12.

On a management server where NNMi was upgraded to the version 10.30 from an older version, the truststore file name is nnm.truststore. You can, however, perform additional steps (described in Configure an Upgraded NNMi Environment to Use the New Keystore) to migrate the nnm.truststore file to the nnm-trust.p12 file.

Keystore: NNMi keystore is the file in which you import NNMi server’s private key.

In a newly installed instance of NNMi, the name of the keystore file is nnm-key.p12.

On a management server where NNMi was upgraded to the version 10.30 from an older version, the keystore file name is nnm.keystore. You can, however, perform additional steps (described in Configure an Upgraded NNMi Environment to Use the New Keystore) to migrate the nnm.keystore file to the nnm-key.p12 file.

These files are located at:

  • Linux: $NNM_DATA/shared/nnm/certificates/

  • Windows: %NNM_DATA%\shared\nnm\certificates\

Default NNMi certificates

NNMi is installed with a self-signed certificate generated using default properties. You can replace the default certificate with another self-signed or CA-signed certificate.

Tools

Certificates are generated and managed using the nnmkeytool.ovpl utility (which uses Java's Keytool utility). Additionally, NNMi provides the nnmmergecert.ovpl utility to merge certificates to establish trust within NNMi systems. This program is used in HA, Failover, and GNM-RNM setups.

Supported encryption algorithms

NNMi accepts certificates generated using RSA algorithm. DSA algorithm is not supported.
Self-Signed Certificate

A Self-Signed certificate is typically used for establishing secure communication between your server and a known group of clients. NNMi installs with a self-signed certificate generated using default properties.

NNMi instances configured to use a self-signed certificate will display a warning message when users try to access NNMi web console in a web browser.
CA-Signed Certificate

Signed server certificate that you receive in response to the Certificate Signing Request will contain the NNMi certificate that is CA signed and one or more CA certificates (if there is more than one CA certificate, this is also known as the certificate chain).

These certificates might be in a single file or in a two separate files.
Root CA Certificate Identifies the certificate authority that is trusted to sign certificates for servers and users.
Intermediate CA Certificate

A certificate signed by either a root or intermediate CA that is itself an authority, rather than a server or user.

The list of certificates from the NNMi server certificate to the root CA certificate, including any intermediate CA certificates, is known as the certificate chain.

Configure an Upgraded NNMi Environment to Use the New Keystore

Prior to the version 10.20, NNMi used to provide a Java KeyStore (JKS) repository to store certificates. NNMi 10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi 10.20 on a system.

However, when you upgrade an older version of NNMi (older than 10.20) to the version 10.30, the PKCS #12 file-based certificate management does not immediately come into effect and NNMi continues to use the JKS repository for certificate management.

With additional configuration tasks, you can configure the upgraded NNMi management server to use the new technique of PKCS #12 file-based certificate management.

To configure the upgraded NNMi management server to use PKCS #12 file-based certificate management:

  1. Log on to the NNMi management server as root or administrator.

  2. Run the following command to migrate to the new keystore file:

    • On Windows:

      %nnminstalldir%\bin\nnmkeytool.ovpl -importkeystore -srckeystore %nnmdatadir%\shared\nnm\certificates\nnm.keystore -destkeystore %nnmdatadir%\shared\nnm\certificates\nnm-key.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername PKCS12 -alias<src_alias>

    • On Linux:

      /opt/OV/bin/nnmkeytool.ovpl -importkeystore -srckeystore /var/opt/OV/shared/nnm/certificates/nnm.keystore -destkeystore /var/opt/OV/shared/nnm/certificates/nnm-key.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername PKCS12 -alias<src_alias>

    The new certificate management technique enables you to retain only a single certificate in the keystore at a time. In this instance, <src_alias> is the alias of the certificate in the old keystore file that you want to migrate.

  3. Run the following command to migrate to the new truststore file:

    • On Windows:

      %nnminstalldir%\bin\nnmkeytool.ovpl -importkeystore -srckeystore %nnmdatadir%\shared\nnm\certificates\nnm.truststore -destkeystore %nnmdatadir%\shared\nnm\certificates\nnm-trust.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername PKCS12

    • On Linux:

      /opt/OV/bin/nnmkeytool.ovpl -importkeystore -srckeystore /var/opt/OV/shared/nnm/certificates/nnm.truststore -destkeystore /var/opt/OV/shared/nnm/certificates/nnm-trust.p12 -srcstoretype JKS -deststoretype PKCS12 -srcprovidername SUN -destprovidername PKCS12

  4. Open the server.properties file from the following location with a text editor:

    • On Windows: 

      %nnmdatadir%\nmsas\nms

    • On Linux: 

      /var/opt/OV/nmsas/nms
  5. Delete the existing content of the file.

  6. Add the following content to the file:

    nmsas.server.security.keystore.type=PKCS12
    nmsas.server.security.keystore.file=${com.hp.ov.DataDir}/shared/nnm/certificates/nnm-key.p12
    nmsas.server.keystore.cred=nnmkeypass
    nmsas.server.security.truststore.file=${com.hp.ov.DataDir}/shared/nnm/certificates/nnm-trust.p12
    nmsas.server.truststore.cred=ovpass
    nmsas.server.security.keystore.alias==
    nms.comm.soap.https.PROTOCOLS=TLSv1.2

    If you want to discover and monitor virtual networks running on VMware ESXi 5.1 servers, set the nms.comm.soap.https.PROTOCOLS property to TLSv1,TLSv1.1,TLSv1.2.

  7. Save the file.

  8. Open the nms-local.properties file from the following location with a text editor:

    • On Windows: 

      %nnmdatadir%\conf\nnm\props

    • On Linux: 

      /var/opt/OV/conf/nnm/props

  9. Modify the values of all the javax parameters:

    Parameter Value
    javax.net.ssl.trustStore ${NnmDataDir}/shared/nnm/certificates/nnm-trust.p12
    javax.net.ssl.trustStoreType PKCS12
    javax.net.ssl.keyStore ${NnmDataDir}/shared/nnm/certificates/nnm-key.p12
    javax.net.ssl.keyStoreType PKCS12
  10. Save the file.

  11. Delete the nnm.keystore and nnm.truststore files from the following directory

    • On Windows: 

      %nnmdatadir%\shared\nnm\certificates

    • On Linux: 

      /var/opt/OV/shared/nnm/certificates

  12. Restart NNMi.

Use Certificates with the PKCS #12 Repository

This section includes the following:

Prior to the version 10.20, NNMi used to provide a Java KeyStore (JKS) repository to store certificates. NNMi 10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi 10.20 on a system.

However, when you upgrade an older version of NNMi (older than 10.20) to the version 10.30, the PKCS #12 file-based certificate management does not immediately come into effect and NNMi continues to use the JKS repository for certificate management.

This section provides you with the procedures to work with certificates in a new installation of NNMi or an environment where the certificate repository is migrated to the PKCS#12 format.

To check the type of certificate repository:

  1. Log on to the NNMi console.
  2. Click Help > System Information, and then go to the Server tab.

  3. Check the value of the javax.net.ssl.keyStore property.

    If the property points to the nnm-key.p12 file, your environment has a PKCS#12 repository.

    If the property points to the nnm.keystore file, your environment has a JKS repository.

Alternatively, do the following:

  1. On the NNMi management server, as root or administer, run the following command:

    • On Windows: %nnminstalldir%\bin\nnmprops -l
    • On Linux: /opt/OV/bin/nnmprops -l

  2. From the command output, note the value of the javax.net.ssl.trustStoreType property.

    The value of this property indicates the type of certificate repository.

Generate a Self-Signed Certificate

NNMi10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.20 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded Environment to Use the New Keystore, skip to Generate a Self-Signed Certificate.

To generate a self-signed certificate:

  1. Change to the directory on the NNMi management server that contains the nnm-key.p12 and nnm-trust.p12 files:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  2. Save a backup copy of the nnm-key.p12 file.

    • If you are replacing an existing NNMi certificate, do not remove the existing certificate until you complete these steps. NNMi must start up at least once with both the old and new certificate installed so that it can transfer encrypted information to the new certificate.
    • Make sure the alias points to the new certificate as described in the next step to ensure NNMi presents the new certificate on the NNMi management server to the client servers.

  3. Delete the existing nnm-key.p12 file.

  4. Generate a private key from your system. Use the nnmkeytool.ovpl command to generate this private key:

    1. Run the following command exactly as shown:

      • Windows: %NnmInstallDir%\bin\nnmkeytool.ovpl -genkeypair -validity 3650 -keyalg rsa -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass-alias<alias_name>

      • Linux: $NnmInstallDir/bin/nnmkeytool.ovpl -genkeypair -validity 3650 -keyalg rsa -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass-alias<alias_name>

      The alias, referred to as <alias_name> in this example, identifies this newly-created key. Although the alias can be any string, recommends you use the fully-qualified domain name (FQDN) followed by a suffix to help you easily identify the right version. For example, you can use alias name as myserver.mydomain-<number> or myserver.mydomain-<date>.

    2. Enter the requested information.

      When prompted for your first and last name, enter the FQDN of your system.

      A self-signed certificate is generated.

      For obtaining CA-signed certificates, you need to additionally generate and submit a CSR file to a CA. For more information, see Generate a CA-Signed Certificate.

      recommends that you use CA-signed certificates.

Generate a CA-Signed Certificate

NNMi10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

To obtain and install a CA-signed certificate:

  1. Generate a self-signed certificate. For details, see Generate a Self-Signed Certificate.

  2. Run the following command to create a CSR (Certificate Signing Request) file:

    • Windows: %NnmInstallDir%\bin\nnmkeytool.ovpl -keystore nnm-key.p12 -certreq -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -file CERTREQFILE
    • Linux: $NnmInstallDir/bin/nnmkeytool.ovpl -keystore nnm-key.p12 -certreq -storetype PKCS12 -storepass nnmkeypass -alias <alias_name> -file CERTREQFILE

    In the command above, <alias_name> corresponds to the alias you had provided at the time of generating the certificate.

  3. Send the CSR to your CA signing authority which signs and returns the certificate files. For information on different types of CA certificates, see Types of CA-Signed Certificates.

    The CA signing authority returns one of the following:

    • A single signed server certificate file (referred to as myserver.crt in this section). The single file contains the server certificate (the NNMi certificate that is CA-signed), one or more intermediate CA certificates, and the root CA certificate. All the certificates in this single file form a certificate chain.

    • A set of two files that includes a signed server certificate file (referred to as myserver.crt in this section) and a separate file containing the CA certificates (referred to as the myca.crt file). The myserver.crt file contains either a single server certificate or a certificate chain, but NOT the root CA certificate, which remains in the myca.crt file.

    If your CA returns the certificates in other forms, contact the CA provider for more information about how to obtain the separate certificate chain and Root CA Certificate.

  4. Prepare the certificate files.

    The certificate chain must be imported to the keystore file and the root CA certificate must be imported to the truststore file. Additionally, if you installed iSPIs on the NNMi management server, you must import the server-signed certificate too to the truststore file.

    iSPIs that reside on the NNMi management server use NNMi's certificates.

    • If you received a single file from step 3

      1. Copy the root CA certificates from that file into a separate myca.crt file.
      2. (Only if you installed iSPIs on the NNMi management server) Copy the server certificate (the NNMi certificate that is CA-signed) from that file into a separate nnmi-server.crt file.

    • If you received a set of two files from step 3

      1. (Only if you installed iSPIs on the NNMi management server) Save a copy of the myserver.crt file as nnmi-server.crt.
      2. Add the myca.crt (the root CA certificate) file content to the end of the myserver.crt file and also remove any extra intermediate certificates from the myca.crt file, if it has any. This should result in one file, myserver.crt, containing the full certificate chain and one file, myca.crt, containing the Root CA Certificate.

  5. Copy the files containing these certificates to a location on the NNMi management server. For this example, copy the files to the following location:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  6. Change to the directory on the NNMi management server that contains the keystore and truststore files:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  7. Run the following command to import the certificate into the keystore file:

    Windows:
    %NnmInstallDir%\bin\nnmkeytool.ovpl -importcert -trustcacerts -keystore
    nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -file     <path_to_myserver.crt>

    Linux:

    $NnmInstallDir/bin/nnmkeytool.ovpl -importcert -trustcacerts -keystore
    nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -file     <path_to_myserver.crt>

    In the above command, <path_to_myserver.crt> corresponds to the full path of the location where you have stored the CA-signed server certificate.

  8. When prompted to trust the certificate, enter: y

    Example output for importing a certificate into the keystore

    The output from the command is of the form:

    Owner: CN=NNMi_server.example.com
    Issuer: CN=NNMi_server.example.com
    Serial number: 494440748e5
    Valid from: Tue Oct 28 10:16:21 MST 2008 until: Thu Oct 04 11:16:21 MDT 2108
    Certificate fingerprints:
    MD5:  29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
    SHA1: C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
    Trust this certificate? [no]:  y
    Certificate was added to keystore

  9. Run the following commands to import the root certificate into the truststore file:

    • Windows:

      %NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias<alias_name>-storetype PKCS12 -keystore nnm-trust.p12 -file<path_to_myca.crt>-storepass ovpass

    • Linux:

      $NnmInstallDir/bin/nnmkeytool.ovpl -import -alias<alias_name>-storetype PKCS12 -keystore nnm-trust.p12 -file<path_to_myca.crt>-storepass ovpass

    In the above command,

    • <path_to_myca.crt> corresponds to the full path of the location where you have stored the root certificate.
    • <alias_name> corresponds to the alias you had provided at the time of generating the certificate.

  10. Examine the contents of the truststore:

    • Windows: 

      %NnmInstallDir%\bin\nnmkeytool.ovpl -list -keystore nnm-trust.p12 -storetype PKCS12

    • Linux: 

      $NnmInstallDir/bin/nnmkeytool.ovpl -list -keystore nnm-trust.p12 -storetype PKCS12

    When prompted for the truststore password, enter: ovpass

    Example truststore output

    The truststore output is of the form:

    Keystore type: pkcs
    Keystore provider: JKS
    Your keystore contains 1 entry
    nnmi_ldap, Nov 14, 2008, trustedCertEntry,
    Certificate fingerprint (MD5): 29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

    The truststore can include multiple certificates.

  11. Import the server certificate (the NNMi certificate that is CA-signed) into the truststore file.

    Follow this step only if you installed iSPIs on the NNMi management server.

    Run the following commands to import the CA-signed server certificate into the truststore file:

    • Windows:

      %NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias<alias_name>-storetype PKCS12 -keystore nnm-trust.p12 -file<path_to_nnmi-server.crt>-storepass ovpass

    • Linux:

      $NnmInstallDir/bin/nnmkeytool.ovpl -import -alias<alias_name>-storetype PKCS12 -keystore nnm-trust.p12 -file<path_to_nnmi-server.crt> -storepass ovpass

       

      In the above command,

      • <path_to_nnmi-server.crt> corresponds to the full path of the location where you have stored the server certificate (the NNMi certificate that is CA-signed).
      • <alias_name> corresponds to the alias you had provided at the time of generating the certificate.

Types of CA-Signed Certificates

If your CA returns the certificates in other forms, contact the CA provider for instructions about obtaining the certificate chain and the Root CA Certificate.

The Certificate Authority (CA) should provide you with one of the following:

  • A signed server certificate file containing the server certificate (the NNMi certificate that is CA signed) and one or more CA certificates. This section refers to the signed server certificate as myserver.crt.

    A CA Certificate can be either of the following:

    • Root CA Certificate - Identifies the authority that is trusted to sign certificates for servers and users.

    • Intermediate CA Certificate - A certificate signed by either a root or intermediate CA that is itself an authority, rather than a server or user.

      The list of certificates from the NNMi server certificate to the root CA certificate, including any intermediate CA certificates, is known as the certificate chain.

  • A signed server certificate and a separate file containing one or more CA certificates. This section refers to the signed server certificate as myserver.crt and the CA certificates as myca.crt. The myserver.crt file should contain either a single server certificate or a certificate chain, but NOT the root CA certificate, which would be in the myca.crt file.

To configure NNMi with the new certificate, you must import the certificate chain into the nnm-key.p12 and the root CA Certificate into the nnm-trust.p12. Use the myserver.crt file when importing the server certificate into the nnm-key.p12 file and the myca.crt file when importing the CA certificate into the nnm-trust.p12 file.

If your CA returns the certificates in other forms, contact the CA provider for instructions about obtaining the separate certificate chain and root CA Certificate.

When provided with one file that contains a full certificate chain, copy the root CA certificate from that file into the myca.crt file. Use the myca.crt file to import into the nnm-trust.p12 so that NNMi trusts the CA that issued the certificate.

When provided two files, add the myca.crt file content to the end of the myserver.crt, if the file does not include it. Also, be sure to remove any extra intermediate certificates from the myca.crt file. This should result in the following files:

  • myserver.crt, containing the full certificate chain
  • myca.crt, containing the root CA Certificate

When using a CA, only the root CA certificate is generally added to the nnm-trust.p12. Adding intermediate CA or server certificates to the nnm-trust.p12 will cause those certificates to be explicitly trusted and not checked for additional information, such as revocation. Only add additional certificates to the nnm-trust.p12 if your CA requires it.

The following examples show what the files received from a CA signing authority might look like:

Separate server and CA certificate files:

-----BEGIN CERTIFICATE-----
Sample/AVQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3Js
eGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNb
pSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----

Combined server and CA certificates in one file:

-----BEGIN CERTIFICATE-----
Sample1/VQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3Js
eGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNb
pSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Sample2/Gh0dHA6Ly9jb3JwMWRjc2cyLnNnLmludC5wc2FnbG9iYWwuY29tL0Nlc
RaOCApwwggKYMB0GA1UdDgQWBBSqaWZzCRcpvJWOFPZ/Be9b+QSPyDAfBgNVHSMC
................................................................
................................................................
Wp5Lz1ZJAOu1VHbPVdQnXnlBkx7V65niLoaT90Eqd6laliVlJHj7GBriJ90uvVGu
BQagggEChoG9bGRhcDovLy9DTj1jb3JwMWRjc2cyL==
-----END CERTIFICATE-----

Delete a Certificate from the NNMi Keystore

The NNMi keystore can hold only one certificate at a time. Before replacing or renewing a certificate on the NNMi management server, you must delete the existing certificate from the NNMi keystore.

To delete a certificate from the NNMi keystore:

  1. Change to the directory on the NNMi management server that contains the nnm-key.p12 and nnm-trust.p12 files:

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  2. Save a backup copy of the nnm-key.p12 file.

  3. Examine the contents of the keystore, and then note down the alias of the existing certificate:

    • Windows: 

      %NnmInstallDir%\bin\nnmkeytool.ovpl -list -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

    • Linux: 

      $NnmInstallDir/bin/nnmkeytool.ovpl -list  -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

  4. Delete the existing certificate from keystore by running the following command:

    • Windows: %NnmInstallDir%\bin\nnmkeytool.ovpl -delete -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias>

    • Linux: $NnmInstallDir/bin/nnmkeytool.ovpl -delete -keystore nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass -alias <alias>

      The alias, referred to as <alias> in this example, identifies the existing certificate.

  5. Restart NNMi by running the following commands:

    Changes take effect only after restarting NNMi.

    • Windows:

      • %NnmInstallDir%\bin\ovstop -c
      • %NnmInstallDir%\bin\ovstart -c

    • Linux:

    • $NnmInstallDir/bin/ovstop -c
    • $NnmInstallDir/bin/ovstart -c

Replace an Existing Certificate with a new Self-Signed or CA-Signed Certificate

A self-signed certificate is created and installed during NNMi installation. You would typically replace a certificate in any of the following scenarios:

  • To use a new self-signed or CA-signed certificate instead of the default certificate.
  • To renew an expired certificate.

To replace a certificate, do the following:

  1. Generate a self-signed certificate. For details, see Generate a Self-Signed Certificate.

    Or, if you organization requires the certificate to be signed by a CA, generate a CSR (Certificate Signing Request) file and obtain a CA signed certificate. For details, see Generate a CA-Signed Certificate

  2. Delete the existing certificate from NNMi keystore by following the instructions in Delete a Certificate from the NNMi Keystore.

  3. Test HTTPS access to the NNMi console using the following syntax:

    https://<fully_qualified_domain_name>:<port_number>/nnm/.

    If you have used CA-signed certificate and if the browser trusts the CA, it will trust the HTTPS connection to the NNMi console.

    If you have used self-signed certificate, browser displays a warning message about the untrusted HTTPS connection to the NNMi Console.

Work with Certificates in Application Failover Environments

Use Certificates with Application Failover

NNMi10.30 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded Environment to Use the New Keystore, skip to Work with Certificates in Application Failover Environments.

When configuring the application failover feature, you must merge the content of the truststore file for both nodes into one nnm-trust.p12 file.

Complete the following steps to configure the application failover feature to use self-signed or CA-signed certificates.

If you are using self-signed certificates with NNMi along with the application failover feature, and do not complete the following steps, NNMi processes will not start correctly on the standby NNMi management server (Server Y in this example).

  1. Change to the following directory on Server Y :

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates
  2. Copy the nnm-trust.p12 file from Server Y to some temporary location on Server X. The remaining steps refer to these file locations as <truststore>.

  3. Run the following command on Server X to merge Server Y’s truststore into Server X’s nnm-trust.p12 file.

    Windows: 

    nnmcertmerge.ovpl -truststore <truststore>

    Linux:

    nnmcertmerge.ovpl -truststore <truststore>

  4. Copy the merged nnm-trust.p12 file from server X to server Y, so that both nodes have the merged files. The location of this file is as follows:

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  5. Run the following command on both Server X and Server Y. Verify that the displayed results from both servers, including the fully-qualified-domain names, match. If they do not match do not continue, rather redo 1 through 1.

    Windows: 

    %NnmInstallDir%\bin\nnmkeytool.ovpl -list -keystore %NnmDataDir%\shared\nnm\certificates\nnm-trust.p12
    -storetype PKCS12 -storepass ovpass

    Linux: 

    $NnmInstallDir/bin/nnmkeytool.ovpl -list -keystore $NnmDataDir/shared/nnm/certificates/nnm-trust.p12 -storetype PKCS12 -storepass ovpass

  6. Continue configuring the application failover feature at "Configure for Application Failover" .

Work with Certificates in High-Availability Environments

This section describes how to configure NNMi to use Self-Signed or Certificate Authority Certificates in an HA environment.

Use Certificates with HA

NNMi10.30 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded Environment to Use the New Keystore, skip to Work with Certificates in High-Availability Environments.

Configure High-Availability Using Default Certificates

The process for configuring NNMi for HA correctly shares the default self-signed certificate among the primary and secondary cluster nodes. You do not need to take any extra steps to use the default certificate with NNMi running under HA.

Configure High-Availability Using New Certificates

This section creates a new self-signed or CA certificate, referred to as newcert. Complete the following steps to configure HA with this new CA or self-signed certificate.

When making file changes under High Availability (HA), you must make the changes on both nodes in the cluster. If the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.

You can complete this procedure before or after configuring NNMi for HA

  1. Change to the following directory on NNMi_HA1 before completing step 2:

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  2. On NNMi_HA1, run the following commands to import newcert into the nnm-key.p12 file:

    • Windows: %NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias newcert_Alias -storetype PKCS12 -keystore nnm-key.p12 -file newcert
    • Linux: $NnmInstallDir/bin/nnmkeytool.ovpl -import -alias newcert_Alias -storetype PKCS12 -keystore nnm-key.p12 -file newcert

Work with Certificates in Global Network Management Environments

NNMi10.30 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded NNMi Environment to Use the New Keystore, skip to Configure Certificates in Global Network Management Environments.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded Environment to Use the New Keystore.

Configure Certificates in Global Network Management Environments

During NNMi installation, the installation script creates a self-signed certificate for the NNMi management server. This certificate contains an alias that includes the fully-qualified domain name of the node. The installation script adds this self-signed certificate to the NNMi management server’s nnm-key.p12 and nnm-trust.p12 files.

Complete the following steps to configure the global network management feature to use self-signed/CA-signed certificates based on the following diagram.

Before you begin, make sure that the required certificates are created on the regional manager systems. For details, see Replace an Existing Certificate with a new Self-Signed or CA-Signed Certificate.

If you are using a mix of newly installed NNMi 10.30 instances and NNMi management servers upgraded to the version 10.30 from an older version, follow the guideline in Configure an Upgraded Environment to Use the New Keystore.

Global Network Management

  1. Change to the following directory on regional1 and regional2 :

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates
  2. Copy the nnm-trust.p12 files from the above locations on regional1 and regional2 to some temporary location on global1.

  3. Run the following command on global1 to merge the regional1 and regional2 certificates into global1’s nnm-trust.p12 file.

    Windows:

    1. nnmcertmerge.ovpl -truststore regional1_nnm-trust.p12_location
    2. nnmcertmerge.ovpl -truststore regional2_nnm-trust.p12_location

    Linux

    1. nnmcertmerge.ovpl -truststore regional1_nnm-trust.p12_location
    2. nnmcertmerge.ovpl -truststore regional2_nnm-trust.p12_location

  4. Run the following command sequence on global1:

    1. Run ovstop on the global1NNMi management server.
    2. Run ovstart on the global1NNMi management server.

    When making file changes under High Availability (HA), you need to make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.

Configure Certificates in Global Network Management Environments with Failover

During NNMi installation the installation script creates a self-signed certificate for the NNMi management server. This certificate contains an alias that includes the fully-qualified domain name of the node. The installation script adds this self-signed certificate to the NNMi management server’s nnm-key.p12 and nnm-trust.p12 files.

If you are using a mix of newly installed NNMi 10.30 instances and NNMi management servers upgraded to the version 10.30 from an older version, follow the guideline in Configure an Upgraded Environment to Use the New Keystore.

This example uses the global network management configuration with the application failover feature as shown in the following diagram:

Global Network Management with Application Failover

Complete the following steps to configure the global network management feature to work with application failover based on the above diagram:

  1. Follow the instructions shown in Work with Certificates in Application Failover Environments for each application failover cluster shown in the above diagram.
  2. Complete the configuration for application failover shown in "Application Failover Basic Setup" .
  3. Follow the instructions shown in Configure Certificates in Global Network Management Environments for regional1_active and regional2_active.

Configure an SSL Connection to the Directory Service

NNMi10.30 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi10.30 on a system. Environments upgraded from an older version of NNMi continue to use a JKS repository to store certificates.

In upgraded environments, you can migrate to the PKCS #12 repository by using the steps in Configure an Upgraded NNMi Environment to Use the New Keystore.

If you have upgraded to NNMi10.30 and did not complete the steps in Configure an Upgraded Environment to Use the New Keystore, skip to Configure an SSL Connection to the Directory Service.

By default, when directory service communications are enabled, NNMi uses the LDAP protocol for retrieving data from a directory service. If your directory service requires an SSL connection, you must enable the SSL protocol to encrypt the data that flows between NNMi and the directory service.

SSL requires a trust relationship between the directory service host and the NNMi management server. To create this trust relationship, add a certificate to the NNMi truststore. The certificate confirms the identity of the directory service host to the NNMi management server.

To install a truststore certificate for SSL communications:

  1. Obtain your company’s truststore certificate from the directory server. The directory service administrator should be able to give you a copy of this text file.

  2. Change to the directory that contains the NNMi truststore:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

    Run all commands in this procedure from the certificates directory.

  3. Import your company’s truststore certificate into the NNMi truststore:

    Import the root CA certificate of the LDAP directory server (without intermediate certificates) into the NNMi truststore.

    1. Run the following command:

      • Windows:

        %NnmInstallDir%\bin\nnmkeytool.ovpl -import
        -alias nnmi_ldap -storetype PKCS12 -keystore nnm-trust.p12
        -file <Directory_Server_Certificate.txt>

      • Linux:

        $NnmInstallDir/bin/nnmkeytool.ovpl -import
        -alias nnmi_ldap -storetype PKCS12 -keystore nnm-trust.p12
        -file <Directory_Server_Certificate.txt>

        Where <Directory_Server_Certificate.txt> is your company’s truststore certificate.

    2. When prompted for password, enter: ovpass

    3. When prompted to trust the certificate, enter: y

      Example output for importing a certificate into the truststore

      The output from this command is of the form:

      Owner: CN=NNMi_server.example.com
      Issuer: CN=NNMi_server.example.com
      Serial number: 494440748e5
      Valid from: Tue Oct 28 10:16:21 MST 2008 until: Thu Oct 04 11:16:21 MDT 2108
      Certificate fingerprints:
      MD5:  29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
      SHA1: C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
      Trust this certificate? [no]:  y
      Certificate was added to keystore

  4. Examine the contents of the truststore:

    • Windows: 

       %NnmInstallDir%\bin\nnmkeytool.ovpl -list
      -storetype PKCS12 -keystore nnm-trust.p12

    • Linux: 

      $NnmInstallDir/bin/nnmkeytool.ovpl -list
      -storetype PKCS12 -keystore nnm-trust.p12

    When prompted for the keystore password, enter: ovpass

    Example truststore output

    The truststore output is of the form:

    Keystore type: jks
    Keystore provider: SUN
    Your keystore contains 1 entry
    nnmi_ldap, Nov 14, 2008, trustedCertEntry,
    Certificate fingerprint (MD5): 29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

    The truststore can include multiple certificates.

  5. Restart the NNMi management server.

    1. Run the ovstop command on the NNMi management server.

    2. Run the ovstart command on the NNMi management server.

      When making file changes under High Availability (HA), you must make the changes on both nodes in the cluster. If the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands. See "Maintenance Mode" for more information.

Use Certificates with the JKS Repository

This section includes the following:

Prior to the version 10.20, NNMi used to provide a Java KeyStore (JKS) repository to store certificates. NNMi 10.20 introduces a Public Key Cryptography Standards (PKCS) #12 repository to store certificates. The new PKCS #12 file-based certificate management technique is available for use as soon as you install a new instance of NNMi 10.20 on a system.

However, when you upgrade an older version of NNMi (older than 10.20) to the version 10.30, the PKCS #12 file-based certificate management does not immediately come into effect and NNMi continues to use the JKS repository for certificate management.

If you like, you can continue with the older JKS repository of certificates. This section provides you with instructions to use certificates when you want to continue to use the JKS repository of certificates. Do not use the information in this section if your NNMi environment uses the PKCS#12 repository.

To check the type of certificate repository:

  1. Log on to the NNMi console.
  2. Click Help > System Information, and then go to the Server tab.

  3. Check the value of the javax.net.ssl.keyStore property.

    If the property points to the nnm-key.p12 file, your environment has a PKCS#12 repository.

    If the property points to the nnm.keystore file, your environment has a JKS repository.

Alternatively, do the following:

  1. On the NNMi management server, as root or administer, run the following command:

    • On Windows: %nnminstalldir%\bin\nnmprops -l
    • On Linux: /opt/OV/bin/nnmprops -l

  2. From the command output, note the value of the javax.net.ssl.trustStoreType property.

    The value of this property indicates the type of certificate repository.

Many tasks in this section require you to use the keytool utility. The location of the keytool utility on the NNMi management server depends on the type of JDK configured with NNMi. To find out the location of the keytool utility:

  1. On the NNMi management server, as root or administer, run the following command:

    • On Windows:%nnminstalldir%\bin\nnmprops -l
    • On Linux:/opt/OV/bin/nnmprops -l

  2. From the command output, note the value of the property com.hp.ov.nms.jdk.dir. This value indicates the home directory of JDK.

    The keytool utility resides within the bin directory under this JDK home directory.

To be able to access the keytool utility easily, you can create an environment variable (for example, jdkdir) that points to this JDK home directory.

About NNMi JKS Certificates

Certificate Terminology

Concept

Description

Keystore and Truststore

Truststore: NNMi truststore is the nnm.truststore file in which you store public keys from sources that you want NNMi to trust.

Keystore: NNMi keystore is the nnm.keystore file in which you import NNMi server’s private key.

The nnm.truststore and nnm.keystrore files are located at:

  • Linux: $NNM_DATA/shared/nnm/certificates/

  • Windows: %NNM_DATA%\shared\nnm\certificates\

Default NNMi certificates

NNMi is installed with a self-signed certificate generated using default properties. You can replace the default certificate with another self-signed or CA-signed certificate.

Tools

Certificates are generated and managed using Java's Keytool utility. Additionally, NNMi provides the nnmmergecert.ovpl utility to merge certificates to establish trust within NNMi systems. This program is used in HA, Failover, and GNM-RNM setups.

Supported encryption algorithms

NNMi accepts certificates generated using RSA algorithm. DSA algorithm is not supported.
Self-Signed Certificate

A Self-Signed certificate is typically used for establishing secure communication between your server and a known group of clients. NNMi installs with a self-signed certificate generated using default properties.

NNMi instances configured to use a self-signed certificate will display a warning message when users try to access NNMi web console in a web browser.
CA-Signed Certificate

Signed server certificate that you receive in response to the Certificate Signing Request will contain the NNMi certificate that is CA signed and one or more CA certificates (if there is more than one CA certificate, this is also known as the certificate chain).

These certificates might be in a single file or in a two separate files.
Root CA Certificate Identifies the certificate authority that is trusted to sign certificates for servers and users.
Intermediate CA Certificate

A certificate signed by either a root or intermediate CA that is itself an authority, rather than a server or user.

The list of certificates from the NNMi server certificate to the root CA certificate, including any intermediate CA certificates, is known as the certificate chain.

Replace an Existing Certificate with a New Self-Signed or CA-Signed Certificate

A self-signed certificate is created and installed during NNMi installation. You would typically replace a certificate in any of the following scenarios:

  • To use a new self-signed or CA-signed certificate instead of the default certificate.
  • To renew an expired certificate.

To replace a certificate, do the following:

  1. Generate a self-signed certificate. For details, see Generate a Self-Signed Certificate.

  2. If you organization requires the certificate to be signed by a CA, generate a CSR (Certificate Signing Request) file and obtain a CA signed certificate. For details, see Generate a CA-Signed CertificateGenerating a CA-Signed Certificate

  3. Open the following file and update the com.hp.ov.nms.ssl.KEY_ALIAS variable to the value you used for <alias> while generating a certificate.

    • Windows: %NNM_CONF%\nnm\props\nms-local.properties
    • Linux: $NNM_CONF/nnm/props/nms-local.properties
  4. Restart the NNMi Management Server.

    1. Run the ovstop command on the NNMi management server.

    2. Run the ovstart command on the NNMi management server.

      When making file changes under High Availability (HA), you need to make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.

  5. Test HTTPS access to the NNMi console using the following syntax:

    https://<fully_qualified_domain_name>:<port_number>/nnm/.

    If you have used CA-signed certificate and if the browser trusts the CA, it will trust the HTTPS connection to the NNMi console.

    If you have used self-signed certificate, browser displays a warning message about the untrusted HTTPS connection to the NNMi Console.

Generate a Self-Signed Certificate

To generate a self-signed certificate:

  1. Change to the directory on the NNMi management server that contains the nnm.keystore and nnm.truststore files:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  2. Save a backup copy of the nnm.keystore file.

    • If you are replacing an existing NNMi certificate, do not remove the existing certificate until you complete these steps. NNMi must start up at least once with both the old and new certificate installed so that it can transfer encrypted information to the new certificate.
    • Make sure the alias points to the new certificate as described in the next step to ensure NNMi presents the new certificate on the NNMi management server to the client servers.
  3. Generate a private key from your system. Use the keytool command to generate this private key:

    1. Run the following command exactly as shown:

      • Windows: %jdkdir%\bin\keytool.exe -genkeypair - validity 3650 -keyalg rsa -keystore nnm.keystore -storepass nnmkeypass - alias <alias_name>

      • Linux: $jdkdir/bin/keytool -genkeypair -validity 3650 -keyalg rsa -keystore nnm.keystore -storepass nnmkeypass -alias <alias_name>

        The alias, referred to as <alias_name> in this example, identifies this newly-created key. Although the alias can be any string, recommends you use the fully-qualified domain name (FQDN) followed by a suffix to help you easily identify the right version. For example, you can use alias name as myserver.mydomain-<number> or myserver.mydomain-<date>.

    2. Enter the requested information.

      When prompted for your first and last name, enter the FQDN of your system.

      A self-signed certificate is generated.

      For obtaining CA-signed certificates, you need to additionally generate and submit a CSR file to a CA. For more information, see Generate a CA-Signed Certificate.

      recommends that you use CA-signed certificates.

Generate a CA-Signed Certificate

To obtain and install a CA-signed certificate:

  1. Generate a self-signed certificate. For details, see Generate a Self-Signed Certificate.

  2. Run the following command to create a CSR (Certificate Signing Request) file:

    • Windows:%jdkdir%\bin\keytool.exe -keystore nnm.keystore -certreq -storepass nnmkeypass -alias <alias_name> -file CERTREQFILE
    • Linux: $jdkdir/bin/keytool -keystore nnm.keystore -certreq -storepass nnmkeypass -alias <alias_name> -file CERTREQFILE
    • In the command above, <alias_name> corresponds to the alias you had provided at the time of generating the certificate.
    • For more information about the keytool command, search for “Key and Certificate Management Tool” at http://www.oracle.com/technetwork/java/index.html.
  3. Send the CSR to your CA signing authority which signs and returns the certificate files. For information on different types of CA certificates, see Types of CA-Signed Certificates.

  4. Copy the files containing these certificates to a location on the NNMi management server. For this example, copy the files to the following location:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  5. Change to the directory on the NNMi management server that contains the nnm.keystore and nnm.truststore files:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  6. Run the following command to import the certificate into the nnm.keystore file:

    Windows:

    • %jdkdir%\bin\keytool.exe -importcert -trustcacerts -keystore nnm.keystore -storepass nnmkeypass -alias <alias_name> -file <myserver.crt>

    Linux:

    • $jdkdir/bin/keytool -importcert -trustcacerts -keystore nnm.keystore -storepass nnmkeypass -alias <alias_name> -file <myserver.crt>

      • In the above command,
        • <myserver.crt> corresponds to the full path of the location where you have stored the signed server certificate.
        • <alias_name> corresponds to the alias you had provided at the time of generating the certificate.
      • If you use the -storepass option and provide the password, the keystore program does not prompt you for the keystore password. If you do not use the -storepass option, enter nnmkeypass when prompted for the keystore password.

  7. When prompted to trust the certificate, enter: y

    Example output for importing a certificate into the keystore

    The output from the command is of the form:

    Owner: CN=NNMi_server.example.com
    Issuer: CN=NNMi_server.example.com
    Serial number: 494440748e5
    Valid from: Tue Oct 28 10:16:21 MST 2008 until: Thu Oct 04 11:16:21 MDT 2108
    Certificate fingerprints:
    MD5:  29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
    SHA1: C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
    Trust this certificate? [no]:  y
    Certificate was added to keystore

  8. Run the following commands to import the certificate into the nnm.truststore file:

    • Windows: 

      %jdkdir%\bin\keytool.exe -import -alias <alias_name> -keystore nnm.truststore -file <myca.crt>

    • Linux: 

      $jdkdir/bin/keytool -import -alias <alias_name> -keystore nnm.truststore -file <
      myca.crt>
      • In the above command,
        • <myca.crt> corresponds to the full path of the location where you have stored the CA certificates.
        • <alias_name> corresponds to the alias you had provided at the time of generating the certificate.
      • If you use the -storepass option and provide the password, the keystore program does not prompt you for the keystore password. If you do not use the -storepass option, enter nnmkeypass when prompted for the keystore password.
  9. When prompted for the truststore password, enter: ovpass.
  10. Examine the contents of the truststore:

    • Windows: 

      %jdkdir%\bin\keytool -list -keystore nnm.truststore

    • Linux: 

      $jdkdir/bin/keytool -list -keystore nnm.truststore

    When prompted for the truststore password, enter: ovpass

    Example truststore output

    The truststore output is of the form:

    Keystore type: jks
    Keystore provider: SUN
    Your keystore contains 1 entry
    nnmi_ldap, Nov 14, 2008, trustedCertEntry,
    Certificate fingerprint (MD5): 29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

    The truststore can include multiple certificates.

Types of CA-Signed Certificates

If your CA returns the certificates in other forms, contact the CA provider for instructions about obtaining the certificate chain and the Root CA Certificate.

The Certificate Authority (CA) should provide you with one of the following:

  • A signed server certificate file containing the server certificate (the NNMi certificate that is CA signed) and one or more CA certificates. This section refers to the signed server certificate as myserver.crt.

    A CA Certificate can be either of the following:

    • Root CA Certificate - Identifies the authority that is trusted to sign certificates for servers and users.

    • Intermediate CA Certificate - A certificate signed by either a root or intermediate CA that is itself an authority, rather than a server or user.

      The list of certificates from the NNMi server certificate to the root CA certificate, including any intermediate CA certificates, is known as the certificate chain.

  • A signed server certificate and a separate file containing one or more CA certificates. This section refers to the signed server certificate as myserver.crt and the CA certificates as myca.crt. The myserver.crt file should contain either a single server certificate or a certificate chain, but NOT the root CA certificate, which would be in the myca.crt file.

To configure NNMi with the new certificate, you must import the certificate chain into the nnm.keystore and the root CA Certificate into the nnm.truststore. Use the myserver.crt file when importing the server certificate into the nnm.keystore file and the myca.crt file when importing the CA certificate into the nnm.truststore file.

If your CA returns the certificates in other forms, contact the CA provider for instructions about obtaining the separate certificate chain and root CA Certificate.

When provided with one file that contains a full certificate chain, copy the root CA certificate from that file into the myca.crt file. Use the myca.crt file to import into the nnm.truststore so that NNMi trusts the CA that issued the certificate.

When provided two files, add the myca.crt file content to the end of the myserver.crt, if the file does not include it, and also remove any extra intermediate certificates from the myca.crt, if it has any. This should result in one file, myserver.crt, containing the full certificate chain and one file, myca.crt, containing the root CA Certificate.

When using a CA, only the root CA certificate is generally added to the nnm.truststore. Adding intermediate CA or server certificates to the nnm.truststore will cause those certificates to be explicitly trusted and not checked for additional information, such as revocation. Only add additional certificates to the nnm.truststore if your CA requires it.

The following examples show what the files received from a CA signing authority might look like:

Separate server and CA certificate files:

-----BEGIN CERTIFICATE-----
Sample/AVQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3Js
eGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNb
pSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----

Combined server and CA certificates in one file:

-----BEGIN CERTIFICATE-----
Sample1/VQQKExNQU0EgQ29ycG9yYXRpb24gTHRkMRAwDgYDVQQLEwdOZXR3b3Js
eGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlw
................................................................
................................................................
TZImiZPyLGQBGRYDaW50MRIwEAYKCZImiZPyLGQBGRYCc2cxEzARBgNVBAMTCmNb
pSo6o/76yShtT7Vrlfz+mXjWyEHaIy/QLCpPebYhejHEg4dZgzWWT/lQt==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Sample2/Gh0dHA6Ly9jb3JwMWRjc2cyLnNnLmludC5wc2FnbG9iYWwuY29tL0Nlc
RaOCApwwggKYMB0GA1UdDgQWBBSqaWZzCRcpvJWOFPZ/Be9b+QSPyDAfBgNVHSMC
................................................................
................................................................
Wp5Lz1ZJAOu1VHbPVdQnXnlBkx7V65niLoaT90Eqd6laliVlJHj7GBriJ90uvVGu
BQagggEChoG9bGRhcDovLy9DTj1jb3JwMWRjc2cyL==
-----END CERTIFICATE-----

Work with Certificates in Application Failover Environments

Use Certificates with Application Failover

When configuring the application failover feature, you must merge the content of the nnm.keystore and nnm.truststore files for both nodes into one nnm.keystore file and one nnm.truststore file.

Complete the following steps to configure the application failover feature to use self-signed or CA-signed certificates.

If you are using self-signed certificates with NNMi along with the application failover feature, and do not complete the following steps, NNMi processes will not start correctly on the standby NNMi management server (Server Y in this example).

  1. Change to the following directory on Server Y :

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates
  2. Copy the nnm.keystore and nnm.truststore files from Server Y to some temporary location on Server X. The remaining steps refer to these file locations as <keystore> and <truststore>.

  3. Run the following command on Server X to merge Server Y’s certificates into Server X’s nnm.keystore and nnm.truststore files.

    Windows: 

    nnmcertmerge.ovpl -keystore <keystore> -truststore <truststore>

    Linux:

    nnmcertmerge.ovpl -keystore <keystore> -truststore <truststore>

  4. Copy the merged nnm.keystore and nnm.truststore files from server X to server Y, so that both nodes have the merged files. The location of these files is as follows:

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  5. Run the following command on both Server X and Server Y. Verify that the displayed results from both servers, including the fully-qualified-domain names, match. If they do not match do not continue, rather redo 1 through 1.

    Windows: 

    %jdkdir%\bin\keytool.exe -list -keystore %NnmDataDir%\shared\nnm\certificates\nnm.keystore -storepass nnmkeypass

    Linux: 

    $jdkdir/bin/keytool -list -keystore $NnmDataDir/shared/nnm/certificates/nnm.keystore -storepass nnmkeypass

  6. Run the following command on both Server X and Server Y. Verify that the displayed results from both servers, including the fully-qualified-domain names, match. If they do not match do not continue, rather redo 1 through 1.

    Windows: 

    %jdkdir%\bin\keytool.exe -list -keystore %NnmDataDir%\shared\nnm\certificates\nnm.truststore
    -storepass ovpass

    Linux: 

    $jdkdir/bin/keytool -list -keystore $NnmDataDir/shared/nnm/certificates/nnm.truststore -storepass ovpass

  7. Continue configuring the application failover feature at "Configuring for Application Failover" .

Work with Certificates in High-Availability Environments

This section describes how to configure NNMi to use Self-Signed or Certificate Authority Certificates in an HA environment.

Use Certificates with HA

Configure High-Availability Using Default Certificates

The process for configuring NNMi for HA correctly shares the default self-signed certificate among the primary and secondary cluster nodes. You do not need to take any extra steps to use the default certificate with NNMi running under HA.

Configure High-Availability Using New Certificates

This section creates a new self-signed or CA certificate, referred to as newcert. Complete the following steps to configure HA with this new CA or self-signed certificate.

When making file changes under High Availability (HA), you must make the changes on both nodes in the cluster. If the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands. See "Maintenance Mode" for more information.

You can complete this procedure before or after configuring NNMi for HA, as described in "Shared Data" .

  1. Change to the following directory on NNMi_HA1 before completing step 2:

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

  2. On NNMi_HA1, run the following commands to import newcert into the nnm.keystore file:

    • Windows: %jdkdir%\bin\keytool -import -alias newcert_Alias -keystore nnm.keystore -file newcert
    • Linux: $jdkdir/bin/keytool -import -alias newcert_Alias -keystore nnm.keystore -file newcert

  3. Edit the following file on both the active (NNMi_HA1) and the standby (NNMi_HA2) nodes:

    • Windows: %NnmDataDir%\conf\nnm\props\nms-local.properties
    • Linux: $NnmDataDir/conf/nnm/props/nms-local.properties

  4. Change the following line in the nms-local.properties file on both NNMi_HA1 and NNMi_HA2.

    com.hp.ov.nms.ssl.KEY_ALIAS = newcert_Alias
  5. Save your changes.

Work with Certificates in Global Network Management Environments

Configure Certificates in Global Network Management Environments

During NNMi installation, the installation script creates a self-signed certificate for the NNMi management server. This certificate contains an alias that includes the fully-qualified domain name of the node. The installation script adds this self-signed certificate to the NNMi management server’s nnm.keystore and nnm.truststore files.

Complete the following steps to configure the global network management feature to use self-signed/CA-signed certificates based on the following diagram.

Before you begin, make sure that the required certificates are created on the regional manager systems. For details, see Replace an Existing Certificate with a new Self-Signed or CA-Signed Certificate.

Global Network Management

  1. Change to the following directory on regional1 and regional2 :

    • Windows:%NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates
  2. Copy the nnm.truststore files from the above locations on regional1 and regional2 to some temporary location on global1.

  3. Run the following command on global1 to merge the regional1 and regional2 certificates into global1’s nnm.truststore file.

    Windows:

    1. nnmcertmerge.ovpl -truststore regional1_nnm.truststore_location
    2. nnmcertmerge.ovpl -truststore regional2_nnm.truststore_location

    Linux

    1. nnmcertmerge.ovpl -truststore regional1_nnm.truststore_location
    2. nnmcertmerge.ovpl -truststore regional2_nnm.truststore_location

  4. Run the following command sequence on global1:

    1. Run ovstop on the global1NNMi management server.
    2. Run ovstart on the global1NNMi management server.

    When making file changes under High Availability (HA), you need to make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.

Configure Certificates in Global Network Management Environments with Failover

During NNMi installation the installation script creates a self-signed certificate for the NNMi management server. This certificate contains an alias that includes the fully-qualified domain name of the node. The installation script adds this self-signed certificate to the NNMi management server’s nnm.keystore and nnm.truststore files.

This example uses the global network management configuration with the application failover feature as shown in the following diagram:

Global Network Management with Application Failover

Complete the following steps to configure the global network management feature to work with application failover based on the above diagram:

  1. Follow the instructions shown in Work with Certificates in Application Failover Environments for each application failover cluster shown in the above diagram.
  2. Complete the configuration for application failover shown in "Application Failover Basic Setup" .
  3. Follow the instructions shown in Work with Certificates in Global Network Management Environments for regional1_active and regional2_active.

Configure an SSL Connection to the Directory Service

By default, when directory service communications are enabled, NNMi uses the LDAP protocol for retrieving data from a directory service. If your directory service requires an SSL connection, you must enable the SSL protocol to encrypt the data that flows between NNMi and the directory service.

SSL requires a trust relationship between the directory service host and the NNMi management server. To create this trust relationship, add a certificate to the NNMi truststore. The certificate confirms the identity of the directory service host to the NNMi management server.

To install a truststore certificate for SSL communications:

  1. Obtain your company’s truststore certificate from the directory server. The directory service administrator should be able to give you a copy of this text file.

  2. Change to the directory that contains the NNMi truststore:

    • Windows: %NnmDataDir%\shared\nnm\certificates
    • Linux: $NnmDataDir/shared/nnm/certificates

    Run all commands in this procedure from the certificates directory.

  3. Import the root CA certificate of the LDAP directory server (without intermediate certificates) into the NNMi truststore:

    1. Run the following command:

      • Windows:

        %jdkdir%\bin\keytool.exe -import
        -alias nnmi_ldap -keystore nnm.truststore
        -file <Directory_Server_Certificate.txt>

      • Linux:

        $jdkdir/bin/keytool -import
        -alias nnmi_ldap -keystore nnm.truststore
        -file <Directory_Server_Certificate.txt>

        Where <Directory_Server_Certificate.txt> is your company’s truststore certificate.

    2. When prompted for the keystore password, enter: ovpass

    3. When prompted to trust the certificate, enter: y

      Example output for importing a certificate into the truststore

      The output from this command is of the form:

      Owner: CN=NNMi_server.example.com
      Issuer: CN=NNMi_server.example.com
      Serial number: 494440748e5
      Valid from: Tue Oct 28 10:16:21 MST 2008 until: Thu Oct 04 11:16:21 MDT 2108
      Certificate fingerprints:
      MD5:  29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02
      SHA1: C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03:7E:C4:03
      Trust this certificate? [no]:  y
      Certificate was added to keystore

  4. Examine the contents of the truststore:

    • Windows: 

      %jdkdir%\bin\keytool.exe -list
      -keystore nnm.truststore

    • Linux: 

      $jdkdir/bin/keytool -list
      -keystore nnm.truststore

    When prompted for the keystore password, enter: ovpass

    Example truststore output

    The truststore output is of the form:

    Keystore type: jks
    Keystore provider: SUN
    Your keystore contains 1 entry
    nnmi_ldap, Nov 14, 2008, trustedCertEntry,
    Certificate fingerprint (MD5): 29:02:D7:D7:D7:D7:29:02:29:02:29:02:29:02:29:02

    The truststore can include multiple certificates.

  5. Restart the NNMi management server.

    1. Run the ovstop command on the NNMi management server.

    2. Run the ovstart command on the NNMi management server.

      When making file changes under High Availability (HA), you must make the changes on both nodes in the cluster. If the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands. See "Maintenance Mode" for more information.

For more information about the keytool command, search for “Key and Certificate Management Tool” at http://www.oracle.com.

Send Help Center feedback