5.2 Keystore and Trust Store Configuration

A Java keystore (JKS) file is a secure file format used to hold certificate information for Java applications. If any Operations Center server (Operations Center, Dashboard, or CMS) uses SSL, it requires two JKS files:

  • keystore contains a single complete certificate (public and private key) used to identify the Operations Center server.

  • trust store contains the public keys of certificates that should be trusted by the Operations Center server.

If SSL is enabled in the Configuration Manager on any connection for any Operations Center server, for Operations Center, the dashboard or CMS, it is necessary to provide a keystore containing a certificate that identifies the host on which the Operations Center Server is running and is trusted by any other Operations Center server that connects to it—whether a certificate is trusted is determined by whether it is signed by a certificate found in the trust store of the server reading the certificate.)

The following sections provide both basic information about SSL connections, certificates, the JKS files; and how to configure SSL for Operations Center servers:

5.2.1 Understanding SSL Connections, Certificate Components, and JKS Files

The following sections provide a brief introduction to SSL connection types, certificate components, and JKS files:

Understanding SSL Connections

When an SSL connection is established between a client and an Operations Center server, the server must provide a certificate with a CN matching the server's host name and that is signed by a certificate in the trust store used by the client. If the client is a web browser, it is possible for a user to tell the browser to ignore any certificate problems and proceed with a connection.

However, when the client is another Operations Center server, such as the dashboard connecting to Operations Center, certificate problems cannot be overridden and must be corrected before SSL connectivity can be established.

In some cases, the server might also ask the client for a certificate that the server validates using the same criteria that the client used to validate the server's certificate. Validation of client certificates is only available on certain ports and is enabled by setting the Client/Server Communications Mode to Secured communication using SSL and Client Certificates in the Configuration Manager.

Understanding Certificate Components

An SSL certificate contains four components that are important to SSL configuration:

  • Private Key: used when encrypting data sent from the server to the client. Data encrypted with the private key can only be deciphered using the public key. For Operations Center Servers, private keys should only be contained in the keystore file.

  • Public Key: used when encrypting sent from client to server (such as the session key). Data encrypted with the public key can only be decrypted using the private key. The public key is shared with all clients during the SSL handshake that occurs during SSL connection establishment. Public keys of trusted certificates are contained in the trust store.

  • Signature: serves both to prevent certificate tampering and to establish trust for the certificate. The signature is a hash of other key parts of the certificate that is then encrypted using the private key of either the same certificate (for a self-signed certificate) or a certificate authority (CA) such as Verisign, Thawte, Entrust, etc. If a certificate is signed by a CA, the certificate will also contain the certificate(s) of the signer(s) in a certificate chain. The certificate at the end of a certificate chain (the root CA) must be trusted for the certificate to be accepted.

  • Common Name (CN): usually the name of the host being authenticated. The HTTPS protocol requires that the CN in the certificate matches the host name in the HTTPS URL. This type of CN validation is also provided for other protocols used between BSM servers (such as RMI) using a custom certificate validator called com.mosol.util.security.ssl.DefaultValidator. This feature is enabled by default in the server's .properties file.

Understanding Java Keystore (JKS) Files

A Java keystore (JKS) file is a secure file format that contains certificate information for Java applications.

A JKS file might contain multiple entries. Following are types of keystore entries:

  • PrivateKeyEntry: indicates that the entry contains both the public and private key information needed for it to used as a server certificate.

  • trustedCertEntry: indicates that the entry contains only the public key information and can only be used to indicate that the certificate is trusted.

Each entry is identified by a unique Alias name which is only used to distinguish an entry in the keystore. It is not used at run-time by Operations Center Servers. Each JKS file is password protected. Individual entries can also be password protected, but there is no support for this feature in Operations Center Servers.

5.2.2 Keystore and Trust Store Configuration Details

The following sections provide information about configuring SSL and requirements for Operations Center servers:

Configuring Keystore and Trust Store Files

The following executables are used in the configuration of the keystore and trust store files for Operations Center servers:

  • keytool (or keytool.exe): A standard Java executable used to view and manipulate Java keystore (JKS) files. An instance of keytool can be found in bin directory of the JRE or JDK used by your Operations Center Server.

    For instructions on using the keytool utility, see Creating a certificate using gencert.

    For more information about keytool, go to the keytool reference page on Oracle’s Web site

  • gencert (or gencert.bat): A script/batch file that uses keytool to assist in the creation of a keystore and associated files. The gencert utility is located in the bin directory of your Operations Center server installation. The gencert script assumes that keytool is on the execution path when it is run.

    For instructions on using gencert, see Creating a certificate using gencert.

The run-time keystore file is normally called keystore and is created using the gencert utility as described in Creating a certificate using gencert. The default password for this file is formula. The keystore file on a Operations Center server should always contain exactly one entry of type PrivateKeyEntry.

The trust store file is called cacerts and is included with your JRE (or JDK) installation and comes prepopulated with the certificates of most common Certificate Authorities (CAs). The cacerts file normally contains many entries that should all be of type trustedCertEntry. The default password for this file is changeit.

The run-time location of these files varies by server type. Table 5-4 lists the default run-time location of Keystore and Trust Store files by server type.

Table 5-4 The Default Run-Time Location of Keystore and Trust Store Files by Server Type

Server Type

Keystore Location

Trust Store Location

Operations Center

Operations Center_install_path/config/keystore

JRE_home/lib/security/cacerts

Operations Center Dashboard

Dashboard_install_path/server/conf/keystore

JDK_home/jre/lib/security/cacerts

Operations Center CMS

CMS_install_path/conf/keystore

JRE_home/lib/security/cacerts

Creating a certificate using gencert

The gencert utility is used to create a certificate. The host name passed to gencert not only becomes the CN in the certificate, but the alias name of the entry.

Because the CN for Operations Center server certificates usually refers to a host name, it is worthwhile to understand the following difference between using a simple name (e.g. test_server_1) versus a fully qualified name (e.g. test_server_1.domain.com) as the CN:

  • If your CN contains the simple name, clients can connect using either the short name or the fully qualified name. Whereas,

  • If the certificate CN contains the fully qualified name, the short name in the URL won’t be accepted; requiring clients to always connect using the fully qualified name.

  • Using the host name for the alias name is not particularly important in the keystore file. However, in a a trust store (cacerts) file where there are many more entries, it is recommended.

The gencert utility produces three files:

  • keystore: a JKS file containing a self-signed certificate with CN equal to the name of the host. In the case of the example, test_server_1. This keystore file includes both the public and private key and can be placed at the keystore location of any BSM server running on test_server_1. If you have multiple Operations Center Servers running on one host, it is perfectly acceptable and often more convenient to copy the same keystore into each server configuration.

  • keystore.cer: contains an exported form of the certificate in keystore that is appropriate for importing into a trust store.

  • keystore.csr: contains a signing request for the certificate in the keystore. If you are using an external CA, this file will need to be sent to them to sign the certificate.

To create a certificate using gencert:

  1. Issue the following command:

    gencert -host servername

    NOTE:It is not necessary to run gencert on the host where the certificate will be used. However, each invocation generates the same three files in the current directory, overwriting any previous files with the same name, so either copy the files to another directory, or invoke gencert from a separate directory to prevent accidental overwrites.

  2. To view the new certificate in the keystore file using the keytool, issue the following command:

    keytool -list -v -alias servername -keystore keystore -storepass formula

    Where, test_server_1 is the name of the host server and formulais the default password for the keystore. If the password has been changed, substitute the new password.

    Output displays similar to the following:

    Alias name: servername Creation date: Feb 1, 2011Entry type: PrivateKeyEntryCertificate chain length: 1Certificate[1]:Owner: CN=servername Issuer: CN=servername Serial number: 4d48598aValid from: Tue Feb 01 14:05:46 EST 2011 until: Fri Jan 29 14:05:46 EST 2021Certificate fingerprints: MD5: FF:6D:5F:C6:21:69:E1:5C:30:FA:59:59:31:A9:44:08 SHA1: C4:55:48:D7:3B:65:56:28:5E:A8:07:40:19:E2:7E:09:95:1F:02:36 Signature algorithm name: SHA1withRSA Version: 3

Importing the Response to a Certificate Signing Request

If submitting a certificate signing request (usually the keystore.csr file from above), then you need to import the response file.

When a certificate is signed by a known CA in this way, no further trust configuration should be necessary.

To import the response file to sign the certificate, run the following command:

keytool -importcert -keystore keystore -storepass formula -alias test_server_1 -trustcacerts -file ca_response_file

Where, test_server_1 is the name of the host server. keystore is the file name and path of the keystore file, and ca_response_file is the file name and path to the certificate response file. formulais the default password for the keystore. If the password has been changed, substitute the new password.

If you have any problems, refer to the on-line documentation for the keytool.

Setting Up Trust for Self-signed Certificates

If setting up SSL connections using self-signed certificates, the certificates that need to be trusted by a particular Operations Center server need to be imported into that server's trust store (cacerts file). This is done using the keystore.cer file from the server-to-trusted. It is imported as follows:

To import the certificates into the Operations Center’s trust store:

  1. Issue the following command:

    keytool -importcert -keystore cacerts -storepass changeit -alias servername -file keystore.cer

    Where, servername is your own alias name. We recommend that you use the name of the host identified in the certificate. Be sure to specify the cacerts and keystore.cer with file path references appropriate to your environment.

  2. When the keytool has read in the certificate information, it prints out the certificate data and asks that you confirm that it should be trusted:

    Trust this certificate? [no]:

    Type yes and enter.

Certificate Requirements for Operations Center Servers

Each Operations Center server has a set of configuration options that impact whether that server needs its own keystore and whether it needs to trust the certificates of other servers. Remember that if using self-signed certificates, then you must manually import the exported certificate (keystore.cer) file of the server that is to be trusted. If you are using CA-signed certificates, you can skip the steps to import the certificate.

The following sections list the various certificate requirements for the Operations Center servers:

Requirements for Operations Center

Operations Center requires a keystore file if SSL is enabled by any of the following settings in the Operations Center Configuration Manager:

  • Client/Server Communications is set to Secured Communications using SSL, or Support both unsecured and secured communications when connecting to the HTTPS Web Server Port.

  • Remote Services Security (RMI) is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates.

  • Web Services Communications Security is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates.

Operations Center server must trust its own certificate if Secured Communications using SSL is enabled for Remote Services Security (RMI). Dashboard communications uses RMI which requires the server to connect to itself when registering remote objects.

Operations Center must trust the certificate used by any Dashboard or CMS server accessing the Operations Center server if Secured Communications using SSL and Client Certificates is enabled for Remote Services Security (RMI).

Operations Center must trust the certificate used by any Web Services client accessing the Operations Center server if Secured Communications using SSL and Client Certificates is enabled for Web Services Communications Security.

Requirements for Dashboard

Operations Center dashboard requires a keystore file if SSL is enabled by any of the following conditions:

  • In the dashboard’s Configuration Manager, Dashboard Communication Mode is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates, or set to Support both unsecured and secured communications when connecting to the Dashboard HTTPS port.

  • In the Operations Center Configuration Manager, Remote Services Security (RMI) is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates.

Dashboard must trust the Operations Center certificate if:

  • In the Operations Center Configuration Manager, Client/Server Communications Mode is set to Secured Communications using SSL, or Support both unsecured and secured communications when connecting to the HTTPS Web Server Port.

    AND

    In the dashboard’s Configuration Manager, NetIQ Operations Center Communications Mode is set to (Secured Communication using SSL.)

  • In the Operations Center Configuration Manager, Remote Services Security (RMI) is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates.

In the dashboard’s Configuration Manager, you can also set Dashboard Communication Mode to Secured Communications using SSL and Client Certificates. This is typically only used if an Apache Server is configured as a reverse proxy in front of the dashboard. In that case, the dashboard would need to trust the certificate used by the Apache Server.

Requirements for CMS

If running CMS with SSL enabled, it is necessary for CMS to trust its own certificate.

CMS uses the same communications ports as the dashboard, so some settings designated for the dashboard also apply to CMS.

CMS requires a keystore file if SSL is enabled by any of the following:

  • In the CMS’ Configuration Manager, Configuration Management System Communication Mode is set to Secured Communications using SSL, or set to Support both unsecured and secured communication when connecting to the CMS HTTPS port.

  • In the Operations Center Configuration Manager, Remote Services Security (RMI) is set to Secured Communications using SSL and Client Certificates .

CMS must trust the Operations Center certificate if SSL is enabled by any of the following:

  • In the Operations Center Configuration Manager, Client/Server Communications Mode is set to Secured Communications using SSL, or Support both unsecured and secured communications when connecting to the HTTPS Web Server Port.

    AND

    In the CMS’ Configuration Manager, NetIQ Operations Center Communications Mode is set to (Secured Communication using SSL.)

  • In the Operations Center Configuration Manager, Remote Services Security (RMI) is set to Secured Communications using SSL or Secured Communications using SSL and Client Certificates.

CMS must trusts its own certificate if SSL is enabled by any of the following:

  • In the CMS’ Configuration Manager, Configuration Management System Communications Mode is set to Secured Communications using SSL, or Support both unsecured and secured communications when connecting to the Configuration Management System HTTPS Web Server Port.

5.2.3 Examples SSL Configurations

The following sections provide step-by-step examples for configuring SSL for Operations Center implementations:

Example #1: Securing Operations Center with self-signed certificates.

Before starting this example, note that the following are running unsecured, each on different servers:

  • Operations Center (server_n)

  • Operations Center dashboard (server_d)

  • Operations Center CMS (server_c)

To secure Operations Center with self-signed certificates:

  1. Do the following on the Operations Center server:

    1. Launch the Configuration Manager and do the following:

      1. Set Client/Server Communication Mode and Dashboard Communications Mode to Secured Communication using SSL

      2. Click Apply to update the settings and close the Configuration Manager.

    2. Create a certificate for Operations Center by running gencert:

      D:/OperationsCenter_install_path/bin>gencert -host server_n

      Output similar to the following displays:

      Begin generation of certificate...Generating 1,024 bit RSA key pair and self-signed certificate (SHA1withRSA) with a validity of 3,650 days for: CN=server_n[Storing keystore]New certificate (self-signed):[[ Version: V3 Subject: CN=server_n Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 126594161902785932578498390566758897158889875795766986682747367546879216234771137457829756085166232578781125339243204317536024821192943421279928416862128853069558150865069307978388638674381960921134793649014750580231083354169107003031151690724296688499549945749741970232448084495541581146498657884672944445159 public exponent: 65537 Validity: [From: Thu Feb 03 12:19:30 EST 2011, To: Sun Jan 31 12:19:30 EST 2021] Issuer: CN=server_n SerialNumber: [ 4d4ae3a2]] Algorithm: [SHA1withRSA] Signature:0000: 63 9C 69 0C 4A 40 6F FB DE 04 BD 51 0B 35 40 90 c.i.J@o....Q.5@.0010: 48 41 A4 51 7F 3C 9D 66 49 D2 9B 5A 64 B4 2A 90 HA.Q.<.fI..Zd.*.0020: B2 53 5B 93 90 3D 73 EE 52 3A E0 3A D5 0E 93 96 .S[..=s.R:.:....0030: 7A 43 32 85 80 F2 B4 56 2E 5C 37 C0 FF 0E 1F 3B zC2....V.\7....;0040: 5B 9E 66 D9 8E 52 00 B6 3D D1 1D 15 28 37 F5 74 [.f..R..=...(7.t0050: EE E9 4D D4 CC 70 16 49 88 82 60 3F 8C BF ED B1 ..M..p.I..`?....0060: 86 8F D4 00 91 76 F1 8A 19 CE DD 3F 51 85 57 BF .....v.....?Q.W.0070: 8D 57 89 41 32 BD 0E 58 9A 8D 72 2B B6 EA B6 8E .W.A2..X..r+....][Storing keystore]Begin exporting certificate...Certificate stored in file <keystore.cer>Certification request stored in file <keystore.csr>Submit this to your CA

    3. Copy the keystore file to the Operations Center server's config directory:

      D:/OperationsCenter_install_path/bin>copy keystore ../config

    4. Issue the following command to import the exported Operations Center certificate into the Operations Center server's trust store:

      e:/dev/jre/se1.6u21b64/lib/security>keytool -import -keystore cacerts -store pass changeit -alias server_n -file d:/OperationsCenter_install_path/bin/keystore.cer

      Output similar to the following displays:

      Owner: CN=server_nIssuer: CN=server_nSerial number: 4d4ae3a2Valid from: Thu Feb 03 12:19:30 EST 2011 until: Sun Jan 31 12:19:30 EST 2021Certificate fingerprints: MD5: 0A:06:64:85:60:F8:7E:58:54:BF:27:58:06:51:68:93 SHA1: 1B:CD:E5:C8:FD:11:2B:AA:6A:19:A1:26:EC:D7:E6:65:FB:45:C4:36 Signature algorithm name: SHA1withRSA Version: 3Trust this certificate? [no]: yes

      When prompted to trust the certificate, type yes and enter.

    5. Copy keystore.cer to a location visible to the Dashboard server host (server_d) and the CMS server host (server_c)

  2. Do the following on the Dashboard Server:

    1. Launch the Configuration Manger and do the following:

      1. Set NetIQ Operations Center Communication Mode and NetIQ Operations Center Web Server Port to the SSL port on Operations Center.

      2. Click Apply to update the settings and close the Configuration Manager.

    2. Issue the following command to import the certificate from server_n into the Dashboard's trust store:

      e:/dev/jdk/1.6u21b64/jre/lib/security>keytool -import -keystore cacerts -storepass changeit -alias server_n -file c:/certificates/server_n/keysto re.cer

      Output similar to the following displays:

      Owner: CN=server_nIssuer: CN=server_nSerial number: 4d4ae3a2Valid from: Thu Feb 03 12:19:30 EST 2011 until: Sun Jan 31 12:19:30 EST 2021Certificate fingerprints: MD5: 0A:06:64:85:60:F8:7E:58:54:BF:27:58:06:51:68:93 SHA1: 1B:CD:E5:C8:FD:11:2B:AA:6A:19:A1:26:EC:D7:E6:65:FB:45:C4:36 Signature algorithm name: SHA1withRSA Version: 3Trust this certificate? [no]: yes

      When prompted to trust the certificate, type yes and enter.

  3. Do the following on the CMS server:

    1. Launch the CMS Configuration Manager and do the following: and

      1. Set NetIQ Operations Center Communication Mode and NetIQ Operations Center Web Server Port to the SSL port on Operations Center.

      2. Click Apply to update the settings and close the Configuration Manager.

    2. Issue the following command to import certificate from server_n into the CMS's trust store:

      e:/dev/jre/se1.6u21b64/lib/security>keytool -import -keystore cacerts -store pass changeit -alias server_n -file c:/certificates/server_n/keystore.cer

      Output similar to the following displays:

      Owner: CN=server_nIssuer: CN=server_nSerial number: 4d4ae3a2Valid from: Thu Feb 03 12:19:30 EST 2011 until: Sun Jan 31 12:19:30 EST 2021Certificate fingerprints: MD5: 0A:06:64:85:60:F8:7E:58:54:BF:27:58:06:51:68:93 SHA1: 1B:CD:E5:C8:FD:11:2B:AA:6A:19:A1:26:EC:D7:E6:65:FB:45:C4:36 Signature algorithm name: SHA1withRSA Version: 3Trust this certificate? [no]: yes

      When prompted to trust the certificate, type yes and enter.

  4. Restart all servers.

Example #2: Securing Operations Center Dashboard with self-signed certificates.

Before starting this example, note that the following are running unsecured, each on different servers:

  • Operations Center (server_n)

  • Operations Center dashboard (server_d)

  • Operations Center CMS (server_c)

To secure the dashboard with self-signed certificates:

  1. On the Operations Center server running the dashboard, launch the Configuration Manager and do the following:

    1. Set Dashboard Communication Mode to Secured Communication using SSL.

    2. Click Apply to update the settings and close the Configuration Manager.

  2. Create a certificate for the dashboard by running gencert:

    C:/OperationsCenter_Dashboard_install_path/bin>gencert -host server_d

    Output similar to the following displays:

    Begin generation of certificate...Generating 1,024 bit RSA key pair and self-signed certificate (SHA1withRSA) with a validity of 3,650 days for: CN=server_d[Storing keystore]New certificate (self-signed):[[ Version: V3 Subject: CN=server_d Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 102037338693262168564613347008011320641771647629914318285483146311561847280174347700620645176217200029834740897472462957535783741791303038689175275577539581299769929245185965204093067298360728577685405297973935320586647374454823050088714093206844196696827954596279424489000793199020430711428610026969411519133 public exponent: 65537 Validity: [From: Thu Feb 03 14:15:24 EST 2011, To: Sun Jan 31 14:15:24 EST 2021] Issuer: CN=server_d SerialNumber: [ 4d4afecc]] Algorithm: [SHA1withRSA] Signature:0000: 91 2C 43 C0 63 C3 ED CC 1E 82 DB 5C 12 45 27 94 .,C.c......\.E'.0010: 9B E9 FD 62 40 AD DF 96 D1 03 3E 7B 91 B3 E1 7B ...b@.....>.....0020: 38 E3 5D E3 B7 C8 CB 8D D4 36 3F 4D 03 2A 2C A7 8.]......6?M.*,.0030: C9 3A 40 D0 82 DF DE 78 81 17 35 9A A3 28 C5 C2 .:@....x..5..(..0040: 59 67 44 9C 9E 54 AF 2B 31 02 AE 6D 18 1F 4E 06 YgD..T.+1..m..N.0050: E9 A4 AB 01 0D AE 1C 14 4C 8D 50 82 A9 C7 AF 05 ........L.P.....0060: 46 5D 52 BA 7D 28 98 CE 87 AA EC 12 1B 55 7C 43 F]R..(.......U.C0070: 9F 62 53 A4 BE 33 5C 6F 2B E8 BE 72 90 52 AE C5 .bS..3\o+..r.R..][Storing keystore]Begin exporting certificate...Certificate stored in file <keystore.cer>Certification request stored in file <keystore.csr>Submit this to your CA][Storing keystore]Begin exporting certificate...Certificate stored in file <keystore.cer>Certification request stored in file <keystore.csr>Submit this to your CA

  3. Issue the following command from the /OperationsCenter_Dashboard_install_path/bin directory to copy the keystore file to the Dashboard server's server /conf directory:

    copy keystore ../server/conf

  4. Restart the dashboard.

Example #3: Securing Operations Center CMS with Self-signed Certificates.

Before starting this example, note that the following are running unsecured, each on different servers:

  • Operations Center (server_n)

  • Operations Center dashboard (server_d)

  • Operations Center CMS (server_c)

To secure the CMS with self-signed certificates:

  1. On the Operations Center server running CMS, launch the CMS Configuration Manager and do the following:

    1. Set Configuration Management System Communication Mode to Secured Communication using SSL.

    2. Click Apply to update the settings and close the Configuration Manger.

  2. Issue the following command to create a certificate for CMS by running gencert:

    C:/OperationsCenter_CMS_install_path/bin>gencert -host server_c

    Output similar to the following displays:

    Begin generation of certificate...Generating 1,024 bit RSA key pair and self-signed certificate (SHA1withRSA) with a validity of 3,650 days for: CN=server_c[Storing keystore]New certificate (self-signed):[[ Version: V3 Subject: CN=server_c Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 121460385947628891012992002480184625164711741523363333249317921220292472699480959921460262921591796643969838591330461443446153936221343163838006497886957363177766786643749142798244876023990879031410693688435614483636326463258921782731654649203189443994946599400087541865527938376810100636446400946674987424089 public exponent: 65537 Validity: [From: Thu Feb 03 14:23:52 EST 2011, To: Sun Jan 31 14:23:52 EST 2021] Issuer: CN=server_c SerialNumber: [ 4d4b00c8]] Algorithm: [SHA1withRSA] Signature:0000: 70 1F 31 1D FA A1 40 92 CE 15 B5 2C C1 FA B7 31 p.1...@....,...10010: B7 1E 97 DE 1B 04 01 2B 6D 8D B0 7F 43 56 C0 FF .......+m...CV..0020: 74 BC E4 AF 2D 22 1E A7 E7 DB 84 38 C1 03 61 44 t...-".....8..aD0030: CC 5D B1 16 BE 58 E1 1B DE C3 73 5B AF 6B 44 84 .]...X....s[.kD.0040: 9D 06 A2 5D 49 77 92 E9 A0 84 4D EB 62 51 AC 80 ...]Iw....M.bQ..0050: E9 B4 19 16 0D DC 06 9B 29 71 32 24 23 72 EF A3 ........)q2$#r..0060: CF 11 3A 09 E1 13 1E 8E 15 AA 2D 6A 6D 5E 99 51 ..:.......-jm^.Q0070: 90 94 8F 53 DA F9 1C 4F 87 C5 5D 36 F4 04 86 0E ...S...O..]6....][Storing keystore]Begin exporting certificate...Certificate stored in file <keystore.cer>Certification request stored in file <keystore.csr>Submit this to your CA

  3. Issue the following command from the /OperationsCenter_CMS_install_path/bin directory to copy the keystore file to the CMS server's server/conf directory:

    copy keystore ../conf

  4. Restart CMS.

Example #4 Enabling “Secured Communications with SSL and Client Certificates” for Dashboard Communications Mode

Prior to performing the steps contained in this example, you must complete the configuration steps in the three preceding example sections.

To enable Secured Communications with SSL and Client Certificates for Dashboard Communications Mode:

  1. On the Operations Center server, copy the keystore.cer files from Dashboard and CMS Servers to a location accessible to the Operations Center server. For our example, we used c:/certificates/server_d and c:/certificates/server_c.

  2. Issue the following command to import the exported Dashboard certificate into the Operations Center server's trust store:

    e:/dev/jre/se1.6u21b64/lib/security>keytool -import -keystore cacerts -storepass changeit -alias server_d -file c:/certificates/server_d/key store.cer

    Output similar to the following displays:

    Owner: CN=server_dIssuer: CN=server_dSerial number: 4d4afeccValid from: Thu Feb 03 14:15:24 EST 2011 until: Sun Jan 31 14:15:24 EST 2021Certificate fingerprints: MD5: 5C:6F:62:12:04:DB:30:3A:63:7B:7C:05:BB:5E:EF:84 SHA1: 71:F2:56:28:77:5C:90:C9:3A:C9:6D:0E:5F:90:59:F8:F5:02:BE:F7 Signature algorithm name: SHA1withRSA Version: 3Trust this certificate? [no]: yes

    When prompted, type yes to trust the certificate and enter.

  3. Issue the following command to import the exported CMS certificate into the Operations Center server's trust store:

    e:/dev/jre/se1.6u21b64/lib/security>keytool -import -keystore cacerts -storepass changeit -alias server_d -file c:/certificates/server_c/ke ystore.cer

    Output similar to the following displays:

    Owner: CN=server_cIssuer: CN=server_cSerial number: 4d4b00c8Valid from: Thu Feb 03 14:23:52 EST 2011 until: Sun Jan 31 14:23:52 EST 2021Certificate fingerprints: MD5: 68:76:6F:57:3F:A9:5A:A9:47:A6:D3:9C:AE:9B:85:EF SHA1: 85:52:BF:9C:54:A3:3E:32:03:9B:31:D9:A7:EF:0C:36:82:81:AD:3E Signature algorithm name: SHA1withRSA Version: 3Trust this certificate? [no]: yes

    When prompted, type yes to trust the certificate and enter.

  4. Run Configuration Manager and do the following:

    1. Set Dashboard Communications Mode to Secured Communication using SSL and Client Certificates.

    2. Click Apply to save the settings and close the Configuration Manager.

  5. Restart the Operations Center Server.