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 basic information about SSL connections, certificates, and JKS files and how to configure SSL for Operations Center servers:
The following sections provide a brief introduction to SSL connection types, certificate components, and JKS files:
When an SSL connection is established between a client and an Operations Center server, the server must provide a certificate with a common name (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, users cannot override certificate problems and must correct them 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.
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 data 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. If a CA signs a certificate, 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.
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 be 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 runtime 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.
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. If using self-signed certificates, 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:
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.
The dashboard requires a keystore file if SSL is enabled by any of the following conditions:
In the Dashboard’s Configuration Manager, Dashboard Communications 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 Communications Mode to Secured Communications using SSL and Client Certificates. This is typically only used if an Apache Web 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 Web Server.
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 Communications 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.
The following sections provide information about configuring SSL:
The runtime keystore file is normally called keystore and is created using Key Manager as described in Creating a Certificate. The default password for the keystore file is formula. The keystore file on an Operations Center server should always contain exactly one entry of type PrivateKeyEntry.
The trust store file is called cacerts. This file 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 runtime location of these files varies by server type. Table 5-4 lists the default runtime location of keystore and trust store files by server type.
Table 5-4 Default Runtime Location of Keystore and Trust Store Files by Server Type
|
Server Type |
Keystore Location |
Trust Store Location |
|---|---|---|
|
Operations Center |
Operations Center_install_path\config\secure\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 |
The Operations Center Configuration Manager and the dashboard Configuration Manager include a utility, Key Manager, that guides you through the process of generating a self-signed certificate and establishing trust or, if you choose to use a CA certificate, creating a certificate signing request that you can submit to your CA.
If you are creating a self-signed certificate, the server name that you specify in Key Manager becomes the CN in the certificate. Key Manager uses the fully-qualified domain name (for example, test_server_1.domain.com) to populate the CN, but also allows you to specify alternative server names (for example, test_server_1) by which clients can connect to the server.
Key Manager produces the following files:
keystore: a JKS file containing a self-signed certificate with the 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. If you have multiple Operations Center servers running on one host, it is 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.
To create a self-signed certificate:
In Congifuration Manager, click Security, and then click Explore next to Key Manager.
Select the option to have the Key Manager Startup Wizard guide you through the process, and then click Next.
Provide the requested information, and then click Finish to generate the certificate.
After the wizard generates the certificate, you can use Key Manager to complete certificate trust tasks. For more information, see Trusting Certificates.
After you generate a self-signed certificate, applications that connect to the server must trust the certificate in order to prevent security warnings or failures. You can have a trusted certificate authority sign the certificate, or you can individually configure the application to trust a self-signed certificate.
If you want a CA to sign a certificate, use Key Manager to create a certificate signing request, and then use Key Manager to import the response file from the CA to the trust store.
If you are using a self-signed certificate, use Key Manager to add the certificate to the trust store.
To create a certificate signing request:
On the Server SSL Key Pair tab of Key Manager, click Manage Trust.
Select the option to use a CA, and then click Next.
Select to create a request, and then click Next.
Provide the requested information, save the request or copy it to the clipboard, and then click Finish.
After you send the request to your CA and receive a response, use Key Manager to import the response file to the trust store. For more information, see Importing the Response to a Certificate Signing Request.
To add self-signed certificates to the trust store:
On the Server SSL Key Pair tab of Key Manager, click Manage Trust.
Select the option to add certificates to the trust store, and then click Next.
Provide the requested information, and then click Finish.
After you receive the response file to a certificate signing request, use Key Manager to import the response file to the trust store.
To import a CA response file to the trust store:
On the Server SSL Key Pair tab of Key Manager, click Manage Trust.
Select the option to use a CA, and then click Next.
Select the option to import a response file, and then click Next.
Select the response file, and then click Finish.
After you establish a keystore and trust store, you can use Key Manager to perform the following additional key management tasks:
Generate a new key pair and certificate to replace the existing key pair and certificate
On the Server SSL Key Pair tab, click Regenerate. The procedure is similar to the procedure that is described in Creating a Certificate, with additional attributes that you can specify, if desired.
View or modify the contents of a JVM trust store
On the Advanced tab, click Explore Trust Store. This option is useful when migrating certificates between trust stores or upgrading your JRE. You can view certificate details, import certificates, copy entries from another keystore, or delete entries from the keystore.
Change the trust store to which Key Manager reads and writes trusted certificates
On the Advanced tab, click Switch Trust Store and then follow the prompts.
Copy a private key from another keystore
On the Advanced tab, click Copy Keys and then follow the prompts.
Change the keystore password
On the Advanced tab, click Change Password and then follow the prompts.
The following sections provide step-by-step examples for configuring SSL for Operations Center implementations:
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:
On the Operations Center server:
In Configuration Manager, do the following:
Set Client/Server Communications Mode and Dashboard Communications Mode to Secured Communication using SSL.
Click Apply to update the settings.
Use Key Manager to create a certificate for Operations Center. For more information, see Creating a Certificate.
Use Key Manager to import the Operations Center certificate into the Operations Center server's trust store. For more information, see Trusting Certificates.
Copy keystore.cer (the file generated when you created the Operations Center certificate) to a location visible to the dashboard server host (server_d) and the CMS server host (server_c).
On the dashboard server:
In Configuration Manger, do the following:
Set NetIQ Operations Center Communications Mode and NetIQ Operations Center Web Server Port to the SSL port on Operations Center.
Click Apply to update the settings.
Use Key Manager to import the certificate from server_n into the dashboard's trust store. For more information, see Trusting Certificates.
On the CMS server:
In Configuration Manager, do the following:
Set NetIQ Operations Center Communications Mode and NetIQ Operations Center Web Server Port to the SSL port on Operations Center.
Click Apply to update the settings.
Use Key Manager to import the certificate from server_n into the CMS's trust store. For more information, see Trusting Certificates.
Restart all servers.
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:
On the Operations Center server running the dashboard, start Configuration Manager and do the following:
Set Dashboard Communications Mode to Secured Communication using SSL.
Click Apply to update the settings.
Use Key Manager to create a certificate for the dashboard. For more information, see Creating a Certificate.
Use Key Manager to copy the keystore file to the dashboard server's /conf directory. For more information, see Performing Advanced Key Management Tasks.
Restart the dashboard.
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:
On the Operations Center server running CMS, start the CMS Configuration Manager and do the following:
Set Configuration Management System Communications Mode to Secured Communication using SSL.
Click Apply to update the settings.
Use Key Manager to create a certificate for CMS. For more information, see Creating a Certificate.
Use Key Manager to copy the keystore file to the CMS server's server/conf directory. For more information, see Performing Advanced Key Management Tasks.
Restart CMS.
Before performing the steps contained in this example, complete the configuration steps in the preceding examples.
To enable Secured Communications with SSL and Client Certificates for Dashboard Communications Mode:
On the Operations Center server, copy the keystore.cer files from the dashboard and CMS servers to a location that is accessible to the Operations Center server. For example, C:/certificates/server_d and C:/certificates/server_c.
Use Key Manager to import the exported dashboard certificate into the Operations Center server's trust store. For more information, see Trusting Certificates.
Use Key Manager to import the exported CMS certificate into the Operations Center server's trust store. For more information, see Trusting Certificates.
In Configuration Manager, do the following:
Set Dashboard Communications Mode to Secured Communication using SSL and Client Certificates.
Click Apply to save the settings.
Restart the Operations Center server.