This explains how to use the JSSE-based SSL implementation, identifies the cipher suites that are supported, describes key differences with the Certicom-based implementation, and also explains how to use the RSA JSSE provider with WebLogic Server 12.1.3.
Notes:
Note the following:As of WebLogic Server version 12.1.1, JSSE is the only SSL implementation that is supported. The Certicom-based SSL implementation is removed and is no longer supported in WebLogic Server.
SHA-2 signed certificates are supported in the JSSE SSL implementation provided in WebLogic Server.
Although JSSE supports Server Name Indication (SNI) in its SSL implementation, WebLogic Server does not support SNI.
This chapter includes the following sections:
Table 39-1 shows the differences in how the JSSE-based SSL implementation handles the WebLogic system properties.
Table 39-1 System Properties Differences
System Property | JSSE Applicability | Description |
---|---|---|
weblogic.security.SSL.ignoreHostnameVerification |
This property continues to work and is not affected by the JSSE integration. |
Does not verify the hostname in the URL to the hostname in the certificate. |
weblogic.ReverseDNSAllowed |
This property continues to work and is not affected by the JSSE integration. |
If set to true then use reverse DNS lookup to figure out if |
weblogic.security.SSL.trustedCAKeyStore |
This property continues to work and is not affected by the JSSE integration. |
Loads the trusted CA certificates from that keystore. |
weblogic.security.SSL.verbose |
Use this property in combination with |
For additional SSL debugging when |
ssl.debug=true |
Use this property in combination with |
Displays SSL debug information to the console or logs. This property is for the calling WebLogic code. The JSSE-based SSL implementation has its own logging system, which is activated by the Note: You can set JSSE logging ( |
weblogic.security.SSL.disableJsseCipherSuiteAliases=true|false |
The default is |
Disables the conversion of Certicom cipher suite names to For a list of Certicom cipher suite names and their |
weblogic.security.SSL.ignoreHostnameVerify |
This property continues to work and is not affected by the JSSE integration. |
See |
weblogic.security.SSL.HostnameVerifier=classname
|
This property continues to work and is not affected by the JSSE integration. |
Specifies the class name of a custom hostname verification class. |
weblogic.security.SSL.protocolVersion=protocol
|
This property continues to work and is not affected by the JSSE integration. The supported protocol values are mapped to the corresponding protocols supported by JSSE. |
|
One of the following:
|
If this setting is enabled, these two null ciphers are added to the cipher list. |
By default, this control is not set and the use of a null cipher is not allowed on the server. In such a configuration, if the SSL clients want to use the null cipher suite (by indicating If you set this control, the null cipher suite (for example, Caution: Do not set this control in a production environment unless you are aware of the implications and consequences of doing so. |
weblogic.security.SSL.enforceConstraints=option
|
|
Ensures that the Basic Constraints extension on the CA certificate is defined as CA. See Controlling the Level of Certificate Validation. |
weblogic.security.SSL.allowedcertificatepolicyids |
Not supported. |
WebLogic Server offers limited support for Certificate Policy Extensions in X.509 certificates. See Accepting Certificate Policies in Certificates. |
weblogic.security.SSL.nojce |
Not supported. |
Footnote 1 This WebLogic system property is applicable to both the Certicom and JSSE-based SSL implementations. However, for JSSE, this property affects only the SSL calling code, not the JSSE-based implementation. For more information about the javax.net.debug
system property and debugging the JSSE-based SSL implementation, see "Debugging Utilities" in the Java Secure Socket Extension (JSSE) Reference Guide at http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug
.
Because WebLogic Server is configured with JDK 7, you may find that the out-of-the-box SSL performance slower than in previous WebLogic Server releases. This performance change is due to the stronger cipher and MAC algorithm used by default when JDK 7 is used with the JSSE-based SSL provider in WebLogic Server. Specifically, AES is used for encryption, and SHA1 is used for hashes. (This cipher combination is typically designated as AES + SHA1 here; that is, cipher + MAC algorithm.)
Previous versions of WebLogic Server used the RC4 and MD5 cipher combination (RC4 + MD5) for SSL connections. In terms of performance, AES + SHA1 is slower than RC4 + MD5. Although AES + SHA1 is recommended, you can configure WebLogic Server to restrict the stronger ciphers and cause RC4 + MD5 to be used instead for SSL. Although RC4 + MD5 is less secure than AES + SHA1, it may be acceptable depending on the security requirements of a particular WebLogic Server environment.
Note:
Oracle strongly recommends the stronger security provided by AES + SHA1 for SSL connections.To configure WebLogic Server to use RC4 + MD5, add the following property to the file JAVA_HOME
/jre/lib/security/java.security
:
jdk.tls.disabledAlgorithms=AES, DESede, DES, SHA1, SHA
The preceding property disables the stronger ciphers that are used by default for SSL connections and allows RC4 + MD5 to be used instead. For more information about cipher combination priorities in JDK 7, see http://bugs.java.com/view_bug.do?bug_id=6996365
.
This topic includes the following sections:
When using Java SE 7, the set of cipher suites supported by the JDK default JSSE provider, SunJSSE
, is available at the following URL:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
When using Java SE 8, the set of cipher suites supported by the JDK default JSSE provider, SunJSSE
, is available at the following URL:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
For backward compatibility, the JSSE-based SSL implementation accepts Certicom cipher suite names for cipher suites that are compatible with SunJSSE
. The Certicom cipher suite names are converted for you to SunJSSE
equivalents, usually replacing the "TLS_" prefix with "SSL_", as shown in Table 39-2.
Please keep the following in mind as you consider backward compatibility with Certicom cipher suites:
With JSSE, the cipher suites selected by default are stronger as compared to Certicom SSL and have slower performance. The security policies in your environment typically set the requirements for the cipher suites that must be used. However, for highly secure environments, using the strongest available cipher that provides acceptable performance is recommended.
For operations where enabled or supported cipher suites are returned, both the Certicom and SunJSSE
names of the cipher suites are returned. (Note that the weblogic.security.SSL.disableJsseCipherSuiteAliases=true
property, described in Table 39-1, disables this behavior.)
For operations where you specify enabled cipher suites, you can use either the equivalent Certicom cipher suite names, or the SunJSSE
names. The Certicom cipher suites, and their SunJSSE
equivalents, are listed in Table 39-2. (Oracle does not encourage future use of Certicom cipher suite names.)
The _DSS_
cipher suites requires certificates signed with DSS, the Digital Signature Standard defined by NIST FIPS Pub 186. DSA is the key generation scheme as described in FIPS 186.
The _anon_
cipher suites are disabled by default, and cannot be managed from the WebLogic Server Administration Console. You must use WLST instead, as described in Setting Cipher Suites Using WLST: An Example.
To use the Kerberos cipher suites TLS_KRB5_***
, you must have KDC accounts set up. See the Java Secure Socket Extension (JSSE) Reference Guide (http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#KRB
) for more details on the Kerberos requirements.
The following anonymous ciphers are not supported out-of-the-box in the JSSE-based WebLogic SSL implementation in WebLogic Server:
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
However, if you want to enable any of the preceding anonymous ciphers, include the following argument in the Java command that starts WebLogic Server:
-Dweblogic.security.SSL.AllowAnonymousCipher=true
In most cases, enabling anonymous ciphers is required when WebLogic Server, or its deployed application, acts as a SSL client that is making an outbound connection to an SSL server (for example, an LDAP server or RDBMS system) that is configured to use anonymous ciphers only. A typical use case is connecting to an Oracle Internet Directory instance that is configured in no-auth mode.
Note:
Oracle does not recommend the use of anonymous ciphers in production environments.By default, Certicom cipher suite names are converted to SunJSSE
cipher suite names when WebLogic Server is configured to use the JSSE-based SSL implementation. Table 39-2 lists each cipher suite supported in the (removed) WebLogic Server Certicom SSL implementation and its SunJSSE
equivalent. The TLS_
name is the Certicom cipher suite name; the SSL_
name is the equivalent SunJSSE
provider cipher suite name.
Table 39-2 Cipher Suite Name Equivalence
Certicom Cipher Suite | SunJSSE Equivalent Cipher Suite |
---|---|
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA |
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA |
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
TLS_DHE_DSS_WITH_DES_CBC_SHA |
SSL_DHE_DSS_WITH_DES_CBC_SHA |
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA |
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA |
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA |
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA |
TLS_DHE_RSA_WITH_DES_CBC_SHA |
SSL_DHE_RSA_WITH_DES_CBC_SHA |
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA |
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA |
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 |
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 |
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA |
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA |
TLS_DH_anon_WITH_DES_CBC_SHA |
SSL_DH_anon_WITH_DES_CBC_SHA |
TLS_DH_anon_WITH_RC4_128_MD5 |
SSL_DH_anon_WITH_RC4_128_MD5 |
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA |
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA |
TLS_RSA_EXPORT_WITH_RC4_40_MD5 |
SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
TLS_RSA_WITH_3DES_EDE_CBC_SHA |
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
TLS_RSA_WITH_DES_CBC_SHA |
SSL_RSA_WITH_DES_CBC_SHA |
TLS_RSA_WITH_RC4_128_MD5 |
SSL_RSA_WITH_RC4_128_MD5 |
TLS_RSA_WITH_RC4_128_SHA |
SSL_RSA_WITH_RC4_128_SHA |
Note:
Do not configure the DHE cipher suites as they are not safe.The following example shows using a WLST script that sets the cipher suites SSL_RSA_WITH_RC4_128_MD5
, SSL_RSA_WITH_RC4_128_SHA
, and SSL_RSA_WITH_3DES_EDE_CBC_SHA
. After this script is run, the cipher suites are set in the domain configuration (that is, the config.xml
file) and the SSL listeners are restarted with the new cipher suite settings.
url="t3://localhost:7001" adminUsername="weblogic" adminPassword="password" connect(adminUsername, adminPassword, url) edit() server=cmo.lookupServer('myserver') cd('Servers') cd('myserver') startEdit() cd('SSL') cd('myserver') ssl = server.getSSL() ciphers = ['SSL_RSA_WITH_RC4_128_MD5', 'SSL_RSA_WITH_RC4_128_SHA', 'SSL_RSA_WITH_3DES_EDE_CBC_SHA'] ssl.setCiphersuites(ciphers) save() activate() disconnect() exit()
As described in Chapter 34, "SSL Debugging", SSL debugging provides more detailed information about the SSL events that occurred during an SSL handshake and other operations.
If you debug SSL when the JSSE-based SSL implementation is enabled, you can use the logging properties listed and described in Table 39-1. However, some properties affect only the SSL calling code and not the JSSE implementation. The JSSE-based SSL implementation has its own logging system, which is activated by the javax.net.debug
property. The javax.net.debug
property provides multiple levels of control over the amount of output and can be used independently of WebLogic SSL logging (ssl.debug
).
See the "Debugging Utilities" section of the Java Secure Socket Extension (JSSE) Reference Guide, available at the following URL, for more details about the javax.net.debug
property:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug
Note:
This section describes using the RSA JSSE provider in non-FIPS mode. You can also use the RSA JSSE provider in FIPS mode as described in Chapter 37, "Enabling FIPS Mode".RSA JSSE is a third-party JSSE provider that can be statically registered in the JVM if you wish to use it. To install and configure the RSA JSSE provider, complete the following steps:
Using the following URL, download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files that correspond to the version of your JDK. These Java policy JAR files affect cipher key sizes greater than 128 bits.
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Open the .ZIP distribution and update local_policy.jar
and US_export_policy.jar
in JAVA_HOME/jre/lib/
security. See the README.txt
file in the .ZIP distribution for more information and installation instructions.
Using a text editor, modify the file JAVA_HOME
/jre/lib/security/java.security
by making the RSA JSSE provider, com.rsa.jsse.JsseProvider
, as the first provider in the list.
For example, before making this update, the list of providers might appear as follows:
# # List of providers and their preference orders (see above): # 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 security.provider.9=sun.security.mscapi.SunMSCAPI
After you add the RSA JSSE provider, the list might appear as follows:
# # List of providers and their preference orders (see above): # security.provider.1=com.rsa.jsse.JsseProvider security.provider.2=sun.security.provider.Sun security.provider.3=sun.security.rsa.SunRsaSign security.provider.4=com.sun.net.ssl.internal.ssl.Provider security.provider.5=com.sun.crypto.provider.SunJCE security.provider.6=sun.security.jgss.SunProvider security.provider.7=com.sun.security.sasl.Provider security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.9=sun.security.smartcardio.SunPCSC security.provider.10=sun.security.mscapi.SunMSCAPI
That is, you need to update the sequence number of each subsequent provider. For example, security.provider.
1
=sun.security.provider.Sun
is changed to security.provider.
2
=sun.security.provider.Sun
(change shown in bold).
Add the SSL-J jar WL_HOME
/server/lib/sslj.jar
at the head of the classpath. You can use the PRE_CLASSPATH environment variable to do this.
For example, you could set sslj.jar
in the PRE_CLASSPATH
variable before you call the server start script, typically startWebLogic.cmd/sh
:
set PRE_CLASSPATH=%MW_HOME%\wlserver\server\lib\sslj.jar
Restart WebLogic Server for the change to the RSA JSEE provider to take effect.