Alternative Method to Support TLS 1.2 on EPM 11.1.2.x

An issue is described for Active Directory authentication in the document "Oracle Enterprise Performance Management System Tips and Tricks from EPM System Infrastructure Development: Issues 103 and Higher" as well as Oracle Support Document 2482392.1. The error that is shown is "EPMCSS-05318: Failed to validate Security Configuration. Failed to connect. Invalid values for host or port. Enter valid value(s)" and the cause is that TLS 1.2 is not supported by JDK 160_35. The given solution is to upgrade the version of the JDK to 1.7.0_161.

However I recently came across another method to support TLS 1.2 on versions of Java that do not otherwise support it. The advantage to this method is that it does not require large changes to the infrastructure I found this method on a Stack Overflow answer and can confirm that it does work. 

The first step is to take a backup of the correct files in the JDK/JRockIt folders. For JRockIt the folder would be similar to: E:\Oracle\Middleware\jrockit_160_37\jre\lib\security\ and the files to backup are:

• java.security
• local_policy.jar
• US_export_policy.jar

Next download the JCE Unlimited Strength Jurisdiction Policy Files 6 and copy the following 2 files to the same folder as before, overwriting the existing files:

• local_policy.jar
• US_export_policy.jar

Now go over to the latest releases section of the Bouncy Castle website. Download the latest bctls-jdk15to18-* and bcprov-jdk15to18-* JAR files, as of 24/08/2020 these would be:

• bcprov-jdk15to18-166.jar
• bctls-jdk15to18-166.jar

Drop these JAR files into the /jre/lib/ext/ folder - for the JRockIt installation this would be similar to: E:\Oracle\Middleware\jrockit_160_37\jre\lib\ext\.

Finally go to the java.security file, for the JRockIt installation this would be: E:\Oracle\Middleware\jrockit_160_37\jre\lib\security\java.security. Open the file and look for the list of security providers. By default this section will look like this:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.8=sun.security.smartcardio.SunPCSC

We need to replace this whole section with this:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
security.provider.3=sun.security.provider.Sun
security.provider.4=sun.security.rsa.SunRsaSign
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.6=com.sun.crypto.provider.SunJCE
security.provider.7=sun.security.jgss.SunProvider
security.provider.8=com.sun.security.sasl.Provider
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.10=sun.security.smartcardio.SunPCSC

ssl.SocketFactory.provider=org.bouncycastle.jsse.provider.SSLSocketFactoryImpl

After these changes all that is required is to restart the WebLogic servers and TLS 1.2 will be used by default.

Here is a snippet from Netmon showing how with this change, TLS 1.2 being used for the LDAP connection to MSAD:

Versus what happens without this change:

 

What we have done is install the Bouncy Castle security provider and unlock greater strength for cryptographic functions.

By default Java is constrained in what security it can provide, for example we are limited to AES keys with a maximum size of 128 bits. The policy files we downloaded makes sure that Java isn't limited by these default restrictions. These policy files are only valid for versions of Java lower than 8u161, 7u171 and 6u181 - versions of Java later than this already use the unlimited policy files.

The second part - and the most important - is that now Bouncy Castle is handling all SSL communications, instead of the default JRE providers. Bouncy Castle is a library to provide access to a wide range of cryptographic functions, and it uses the Java Cryptographic Extension (JCE) technology to transparently provide these to the JRE. Bouncy Castle supports not just TLS 1.2 but lots of other algorithms, whereas the default JCE provider has a more limited selection.

You can see how using Bouncy Castle we are able to support a wider range of cryptographic functions in EPM 11.1.2.x. Given that this is done at the JRE level it can be done for any JRE and as seen in the Stack Overflow answer, is generic to all Java installations.

Edit: Please note that if you set SSL certificates in WebLogic this will also upgrade the protocols used on the SSL listening ports from TLS 1.0 to TLS 1.2! This can cause issues with OHS, since OHS 11.1.1.7 (the version shipped with 11.1.2.3 and 11.1.2.4) can only support up to TLS 1.0.