TLS (Transport Layer Security) is the successor to SSL and is used to encrypt transmissions over the network and the web. TLS 1.2 is the most secure protocol available till date for use.
In order to successfully establish TLS 1.2 communication with external clients and enabling TLSv1.2 protocol in Web Logic Server the steps are classified as:

  1. Migrate to SHA2 compliant certificates in WLS trust and identity stores. (Refer Support for SHA2 certificates in WLS section given below)
  2. Migrate/Re-generate SHA2 compliant certificates. (Refer How to migrate keystores to use SHA2 certificates givem below)
  3.  Add/set all the required properties in WLS to pick TLS 1.2 protocol for secure communication.



Note that SHA2 migration is a pre-requisite of TLS 1.2 communication. Thus, follow the related document prior to following the steps to enable TLSv12 given below. The steps which I have mentioned below are  done on a non - clustered , single node instance of Weblogic. In case of clustered setup, You need to do the steps on all the  nodes.

Important Information / Notes:

Oracle JDK version information regarding support of SHA-2 cipher suites and TLS version 1.2, please refer https://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_121


 IBM Java 7, SR4 version supports SHA-2 cipher suites and TLS version 1.2. For more details on this please check with IBM.


In WLS12c (12.1.1 and up), JSSE is the default SSL implementation and Certicom was removed.

TLS 1.1 and 1.2 is supported with a combination of JDK 7 Update 1 (or later) and JSSE enabled.

JDK 6 Update 1.6.0_121 adds support for TLS 1.2 on all platforms. 


Disabling SSL / TLS Protocol  for Oracle WebLogic Server

WebLogic Server versions (8.1 + ) allow SSL 2.0 and SSL 3.0 to be disabled with the following parameter at startup as a JAVA_OPTION because TLS 1.0 is minimally supported on all versions:
 
-Dweblogic.security.SSL.protocolVersion=TLS

  • For Certicom, setting -Dweblogic.security.SSL.protocolVersion=TLS1 enables only TLS 1.0.
  • For JSSE, setting -Dweblogic.security.SSL.protocolVersion=TLS1 enables any protocol starting with "TLS", for example TLS 1.0, TLS 1.1, and TLS 1.2.

Older protocols can also be disabled by configuring a minimum higher protocol for example to gain, support of TLSv1.1 or TLSv1.2 protocols, use the following as JAVA_OPTION

              -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1 


Enabling TLS 1.2 for Weblogic Servers



A SHA2 compliant certificate is a pre-requisite for using TLS 1.2 protocol for SSL communication.  

Complete steps [1-4] below to generate SHA2 compliant certificates first.

  1.          Move to SHA2 compliant certificates in Identity and Trust stores.
  2.          Update to the latest PSU for the Weblogic Server version. (If applicable)
  3.          Edit $DOMAIN_HOME/bin/setDomainEnv.sh file to set following Java options for enabling TLS 1.2 on Weblogic servers.

TLS_JAVA_OPTIONS=" -Djavax.net.ssl.trustStore=<TRUST_KEYSTORE> -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.SSL.enforceConstraints=off -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.security.SSL.protocolVersion=TLSv1.2  -Dhttps.protocols=TLSv1.2   -Djdk.tls.client.protocols=TLSv1.2 -Djdk.tls.disabledAlgorithms=SSLv2Hello,SSLv3,TLSv1,TLSv1.1 -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2"

 4.  Start the Admin server and managed servers. All server communication will happen on TLS 1.2 after this start. We can enable SSL logs by adding below Java options either while starting the server or in “DOMAIN_HOME/bin/setDomainEnv.sh” file:

-Dssl.debug=true -Djavax.net.debug=ssl:handshake:verbose

Support for SHA2 certificates in WLS


                   SHA2 signed certificates and ciphers are supported under these conditions with Oracle WebLogic Server:
  • WebLogic Server 10.3.6 and prior versions do not support SHA2 signed certificates or cipher suites when using the default Certicom SSL.
  • The following WebLogic Server versions support SHA2 cipher suites when using JSSE SSL and the following JDK versions:
    • WLS 10.3.6 with JDK 7 and JSSE enabled using the JDK's JSSE provider
    • WLS 12.1.1 with JDK 7 and JSSE enabled using the JDK's JSSE provider
    • WLS 12.1.2 (or later) with JDK 7 (or later) and JSSE enabled using the JDK's JSSE provider
  • The following WebLogic Server versions support SHA2 signed certificates when using JSSE SSL and the following JDK versions:
    • WLS 10.3.3 - 10.3.6 with JDK 6 and JSSE enabled using the JDK's JSSE provider
    • WLS 10.3.6 with JDK 7 and JSSE enabled using the JDK's  JSSE provider
    • WLS 12.1.1 with JDK 7 and JSSE enabled using the JDK's  JSSE provider

  • WLS 12.1.2 (or later) with JDK 7 (or later) and JSSE enabled using the JDK’s JSSE provider

Notes:
- See docs to enable JSSE  - https://docs.oracle.com/cd/E23943_01/web.1111/e13707/ssl.htm#SECMG494

- Note some versions may have expired support. Check Note 950131.1 for current support status.
- For expiring JDK versions, see Note 952075.1 for the Java SE End of Life and Oracle Fusion Middleware Policy
- For more detail on support provided in the JDK's JSSE provider, consult the applicable JDK documentation


How to migrate key stores to use SHA2 certificates?


Steps to replace the certificates managed by WebLogic Server. The steps described are for a non-clustered setup, for clustered setup update the key store at the admin server node and copy the updated key stores from the admin node to all the other nodes.

Steps:-
  •         Identify the key stores in use at WLS server level.
  •         Identify the signing algorithm used in these certificates
  •           Identify the alias in use against existing identity key store
  •           Delete the above identified alias from the existing identity key store if signing algorithm is not SHA2
  •           Generate a new key with same alias name in existing identity key store
  •           Export the trust certificate from existing identity key store
  •           Identify the alias name used to import the trust certificate of identity key store in existing trust key store
  •           Delete the above identified alias from existing trust key store if signing algorithm is not SHA2
  •           Import the newly exported trust certificate from existing identity key store to existing trust keystore


Identifying  key stores IN USE at Web Logic.
 

·         Login to WLS admin console.
·         Click on “Environment” à “Servers”.
·         Click on the name of any server listed.
·         Go to “Configurations” à “Key stores” tab listed on top.
·         Check the key store listed here. E.g. Custom Identity and Custom Trust, Demo Identity and Demo trust etc.
·         Check the trust and identity key stores listed here. These are the ones which are actively used for SSL communication.
·         Repeat above steps for all managed servers and admin server.

In order to identify the signing algorithm of certificates used in all key stores (Custom or Demo), use the below commands/ steps.

keytool -list –v -key store <keystore_file_name>

If you are using CA signed certificates, you will need to have the CA re-issue SHA2 certificates. After generating the CSR from these key stores in use, you will need to a)    get the CSR signed by the CA and  b)    Import user and trust certificates back into the identified key stores.

Ensure to use 2048 key length and SHA256 signing algorithm during certificate signing request generation, also ensure all other details provided in the CSR is same as existing certificates.

For regenerating self-signed certificates, identify the alias in use for the given custom identity key store.
  • In WLS Console Click on “Environment” à “Servers”.
  • Click on the name of any server listed here.
  • Go to “Configurations” à“SSL” tab listed on top.
  •  Check the alias listed here. e.g. “support”.
  •  Repeat above steps for all managed servers and admin server,

Take a backup of the existing identity key store.

Delete the above identified alias (example support) from existing custom identity key store signing algorithm is not SHA2 for the same using the below command.

keytool -delete -alias <identified alias> -key store <existing_custom_identity_store> -storepass <existing_custom_identity_store_password>

Create new key with same alias name in existing custom identity key store using below command:

keytool -genkey -alias <identified_alias> -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "<dn_name>" -keypass <any-password-of-choice-for-private-key>  -keystore <existing_custom_identity_store> -storepass <existing_custom_identity_store_password>

e.g.
keytool -genkey -alias support -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "CN=myhost.com, OU=Identity, O=My Corporation,C=US" -keypass welcome1  -keystore /u01/jdk6u35_b10/jre/bin/custom_identity_store.jks -storepass welcome1

Create self-signed certificate in existing custom identity key store using below command:

keytool -selfcert -alias <alias_name> -sigalg SHA256withRSA -keypass < any-password-of-choice-for-private-key> -keystore <existing_custom_identity_store> -storepass <existing_custom_identity_store_password>e.g.keytool -selfcert -alias support -sigalg SHA256withRSA -keypass welcome1 -keystore /u01/jdk6u35_b10/jre/bin/custom_identity_store.jks -storepass welcome1


Export above created self-signed certificate from existing custom identity keystore using below command:

keytool -export -alias <alias_name> -file <cert_file_name> -keypass <any-password-of-choice-for-private-key> -keystore <existing_custom_identity_store> -storepass <existing_custom_identity_store_password>
e.g.
keytool -export -alias support  -file /scratch/supportcert.pem -keypass welcome1 -keystore /u01/jdk6u35_b10/jre/bin/custom_identity_store.jks -storepass welcome1

Take backup of existing trust keystore and import this self-signed certificate in trust store but before delete the previous alias the existing certificate was imported. For example

keytool -delete -alias <existing_alias_name> -keystore <custom_trust_store> -storepass <password-of-existing-trust-keystore>
e.g.
keytool -delete -alias serverssl -keystore <DOMAIN_HOME>/config/fmwconfig/custom_trust_store.jks -storepass welcome1


Import the new certificate against the same

keytool -import -alias serverssl -trustcacerts -file <cert_file_name> -keystore <custom_trust_store>  -storepass <password-of-existing-trust-keystore>
e.g.
keytool -import -alias serverssl -trustcacerts -file /scratch/supportcert.pem -keystore <DOMAIN_HOME>/config/fmwconfig/custom_trust_store.jks -storepass welcome1

After this if you list the keystore then against “serverssl” alias it will show a SHA2 certificate algorithm.
Similarly, update all the required self-signed certificates in a given keystore.

Web Services and Client Applications (Out bound Connections)
When applications are running as client for example web services and to invoke remote connections, the below system property can be used to include TLSv1.0, 1.1 and 1.2.

-Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2

TLSv1.1 and TLSv1.2 protocol versions are supported but are not enabled by default when using earlier versions of JDK 6 and 7. We need to explicitly set them using the system above system property, else only TLS 1.0 will be used. The JDK 8 default allows both TLS 1.1 and 1.2 by default. It is important to consider the external servers the application is connecting to. The protocol will always be negotiated to the highest supported level between the client and server.
Older JDK versions only support TLS 1.0 for outbound client connections. 

The jdk.tls.client.protocols system property is available since 7u95 and 6u121 to be able to set this.

Testing Connections

A common method to test is by setting options on your browser and testing one protocol at a time . If you only want TLS 1.2 to work, then disable all other protocols in your browser settings.

If you have openssl on your system, you can test to ensure what you have configured is working with the following commands to connect:
openssl s_client -connect <hostname:port> -ssl_3
openssl s_client -connect <hostname:port> -tls1
openssl s_client -connect <hostname:port> -tls1_1
openssl s_client -connect <hostname:port> -tls1_2
Replace hostname and port with your server. The results depends on what you have configured. You definitely want to see -ssl_3 fail to avoid the Poodle vulnerability.  If you have configured a minimum TLS version, then you will want -tls1 to fail. Keep in mind you also need supported ciphers available for each protocol.  for example  Use the following to confirm listener accepts SSL_RSA_WITH_AES_256_CBC_SHA and TLS 1.2:

openssl s_client -connect <hostname:port> -tls1_2 -cipher AES256-SHA