Chapter 7 Configuring the N1 Grid Service Provisioning System 5.0 for SSL

This chapter contains instructions for configuring the N1 Grid Service Provisioning System 5.0 to communicate using Secure Socket Layer (SSL). This chapter discusses the following topics:

• Overview of SSL Support in the N1 Grid Service Provisioning System 5.0

• Configuring SSL – Process Overview

• Enabling HTTPS Connections from the Master Server Browser Interface

• Creating Keystores

• Configuring SSL

• Sample Configuration Scenarios

• SSL Cipher Suites

Overview of SSL Support in the N1 Grid Service Provisioning System 5.0

SSL is a protocol for securing communication over IP networks. SSL uses TCP/IP sockets technology to exchange messages between a client and a server, while protecting the message with a public and private key encryption system developed by RSA. Support for SSL is included in most web server products, as well as in the Netscape Navigator and Microsoft web browsers.

N1 Grid Service Provisioning System 5.0 applications can be configured to use SSL for their network communications, preventing messages from being read or tampered with. Optionally, applications can be configured to use SSL to authenticate before communicating, further increasing network security.

Cipher Suites: Encryption and Authentication Overview

The SSL protocol supports a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. The cipher suite that SSL uses to connect determines whether any authentication takes place.

Exercise caution when selecting cipher suites. Each application must enable only those cipher suites that provide the minimum security needed by the node. SSL uses the most secure cipher suites supported by both the client and server. If low security cipher suites are enabled, a third party client can force the server to use the less secure cipher suites by publishing support for only the least secure cipher suite during cipher suite negotiation.

SSL can be operated in the following modes:

• Encryption only, no authentication – Connections are encrypted. However, SSL does not authenticate the applications that are connecting.

• Server Authentication – Clients authenticate the server to which they are connecting.

• Server and Client Authentication – Both the client and server authenticate each other.

During the installation, when you select to use SSL to secure communications between applications, you are prompted to select the cipher suite to use. The cipher suite value is stored as the value of net.ssl.cipher.suites in the config.properties file. The cipher suite value is set to the following value based on the selection you make:

• If you select encryption, no authentication, the cipher suite is set to SSL_DH_anon_WITH_3DES_EDE_CBC_SHA.

• If you select encryption, with authentication, the cipher suite is set to SSL_RSA_WITH_3DES_EDE_CBC_SHA.

When you use SSL with a Local Distributor on an AIX server, the SSL cipher suite is set to encryption with authentication. Encryption with no authentication is not available for Local Distributors that are running on AIX servers.

For lists of SSL cipher suites that do and do not require server authentication, see SSL Cipher Suites. You can configure client authentication only for cipher suites that require server authentication.

The N1 Grid Service Provisioning System 5.0 applications allow you to configure SSL connections with encryption, no authentication or encryption with authentication. Encryption with authentication uses client and server authentication. Although the configurations described above are possible, encryption, with authentication is the most secure.

Authentication Keystores

The N1 Grid Service Provisioning System 5.0 supports self-signed certificates and certificates signed by a Certifying Authority. Two types of keystores exist:

• Private Keystore – The private keystore contains the public-private key pairs that the application uses to authenticate itself when connecting to other applications.

• Trust Keystore – The trust keystore contains the public key, in self-signed certificates, of other applications that the keystore trusts and allows them to connect to the application.

When enabling SSL for client-server authentication, each enabled application needs to be configured with two keystores that SSL will use to authenticate itself to other applications and to authenticate other applications.

When enabling SSL for server-only authentication, the application acting as the SSL server requires a private keystore and the application acting as the SSL client requires a public, or trusted, keystore. The public keystores are in the proprietary JKS format provided by the Java Secure Sockets Extension (JSSE) v1.0.3.

You must specify a password for both of the keystores. The password for both of the keystores must be the same.

For example, application A, an SSL client, and application B, an SSL server, want to connect with each other using SSL. Both are configured to use a cipher suite that requires server authentication. Application B must have a public-private key pair in its private keystore, and application A must have application B's public key in its trust keystore. When application A attempts to connect to application B, application B sends its public key down to application A. Application A is able to verify the public key by finding it in its trust keystore.

If application B is configured to require client authentication, application A must have a public-private key pair in its private keystore. Also,application B must have application A's public key in its trust keystore. After application A has authenticated application B, application B is able to verify application A's public key, as it finds the public key in its trust keystore.

Using Passwords With SSL

If you supply a password for trust keystore operations, the password is only used to verify the integrity of the keystore. The password does not prevent access to the contents of the trust keystore, but it does protect updates to the keystore. Users are not able to change the contents of the keystore without supplying the password.

If you supply a password for private keystore operations, the password is used to verify the integrity of the keystore, protect against modifications of the keystore contents, and to encrypt and protect access to the private key.

The crkeys script validates that you specified the same password for both the keystores. When creating a trust store for the first time by importing certificates, the crkeys script ensures that the trust store has the same password as the private store, if one exists. Similarly, when creating a private store for the first time, the crkeys script ensures that the private store has the same password as the trust store, if one exists.

Limitations of SSL on the N1 Grid Service Provisioning System 5.0

The SSL implementation on the N1 Grid Service Provisioning System 5.0 has the following limitations:

• Both the trust and the private keystores must be configured with the same password. Also, within the private keystore, the key password for each key in the store must be the same as the store password. The crkeys script used to create keys enforces this limitation.

• Although enabling client authentication for CLI Client applications is possible, this setup is not supported due to security limitations. The CLI Client applications do not prompt the user for keystore passwords. If the keystores have been created, the keystores must be provided in the CLI Client properties file.

• The N1 Grid Service Provisioning System 5.0 uses single trust keystore for both incoming and outgoing connections. Therefore, if a Master Server connects to a Remote Agent and trusts its public key and if that Remote Agent becomes compromised, that Remote Agent's keys could be used to authenticate the CLI Client to the Master Server, if the CLI Client were to use client authentication. Similarly, if a Local Distributor connects to a Remote Agent and the Remote Agent becomes compromised, the Local Distributor can be used to issue commands to the Master Server.

  To secure the Master Server and the Local Distributor against such issues, configure the applications to accept connections only from servers that are expected to connect to them. Permit a Local Distributor to accept connections only from its parent node. Permit the Master Server to accept connections only from the designated CLI hosts. For instructions, see Chapter 8, Configuring the Java Virtual Machine Security Policy.

• For SSH connections, the remote application, the Local Distributor or Remote Agent, is automatically started. The server does not prompt you for the keystore passwords to start these applications. If the applications are initialized with keystores, the passwords to their keystores must be specified in their properties file.

• When you configure the CLI Client to connect to the Master Server using SSH, the CLI Client connects to the Master Server using an SshProxy application that connects to the Master Server through sockets. The SshProxy can connect to the Master Server through SSL, but this configuration is not supported.

Configuring SSL – Process Overview

The following process overview describes the tasks necessary to configure the N1 Grid Service Provisioning System 5.0 to use SSL.

1. Determine the SSL connectivity that you want to use.

   For more information, see Overview of SSL Support in the N1 Grid Service Provisioning System 5.0.

2. (Optional) Enable the Master Server browser interface to use HTTPS.

   See Enabling HTTPS Connections from the Master Server Browser Interface.

3. Use the crkeys command to create keystores.

   See Creating Keystores.

4. Edit the config.properties file to configure SSL.

   See Configuring SSL.

Enabling HTTPS Connections from the Master Server Browser Interface

By default, the N1 Grid Service Provisioning System 5.0 browser interface does not use SSL. Requests are performed over HTTP rather than HTTPS. You can enable HTTPS with an SSL Certificate. You can choose whether to have a Certifying Authority sign the certifcate or you can use a self-signed certificate.

A certificate signed by a Certifying Authority is trusted by browsers, therefore the browser does not issue a warning when a user connects to the browser interface on the Master Server. Generally, Certifying Authorities charge a fee to sign a certificate.

A self-signed certificate is available for use immediately after you generate the certificate because you do not have to wait for the Certifying Authority to sign it. However, a self-signed certificate is not trusted by the browser, so the browser issues a warning each time a user connects to the Master Server browser interface.

How to Generate SSL Certificates

To enable the browser interface to use SSL, you must first generate an SSL Certificate.

Steps

1. Change to the directory in which you installed the JRE.

   % cd JAVA-HOME/bin

   JAVA-HOME is the directory where you installed the JRE. If you installed the JRE with the N1 Grid Service Provisioning System 5.0, the JRE is installed in the N1SPS5.0-home/common/jre/bin directory.

2. Generate the certificate.

   % keytool -genkey -alias tomcat -keyalg RSA -keystore /keystore-location -storepass password

   Set /keystore-location to the location and filename where you want to store the generated key.

   Set password to whatever password that you choose.

3. Follow the prompts to complete.

   Do not include any punctuation in the name of your organization, otherwise the Java Certificate tool fails when attempting to generate the request. The Common Name (CN) must be set to the fully qualified host name, including the domain name, component of the URI.

How to Obtain a Signature for an SSL Certificate

If you want to use a Certificate signed by a Certifying Authority, follow this procedure to submit the Certificate to the Certifying Authority to be signed.

Steps

1. Generate the Certificate Request.

   % keytool -certreq -v -alias tomcat -keyalg RSA -keystore /keystore-location

   /keystore-location is the location and filename where you stored the generated key.

2. Send the Certificate Request to the Certifying Authority.

   Follow the instructions provided by the Certifying Authority. The Certifying Authority returns a Certificate Reply.

3. Save the Certificate Reply to a file.

4. Verify the Certificate Reply.

   % keytool -printcert -file certificate-reply-file

   certificate-reply-file is the filename of the Certificate Reply that you received from the Certifying Authority.

5. Import the Certificate Reply file to the keystore file.

   % keytool -v -import -trustcacerts -keystore /keystore-location -file certificate-reply-file -alias tomcat

   /keystore-location is the location and filename where you stored the generated key. certificate-reply-file is the filename of the Certificate Reply that you received from the Certifying Authority.

6. Verify the imported Certificate Reply.

   % keytool -v -list -keystore /keystore-location

   /keystore-location is the location and filename where you stored the generated key.

How to Enable HTTPS Connections from the Master Server Browser Interface

After you have generated an SSL Certificate, and obtained a signature from a Certifying Authority if you chose to do so, you must configure the Master Server browser interface to use SSL.

Steps

1. Stop the Master Server.

   % N1SPS5.0-MasterServer-home/server/bin/cr_server stop

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

2. Move the keystore file to the Master Server home directory.

   %mv /keystore-location N1SPS5.0-MasterServer-home/server/tomcat/

   /keystore-location is the location and filename where you stored the generated key. N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

3. Change to the directory where you moved the keystore file.

   % cd N1SPS5.0-MasterServer-home/server/tomcat/

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

4. Set the ownership and permissions on the keystore file:

   %chmod 600 /keystore-location

   %chown MS_user:MS_group /keystore-location

   MS_user is the user that owns the Master Server application. MS_group is the group that owns the Master Server application. /keystore-location is the filename where you stored the generated key.

5. Change to the directory where the Tomcat configuration files are located.

   % cd /N1SPS5.0-MasterServer-home/server/tomcat/conf

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

6. In the server.xml file, uncomment the following lines. XML comments begin with <!-- and end with -->.

   <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true"> <Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS"/> </Connector>

7. Edit the Factory element as follows.

   <Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="false" protocol="TLS" keystoreFile="N1SPS5.0-MasterServer-home/server/tomcat/keystore-file" keystorePass="password"/>

   N1SPS5.0-MasterServer-home/server/tomcat/keystore-file is the path to the keystore file. password is the password that you used to create the original keystore.

Requiring Users to Connect to the Master Server Browser Interface Using SSL

After you have configured the Master Server browser interface to use SSL, you can configure it further so that users must use SSL to connect to the on the N1 Grid Service Provisioning System Master Server.

How to Require Users to Connect to the Master Server Browser Interface Using SSL

Steps

1. Replace the Tomcat web.xml file with the secure web.xml file.

   % cd /N1SPS5.0-MasterServer-home/server/webapp/WEB-INF

   % cp web.xml.secure web.xml

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

2. Restart the Master Server.

   % N1SPS5.0-MasterServer-home/server/bin/cr_server start

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

How to Revert to the Original Configuration

Steps

1. Stop the Master Server

   % N1SPS5.0-MasterServer-home/server/bin/cr_server stop

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

2. To return to the original configuration, replace the secure web.xml file with the default web.xml file.

   % cd /N1SPS5.0-MasterServer-home/server/webapp/WEB-INF

   % cp web.xml.default web.xml

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

3. Restart the Master Server.

   % N1SPS5.0-MasterServer-home/server/bin/cr_server start

   N1SPS5.0-MasterServer-home is the directory where you installed the Master Server.

Creating Keystores

The N1 Grid Service Provisioning System 5.0 uses the keytool utility provided with the JRE. The keytool utility is wrapped in a shell script, crkeys, to enable you to create keystores. The script ensures that the correct parameters are supplied to the keytool utility.

When you create a keystore, the X.509 Distinguished Name in the self-signed certificate is set to the following:

CN=application_name OU=Engineering O=Sun Microsystems Inc L=Menlo Park ST=CA C=US

How to Create Keystores

Step

Generate the keys.

% crkeys -options

Use the following options to create keystores based on the type of SSL connectivity you want to use.

-alias application_hostname

Specifies an alias for the certificate or the key pair. Use the host name of the application as the alias. The alias names must be unique within a keystore.

-cpass

Changes the password of the keystore and all the keys within the keystore.

-delete

Specifies that the key pair or certificate for the specified entity should be deleted from keystore.

-export

Exports a self-signed certificate of the specified entity to the specified file.

-file cert_file

Specifies the name of the file that the certificate is to be imported from or exported to.

-generate

Generates a new key pair for the specified alias.

-help

Lists all the options.

-import

Imports a self-signed certificate of an entity that is allowed to connect to this node. When importing the certificate, the host name of the node that this certificate represents should be used as the alias.

-keyalg keyalg

The key generation algorithm. Defaults to RSA. Can be either RSA or DSA.

-keysize keysize

The key size. Defaults to 1024. Can be any multiple of 64 in the range 512-1024 for DSA keys, and range 512-2048 for RSA keys.

-list

Lists all the entities contained in the keystore.

-new newpassword

Specifies the new password for the keystore and all the keys in the keystore. The password must contain at least six characters.

-password password

Specifies the password for the keystore. If a password is not specified, the user is prompted for a password. The password must contain at least six characters.

-private

Specifies the private keystore as the target of the operation.

-validity days_valid

Number of days the self-signed certificate is valid.

-trust

Specifies the trust keystore as the target of the operation.

Example 7–1 crkeys Command Syntax

The following examples show how to use the crkeys command.

To generate a public-private key pair:

crkeys -private –generate –alias application_hostname [-keyalg keyalg] 
[-keysize keysize] [-validity days_valid] [–password password]

To export the self signed public key for a key pair to a file:

crkeys -private –export –file cert_file
 –alias application_hostname [–password password]

To import an exported, as shown in the previous example, self signed public key into the trust store:

crkeys –trust –import –file cert_file
 –alias application_hostname [-password password] 

To delete a key or key pair:

crkeys {-private|–trust} -delete
 –alias application_hostname [-password password] 

To list all of the public keys:

crkeys {-private|–trust} –list [-password password]

To change the SSL keystore, both the trust and the private store, password:

crkeys –cpass -password oldpassword 
-new newpassword

To print instructions for using the crkeys command:

crkeys -help

Configuring SSL

During the installation, each application is configured to do the following:

• Support cipher suites that require server authentication.

• Do not require client authentication.

• Find the private keystore in the N1SPS5.0-home/app/data/private.store file.

• Find the trust keystore in the N1SPS5.0-home/app/data/trust.store file.

• Supply empty passwords for each keystore.

You can change the SSL configuration of each application to perform the following security checks:

• Selectively enable cipher suites on each application

  You can explicitly specify which cipher suites to enable. If unspecified, the reference implementation uses the cipher suites that are enabled by default. The default cipher suites enabled by the reference implementation require server authentication. For the list of supported cipher suites, see SSL Cipher Suites.

• Specify that the application authenticates the SSL clients that are connecting to it

• Specify the location and password of the private and trust keystores

To enable authentication, you must initialize the keystores after installation of the application.

How to Configure SSL

Step

(Optional) Manually edit the config.properties file to change the SSL configuration.

The following table lists the settings in the config.properties file that are related to SSL configurations. Change the parameters based on the type of SSL connectivity you want to use.

Parameter	Default Value	Description
net.ssl.cipher.suites	SSL_RSA_WITH_3DES_EDE_CBC_SHA	A comma separated list of SSL cipher suites to enable. For a list of supported SSL Cipher suite, see SSL Cipher Suites.
net.ssl.client.auth	false	Specifies whether the SSL server should authenticate clients that are connecting to it.
net.ssl.key.store.pass		The keystore password. Required in some instances. See the following for more information.

---

Note –

The net.ssl.key.store.pass parameter specifies the SSL keystore password for an N1 Grid Service Provisioning System 5.0 application. Use this parameter when you configure an application with SSL keystores and you do not want to be prompted for the passwords to the keystore when you start the application. You must specify this parameter in the following instances:

• When you setup the N1 Grid Service Provisioning System applications to start automatically when the system boots

• On Windows servers, N1 Grid Service Provisioning System applications do not prompt for keystore passwords, so this parameter must be specified for any applications configured to use SSL on Windows servers.

• The CLI application does not prompt for keystore passwords, so this parameter must be specified for any CLI Clients that you configure to use SSL.

• If a Local Distributor is connected to its parent through an SSH connection, the Local Distributor cannot prompt for passwords.

---

Sample Configuration Scenarios

Example 7–2 How to Configure SSL Without Authentication Between the Master Server, Local Distributor, and Remote Agent

1. Install the Master Server, Local Distributor, and Remote Agent and select SSL when the installation program prompts you to select a connection type. When prompted to select a cipher suite, select encryption with no authentication.

2. Add the following property to the config.properties file for each application.

   net.ssl.cipher.suites=SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

   More than one cipher suite or a different cipher suite can be enabled. To enable multiple cipher suites, set the parameter to a comma separated list of cipher suites.

3. From the browser interface, create a new host.

4. On the host that you just created, add a Local Distributor with the connection type SSL.

5. Test the connection to the Local Distributor.

6. Create a new host.

7. On the host that you just created, add a Remote Agent with the connection type SSL.

8. Test the connection to the Remote Agent.

Example 7–3 How to Configure SSL Server Authentication

By default, cipher suites requiring server authentication are enabled, so no change is required in the config.properties file to enable cipher suites.

1. Generate a key pair for the Local Distributor and store it in the private keystore for the Local Distributor.

   % ld/bin/crkeys –private –generate –alias ldhostname.cr.com –validity 365

2. Export the self-signed certificate from the private keystore on the Local Distributor into a file.

   % ld/bin/crkeys –private –export –file ld.cert –alias ldhostname.cr.com

3. Copy the self-signed certificate for Local Distributor to the Master Server.

4. Import the self-signed certificate into the Master Server trust keystore.

   % server/bin/crkeys –trust –import –file ld.cert –alias ldhostname.cr.com

5. Create a new host.

6. On the new host, add a Local Distributor with the connection type SSL.

7. For the Local Distributor, use the CLI net.gencfg command to manually generate the transport.config file.

8. Copy the transport.config file to the Local Distributor.

9. If already running, stop and the Master Server and the Local Distributor.

10. Start the Master Server and the Local Distributor.

11. Provide the keystore password for the Master Server and Local Distributor.

12. Test the connection to the Local Distributor.

13. Generate a key pair for the Remote Agent and store it in the private store for the Remote Agent.

    % agent/bin/crkeys –private –generate –alias rahostname.cr.com –validity 365

14. Export the self-signed certificate from the private store on the Remote Agent into a file.

    % agent/bin/crkeys –private –export –file ra.cert –alias rahostname.cr.com

15. Copy the self-signed certificate for the Remote Agent to the Local Distributor.

16. Import the self-signed certificate into the Local Distributor trust store.

    % ld/bin/crkeys –trust –import –file ra.cert –alias rahostname.cr.com

17. Create a new host.

18. On the new host, add a Remote Agent with the connection type SSL.

19. For the Remote Agent, use the CLI net.gencfg command to manually generate the transport.config file.

20. Copy the transport.config file to the Remote Agent.

21. If already running, stop the Local Distributor and Remote Agent.

22. Start the Local Distributor and the Remote Agent.

23. Provide the keystore password for the Local Distributor and Remote Agent.

24. Test the connection to the Remote Agent.

Example 7–4 How to Configure SSL Server and Client Authentication

1. Install the Master Server, Local Distributor, and Remote Agent and select SSL when the installation program prompts you to select a connection type. When prompted to select a cipher suite, select encryption with authentication.

2. Generate a key pair for the Local Distributor and store it in the private store for the Local Distributor.

   % ld/bin/crkeys –private –generate –alias ldhostname.cr.com –validity 365

3. Generate a key pair for the Master Server and store it in the private store for the Master Server.

   % server/bin/crkeys –private –generate –alias mshostname.cr.com –validity 365

4. Export the self-signed certificate from the private store for the Local Distributor into a file.

   % ld/bin/crkeys –private –export –file ld.cert –alias ldhostname.cr.com

5. Copy the self-signed certificate for the Local Distributor to the Master Server.

6. Import the self-signed certificate into the Master Server trust store.

   % server/bin/crkeys –trust –import –file ld.cert –alias ldhostname.cr.com

7. Export the self-signed certificate from the private store for the Master Server into a file.

   % server/bin/crkeys –private –export –file ms.cert –alias mshostname.cr.com

8. Copy the self-signed certificate for the Master Server to the Local Distributor.

9. Import the self-signed certificate into the Local Distributor trust store.

   % ld/bin/crkeys –trust –import –file ms.cert –alias mshostname.cr.com

10. If already running, stop the Master Server and the Local Distributor.

11. Start the Master Server and the Local Distributor.

12. Provide the keystore password for the Master Server and Local Distributor.

13. Create a new host.

14. On the new host, add a Local Distributor with the connection type SSL.

15. Test the connection to the Local Distributor.

16. Generate a key pair for the Remote Agent and store it in the private store for the Remote Agent.

    % agent/bin/crkeys –private –generate –alias rahostname.cr.com –validity 365

17. Export the self-signed certificate from private store for the Remote Agent into a file.

    % agent/bin/crkeys –private –export –file ra.cert –alias rahostname.cr.com

18. Copy the self-signed certificate for the Remote Agent to the Local Distributor.

19. Import the self-signed certificate into the Local Distributor trust store.

    % ld/bin/crkeys –trust –import –file ra.cert –alias rahostname.cr.com

20. Copy the self-signed certificate for the Local Distributor, that you exported in Step 4, to the Remote Agent machine.

21. Import the self-signed certificate into the Remote Agent trust store.

    % agent/bin/crkeys –trust –import –file ld.cert –alias ldhostname.cr.com

22. If already running, stop the Local Distributor and Remote Agent.

23. Start the Local Distributor and the Remote Agent.

24. Provide the keystore password for the Local Distributor and Remote Agent.

25. Create a new host.

26. On the new host, add a Remote Agent with the connection type SSL.

27. Test the connection to the Remote Agent.

Example 7–5 How to Configure SSL Authentication Between a CLI Client and Master Server

1. Install the Master Server and the CLI Client and select SSL when the installation program prompts you to select a connection type. When prompted to select a cipher suite, select encryption with authentication.

2. Generate a key pair for the Master Server and store it in the private store for the Master Server.

   % server/bin/crkeys –private –generate –alias mshostname.cr.com –validity 365

3. Generate a key pair for the CLI Client and store it in the private store for the CLI Client.

   % cli/bin/crkeys -private -generate -alias clihostname.cr.com.cr.com -validity 365

4. Export the self-signed certificate from the private store for Master Server private store into a file.

   % server/bin/crkeys –private –export –file ms.cert –alias mshostname.cr.com

5. Copy the Master Server self-signed certificate to the CLI Client.

6. Import the self-signed certificate into CLI Client trust store.

   % cli/bin/crkeys –trust –import –file ms.cert –alias mshostname.cr.com

7. Export the self-signed certificate from the private store for CLI Client into a file.

   % cli/bin/crkeys -private -export -file cli.cert -alias clihostname.cr.com

8. Copy the CLI Client self-signed certificate to the Master Server.

9. Import the self-signed certificate into the Master Server trust store.

   % server/bin/crkeys -trust -import -file cli.cert -alias clihostname.cr.com

10. If the Master Server is running, stop the Master Server.

11. Start the Master Server.

12. Provide the keystore password for the Master Server.

13. On the CLI Client, edit the config.properties file to include the following line:

    net.ssl.key.store.pass=trust-store-password

14. Run a CLI Client command to verify the connection.

SSL Cipher Suites

Cipher Suites for Solaris OS, Red Hat Linux, and Windows

The following lists describe the supported SSL cipher suites for Solaris OS, Red Hat Linux, and Windows servers.

The following suites require server authentication:

SSL_DHE_DSS_WITH_DES_CBC_SHA 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 
SSL_RSA_WITH_RC4_128_MD5 
SSL_RSA_WITH_RC4_128_SHA 
SSL_RSA_WITH_DES_CBC_SHA 
SSL_RSA_WITH_3DES_EDE_CBC_SHA 
SSL_RSA_EXPORT_WITH_RC4_40_MD5 
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA

The following suites do not require server authentication:

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA 
SSL_DH_anon_WITH_DES_CBC_SHA 
SSL_DH_anon_WITH_RC4_128_MD5 
TLS_DH_anon_WITH_AES_128_CBC_SHA

The following suites require server authentication with no encryption:

SSL_RSA_WITH_NULL_MD5 
SSL_RSA_WITH_NULL_SHA 

Cipher Suites for IBM AIX

The following lists describe the supported SSL cipher suites for IBM AIX servers.

All of the following cipher suites are available for use with Remote Agents. Cipher suites that do not require server authentication cannot be used for Local Distributors.

The following suites require server authentication:

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_FIPS_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

The following suites do not require server authentication:

Cipher suites that do not require server authentication cannot be used for Local Distributors.

SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA

The following suites require server authentication with no encryption:

SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA