Using Certificates with the PKCS #12 Repository

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.

Generating a Self-Signed Certificate

To generate a self-signed certificate, follow these steps:

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. 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>

      Note 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.

      Caution 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 Generating a CA-Signed Certificate.

      recommends that you use CA-signed certificates.

Generating a CA-Signed Certificate

To obtain and install a CA-signed certificate, follow these steps:

1. Generate a self-signed certificate. For details, see Generating 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

   Note  

   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.

   Note 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.

   Note 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>

   Note 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

   Note  

   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

    Tip The truststore can include multiple certificates.

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

    Note 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

       

      Note  

      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

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.

    Note 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.

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

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>

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

5. Restart NNMi by running the following commands:

   Note 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

Replacing 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 Generating 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 Generating 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.

Working with Certificates in Application Failover Environments

Using Certificates with Application Failover

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.

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 Application Failover.

Working 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.

Using Certificates with HA

Configuring 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.

Configuring 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.

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

Working with Certificates in Global Network Management Environments

Configuring 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 Replacing 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.

Configuring 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 Working 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 Requirements.
3. Follow the instructions shown in Configuring Certificates in Global Network Management Environments for regional1_active and regional2_active.

Configuring 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, follow these steps:

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:

   Note 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

   Tip 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.

      Note 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.