Configuring the internal communication channel (CDP, HA-CDP, AP, and LAP ports)

This page describes how to configure the secure transport protocol and cipher suite for the internal communication channel (JMS/Apache Active MQ), which includes HTTPS ports for the configuration distribution peer (CDP). High Availability-CDP (HA-CDP), activity peer (AP), and lightweight activity peer (LAP).

In this page, AO_HOME represents the installation directory for BMC  Atrium Orchestrator peers, such as the CDP, HA-CDP, AP, or LAP).

Note

Instructions for the CDP apply to the HA-CDP.

This page includes the following sections:

Configuration overview

Configuring the internal communication channel involves the following steps (described in this page):

  1. Configure the CDP (HA-CDP).
  2. Confirm the configuration changes across all peers.

You will use the broker-config.xml configuration file, located in the AO_HOME/server/.jms directory, to configure the secure transport protocol and allowed cipher suites on the CDP (HA-CDP).

The secure transport protocol and cipher suites are defined in the broker-config.xml using the element <cipher-suites>.

An example is provided in the instructions in this page.

Secure transport protocols

To configure a transport protocol version, you need to modify the uri string in the broker-config file using with the socket.enabledProtocols to specify the protocol.

The following example broker-config file is configured for tlsv1.2. If you are configuring a protocol, use this example for guidance.

<broker-config>
<external>false</external>
<uri>ssl://172.22.185.246:61719?connectionTimeout=1000&amp;socket.enabledProtocols=TLSv1.2</uri>
<cipher-suites>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384</cipher-suites>
</broker-config> 

The following table lists the supported secure transport protocol values: 

Secure transport protocol value

Notes
tlsUse the JVM default version of the TLS algorithm.
tlsv*

Use a specific TLS version where * is a version.

For example: tlsv1.2

Cipher suites

For a list of cipher suites that you can use for SSL connections, see Cipher suites for 7.8.02 and later

The current BMC Atrium Orchestrator release installs Java SE Runtime Environment (build 1.7 update 76). The cipher suites listed in Cipher suites for 7.8.02 and later are installed with the BMC Atrium Orchestrator release. Cipher suites listed as default are enabled. Unless a different list is defined for SSL, handshaking on an SSL connection will use one of these cipher suites. 

Before you begin

Before configuring the internal communication channel, ensure that you have completed the following:

  • Installed the BMC Atrium Orchestrator components, completed any post-installation configuration, and ensured that everything is working properly.
  • Configured BMC Atrium Orchestrator to use HTTPS (see Configuring BMC Atrium Orchestrator to use HTTPS).
  • Checked your web browser documentation for information about supported protocols and cipher suites.
  • Checked with your network administrator to ensure that the chosen protocol and cipher suite are supported by your network environment.
  • Made backup copies of the following files:

    Warning

    It is very important that you back up these files, so that you can revert back to the original files if needed.

CDP and HA-CDP configuration steps 

To configure the secure transport protocol and allowed cipher suites for a CDP

  1. Shut down the CDP service, called BAO-CDP-Distribution Peer (see Starting and stopping product components and services for instructions).
  2. Navigate to the AO_HOME/server/.jms directory and edit the broker-config.xml file, making the following two changes (use the example broker-config.xml file for guidance):

    <broker-config>
      <external>false</external>
      <uri>ssl://10.1.32.34:61719?connectionTimeout=1000&amp;trace=true</uri>
      <cipher-suites>TLS_RSA_WITH_AES_128_CBC_SHA</cipher-suites>
    </broker-config>
    • Change the protocol string in the <uri> element's value if applicable for your company's security policy.

    • Add the cipher suite name to the <cipher-suites> element's value.

  3. Startup the CDP service (see Starting and stopping product components and services for details). 
    After starting the service, the management.CDP.JMS_DISCOVERY file is automatically updated with the protocol and cipher suite information from the broker-config.xml file. 

  4. Check the grid log files for any connection failures, such javax.net.ssl.SSLHandshakeException exceptions. If there are issues, see Troubleshooting.

Confirm the configuration changes across all peers 

Confirm that the CDP configuration changes were made to all peers in your environment.

To confirm the configuration changes on all peers

  1. Restart all of the APs and LAPs in your environment (see Starting and stopping peers for instructions). 
    After restarting the APs and LAPs , the management.CDP.JMS_DISCOVERY file is automatically updated with the protocol and cipher suite information from the CDP broker-config.xml file.
  2. Check the grid log files on each peer for any connection failures, such javax.net.ssl.SSLHandshakeException exceptions. If there are issues, see Troubleshooting.
  3. If you have a Development Studio installed in your environment, log out and log back into Development Studio.
    If you have any issues running your workflows, see Troubleshooting.

Troubleshooting

Use the instructions in this section to troubleshoot issues with the transport protocol and cipher suite configurations.

Troubleshooting the CDP (HA-CDP) configuration

If you have connection failures in the grid log files, complete the following steps on your CDP or HA-CDP:

  1. Navigate to the AO_HOME/server/.jms/disco directory, view the management.CDP.JMS_DISCOVERY file, and check the broker-uri value to verify that it is updated with the protocol name and cipher suite name.
    It should look similar to one of the following examples:

    • With secure transport protocol

      <broker-uri>failover:(ssl://10.1.32.34:61721?connectionTimeout=1000&amp;socket.enabledProtocols=TLSv1.2&amp;socket.enabledCipherSuites=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384)?randomize=false&amp;maxReconnectAttempts=1</broker-uri>
    • Without secure transport protocol

      <broker-uri>failover:(ssl://10.1.32.34:61719?connectionTimeout=1000&amp;trace=true&amp;socket.enabledCipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA384)?randomize=false&amp;maxReconnectAttempts=1</broker-uri>
    • If you have multiple IPs on a CDP or HA-CDP, the example will have 2 SSL lines separated by a comma, as shown in the following example:

      <broker-uri>failover:(ssl://10.1.32.34:61721?connectionTimeout=1000&amp;socket.enabledProtocols=TLSv1.2&amp;socket.enabledCipherSuites=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
      ssl://10.1.32.35:61721?connectionTimeout=1000&amp;socket.enabledProtocols=TLSv1.2&amp;socket.enabledCipherSuites=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384)?randomize=false&amp;maxReconnectAttempts=1</broker-uri> 
  2. If the value does look like this example, complete the following steps:
    1. Stop the CDP.
    2. Edit the management.CDP.JMS_DISCOVERY file and modify the broker-uri value (as shown above).
    3. Start the CDP.
  3. If you still see errors in the grid.log files, complete the follow steps to gather debugging information:
    1. Temporarily append the string -Djavax.net.debug=ssl to the jvm startup options. This writes TLS debug information into the BAO stdout log file (located in AO_HOME/tomcat/logs).
        • In Windows environments, use one of the following steps:
          • (Recommended) Use the tomcat7w.exe as follows:
            1. Start the tomcat7w.exe (for example, tomcat7w.exe //MS//BAO-CDP).
            2. Open the daemon service manager.
            3. On the Java tab, add -Djavax.net.debug=ssl to the Java entries and click Apply.
          • Modify the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\BAO-CDP\Parameters\Java\Options.
        • In UNIX environments, use the server.sh file.
    2. Restart the CDP.
    3. Check to the BAO stdout log file for troubleshooting. See Using the BAO stdout log file for troubleshooting.

Troubleshooting the AP and LAP configurations

If you have connection failures in the grid log files, use the following procedure for each peer:

  1. Navigate to the AO_HOME/server/.jms/disco directory, view the management.CDP.JMS_DISCOVERY file, and check the broker-uri value to verify that it is updated with the protocol name and cipher suite name.
    It should look similar to the following example:

    <broker-uri>ssl://10.1.32.34:61719?connectionTimeout=1000&socket.enabledCipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA</broker-uri> 
  2. If the value does look like this example, complete the following steps:
    1. Stop the peer.
    2. Edit the management.CDP.JMS_DISCOVERY file and modify the broker-uri value (as shown above).
    3. Start the peer.
  3. If you still see errors in the grid.log files, complete the follow steps to gather debugging information:
    1. Temporarily append the string -Djavax.net.debug=ssl to the jvm startup options. This writes TLS debug information into the BAO stdout log file (located in AO_HOME/tomcat/logs).
        • In Windows environments, use one of the following steps:
          • (Recommended) Use the tomcat7w.exe as follows:
            1. Start the tomcat7w.exe (for example, tomcat7w.exe //MS//BAO-AP).
            2. Open the daemon service manager.
            3. On the Java tab, add -Djavax.net.debug=ssl to the Java entries and click Apply.
          • Modify the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\BAO-AP\Parameters\Java\Options.
        • In UNIX environments, use the server.sh file.
    2. Restart the peer.
    3. Check to the BAO stdout log file for troubleshooting. See Using the BAO stdout log file for troubleshooting.

Using the BAO stdout log file for troubleshooting 

The instructions recommended that you temporarily add -Djavax.net.debug=ssl to the jvm startup options. This writes TLS debug information into the BAO stdout log file (located in AO_HOME/tomcat/logs). You can use this for troubleshooting problems, for example, the cipher suite is not supported by the JVM or secure transport protocol or there is a mismatch of the specified cipher suite between the client and server. Look for SSL handshake error messages in the log file.

The following example shows a BAO stdout log file. 

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
AMP - Grid Framework - Advertisement Processor - 1, setSoTimeout(0) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1416068893 bytes =
Unknown macro: { 216, 19, 106, 164, 65, 55, 197, 54, 102, 136, 149, 66, 64, 161, 47, 61, 9, 155, 144, 113, 104, 20, 108, 252, 78, 173, 30, 72 }
Session ID:  {}
Cipher Suites: [~mgay:TLS_RSA_WITH_AES_128_CBC_SHA]
Compression Methods: 
Unknown macro: { 0 }
Extension renegotiation_info, renegotiated_connection: <empty>
***
ActiveMQ Transport: ssl:///10.1.32.34:61719, WRITE: TLSv1 Handshake, length = 52
ActiveMQ Transport: ssl:///10.1.32.34:61719, READ: TLSv1 Handshake, length = 779
*** ServerHello, TLSv1
RandomCookie:  GMT: 1416068582 bytes =
Unknown macro: { 148, 114, 211, 88, 194, 97, 123, 51, 209, 212, 97, 73, 252, 255, 196, 16, 160, 73, 123, 190, 169, 172, 83, 2, 111, 231, 156, 250 }
Session ID: 
Unknown macro: {84, 103, 126, 230, 230, 55, 172, 31, 175, 97, 62, 213, 229, 20, 96, 135, 84, 25, 125, 190, 47, 144, 159, 186, 170, 23, 118, 107, 69, 6, 165, 40}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized:  [~mgay:Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA 
Was this page helpful? Yes No Submitting... Thank you

Comments