IBM Support

Does the RRT agent support TLS 1.1/1.2 and 256-bit ciphers?

Question & Answer


What do you need to do to configure the Robotic Response Time (RRT) agent to support TLS 1.1/1.2 and 256-bit ciphers?


Support for TLS 1.1/1.2 and 256-bit ciphers is determined by the underlying JRE (Java Runtime Environment). Consequently, in order to support TLS 1.1/1.2 and 256-bit ciphers, patch the RPT workbench JRE, and patch the RRT agent JRE. Both JREs must support the same level of TLS.



SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are transport layer protocols. Ciphers implement security by providing the encryption mechanism.

TLS is the new protocol. SSL protocol got up to version 3.0. In effect, TLS 1.0 is SSL 3.1. Currently, TLS versions include TLS 1.1 and 1.2. Each new version adds new features and modifies internal details.

Whether the RRT agent supports TLS1.1/1.2 depends on whether the underlying JRE supports TLS 1.1/1.2. The JRE that supports the RRT agent and the JRE that supports RPT workbench must both support the same version of TLS and the same ciphers.

For example, RRT 7.3 FP01 supports RPT, but RPT does not support TLS1.1/1.2. Consequently, RRT 7.3 FP01 also does not support TLS 1.1/1.2.

In comparison, RRT 7.4 with IF21 or IF24 ( or can support RPT 8.3 and RPT 8.6 since RPT 8.6 supports TLS1.1 /1.2, and the IBM Java 7 included with RRT 7.4 also supports TLS 1.1/1.2.

However, when a script uses TLS 1.2/1,2, some ciphers may not be supported. To verify whether certain cipher suites are supported, visit the IBM Java Knowledge Center:

IBM Java Cipher Suite Information

Do You Need to Patch Java?

First, determine whether your script uses 256-bit ciphers. In RPT workbench, open the script in Test Editor mode. In the left panel, drill down through the Server Access Configurations. Select SSL.

In the right panel, examine the available ciphers that display. If the list contains 256-bit ciphers, you need to support Strong Encryption in RPT and the RRT agent. The name identifies the encryption level. For example, SSL_DHE_RSA_WITH_AES_256_CBC_SHA is a 256-bit cipher. The presence of 256 in the cipher name means that the cipher supports 256-bit encryption.

Cipher Naming Conventions

In RPT workbench, the cipher name always begins with "SSL" to simplify naming conventions. If the script uses TLS as the protocol in the test, then the cipher is a TLS cipher.

Playback Symptoms

Check whether your script playbacks indicate that the RRT JRE needs to be patched to support Strong Encryption. Strong Encryption adds 256-bit ciphers.

1) The Playback Status workspace shows that playbacks are complete, but the Verification Failures workspace shows:

Event Type: Generic Failure

Violated Value: java.lang.RuntimeException occurred in IBM Registration. Message: /tmp/RPTTEMP.A1E4CC464D3DD067D

Additional Details: none

2) The trace-robotic log includes messages like the following:

[2015-05-05T22:10:58.487-04:00] -  MIN  - <playback-hostname> - PlaybackThreadPoolWorker-1169 - - Sending RT VP event: i=|0|, statusEvent=|SimTestStatusEvent Values: monitorName=|<script-name>|,URL=|<monitored-url>|,eventType=||,eventId=|516.b32|,parentEventId=|516.b27|,ownerId=|A1E4ED99F22F68E2FD5CB86461633031|,text=|Error occurred during connection to server '<server-url>'.  Explanation message: 'Cannot support SSL_DHE_RSA_WITH_AES_256_CBC_SHA with currently installed providers'. Since this request is the primary request for the current page all secondary requests will be skipped and the next page will be attempted.|,name=|Primary Request verdict|,actualValue=||,expectedValue=|null|,eventVerdict=|3|,eventReason=|2|,eventDesc=|null||

Patching JREs to Support TLS 1.1/1,2

By default, RPT workbench is configured with restricted or limited strength ciphers. To use less restricted encryption algorithms, you need to download and apply the unlimited jurisdiction policy files (local_policy.jar and US_export_policy.jar).

See Enabling Strong encryption greater than 128 bit key lengths in Rational Performance Tester

Use the following instructions to patch the JRE that the RRT agent uses.

Note: Backup the jar files that these steps replace -- before you replace these files.

1) Go to the IBM developerWorks Java Technology Security page for JRE 6 security information.

2) Click on the "Java SE 6" link.

3) Click on the "IBM SDK Policy files".

4) On the Sign in page, enter your developerWorks IBM ID and password.

5) After successfully logging in, select Files for Java 5.0 SR16, Java 6 SR13, Java 6 SR5 (J9 VM2.6), Java 7 SR4, and all later releases. Click on Continue.

6) Scroll down to the License portion of the resulting page and click on the View license link to see the licensing terms for the download.

7) If the licensing terms are acceptable, check I agree and click on the I confirm link. If the terms are not acceptable, you are not able to enable strong encryption, and you should click I cancel.

8) Click on the Download now link to download the file.

9) Extract the local_policy.jar and US_export_policy.jar files from the archive.

10) Log onto the RRT agent host, and stop the RRT agent.

11) Backup the local_policy.jar and US_export_policy.jar files in the following directories on the RRT agent host:

12) Replace the local_policy.jar and US_export_policy.jar files in the following directories on the RRT agent host:
Verify that the file permissions are the same as the files you replaced.

13) Restart the RRT agent.

14) Try to playback the RPT script again. Does the script playback successfully, without error?

[{"Product":{"code":"SS5MD2","label":"Tivoli Composite Application Manager for Transactions"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":"ITCAM TRANSACT RRT 5724S79RR v710","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.4","Edition":""}]

Historical Number


Product Synonym


Document Information

Modified date:
12 March 2019