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?

Internal Use Only

This technote was generated by Technote Kickstart based off of Tivoli Customer Support PMR 42430,082,000.
View the associated PMR's text via Wellspring at:
Whether T6 support TLS1.1/1.2 depends on the following two aspects:
1. TLS1.1/1.2 support by IBM JAVA included in T6
2. TLS1.1/1.2 support by RPT

So, since RRT just supports RPT8.3 and earlier, from RPT team, RPT8.3.0.3 did not support TLS1.1&1.2, then I think the earlier RPT should not support TLS1.1/1.2 too, so RRT and earlier did not support TLS1.1/1.2.

For RRT 7.4 with IFIX21 or IFIX24, it can support RPT8.6, RPT 8.3 and earlier. since RPT8.6 support TLS1.1 &1.2 and IBM Java 7 included in RRT7.4 support TLS 1.1&1.2, so when RPT 8.6 script uses TLS1.1/1/2 could be playback in RPT7.4, but some cipher suites may not supported. Whether the cipher suites is supported or not, customer can refer IBM Java knowledge center and the cipher suites supported by RPT 8.6.

Here is the cipher suites information of IBM Java:

I did not find the cipher suites supported by RPT8.6, for this, Harriet can ask RPT team for the information. @Harriet Johnson could you help to ask this information and let me know?

From the technote, I think we need to make some update to make it more clear about the TLS 1.1/1.2 support by ITCAM RRT 7.4.

And for Harriet's question: what 256-bit ciphers have to do with TLS 1.x.:
Actually, I did not have answer, since I am not quite familiar with the details of SSL/TLS, but I think we do not need to care this based on the above.

In the technote, when customer meet the error "'Cannot support SSL_DHE_RSA_WITH_AES_256_CBC_SHA with currently installed providers' ", then update IBM Java policy files to solve this issue, is based on the following information in IBM JAVA knowledge center:

** Cipher suites that use AES_256 require installation of the JCE Unlimited Strength Jurisdiction Policy Files

Thank You & Best Regards
Huang Wei Ping (黄伟平)


TLS is Transport Layer Security

Securitiy is done by encrption

Encrpytion requires a cipher

Complete list is:

The best way to check availability of cipher suites is to look at the WireShark capture of a recording and playback.

With RPT and the TLS 1.2 hotfix, my recording's ClientHello specified support for 21 suites:

 At least one of these, TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d), overlaps with the list you provided from the FBI.

For playback, the ClientHello specifies 80 (!) suites:

The TLS_RSA_WITH_AES_256_CBC_SHA256 comes first in this list because that's the one I specified in the test:

Admittedly, the test specifies "SSL_" at the beginning instead of "TLS_" but that's just a convention we use to simplify things.  If you're using TLS as the Protocol in the test, then we'll use a TLS cipher.

Scott Didier


1. to see what ciphers are available filter on tcp.port == 443 in Wireshark and click on the Client.hello
then click on Cipher suites

2. We don't have a web site that lists the suites for 8.6, the above method is one way to find out the suites. I couldn't export the list as text

The list of ciphers differs with the version of the jvm shipped with RPT and if the java policy files are installed
Paul Liskay

[{"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 Alias/Synonym


Document Information

Modified date:
12 March 2019