38 Using the JSSE-Based SSL Implementation
Note:
Note the following:
-
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:
Using System Properties with the JSSE-Based SSL Implementation
Learn how the JSSE-based SSL implementation handles the WebLogic security system properties.
Table 38-1 System Properties Usage
System Property | Description |
---|---|
|
Does not verify the hostname in the URL to the hostname in the certificate. |
|
If set to |
|
Loads the trusted CA certificates from that keystore. |
|
For additional SSL debugging when 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 ( Use this property in combination with |
|
See |
|
Specifies the class name of a custom hostname verification class. |
|
|
One of the following:
|
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, The supported protocol values are mapped to the corresponding protocols supported by JSSE.
If this setting is enabled, these two null ciphers are added to the cipher list. Caution: Do not set this control in a production environment unless you are aware of the implications and consequences of doing so. |
|
Ensures that the Basic Constraints extension on the CA certificate is defined as CA. See Controlling the Level of Certificate Validation.
|
Footnote 1
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 - Java Secure Socket Extension (JSSE) Reference Guide in Security Developer’s Guide.
Cipher Suites
Learn about the cipher suites supported by WebLogic Server, using anonymous ciphers, and setting cipher suites.
To set cipher suites, use WebLogic Remote Console or WLST. See Set Cipher Suites in Oracle WebLogic Remote Console Online Help or Setting Cipher Suites Using WLST: An Example.
This topic includes the following sections:
List of Supported Cipher Suites
For a list of the set of cipher suites supported by the JDK default JSSE provider, SunJSSE
, see:
- JDK 17: The SunJSSE Provider in Security Developer’s Guide
- JDK 21: The SunJSSE Provider in Security Developer’s Guide
Deprecated Cipher Suites
Per Oracle security guidelines, the TLS cipher suites that are prefixed with TLS_RSA_
or contain _CBC_
are deprecated and are disabled by default. These disabled cipher suites are weak and do not provide sufficient security for your system. However, if necessary for your environment, you can enable these TLS cipher suites using any of the following methods:
-
Set the
ExcludedCiphersuites
attribute on theweblogic.management.configuration.SSLMBean
MBean to an array that contains just one empty string. For examplenew String[]{""}
. -
Set the
MinimumTLSProtocolVersion
attribute on theweblogic.management.configuration.SSLMBean
MBean toTLSv1.1
or earlier. -
Set the system property
-Dweblogic.security.SSL.minimumProtocolVersion
toTLSv1.1
or earlier in the Java command that starts WebLogic Server. -
Set the system property
-Dweblogic.security.SSL.protocolVersion
in the Java command that starts WebLogic Server. See Using the weblogic.security.SSL.protocolVersion System Property.
Backward Compatibility of Supported Cipher Suites
Keep the following in mind as you consider backward compatibility of supported cipher suites:
-
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. To enable them, you can use WebLogic Remote Console or WLST. See Set Cipher Suites in Oracle WebLogic Remote Console Online Help or Setting Cipher Suites Using WLST: An Example. -
The TLS DES cipher suites have been disabled at the JSSE provider level by default. See the Oracle JRE and JDK Cryptographic Roadmap at
https://java.com/en/jre-jdk-cryptoroadmap.html
.
Using Anonymous Ciphers
The following anonymous ciphers are not supported out-of-the-box in the JSSE-based WebLogic SSL implementation in WebLogic Server:
-
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
-
SSL_DH_anon_WITH_RC4_128_MD5
-
SSL_DH_anon_WITH_DES_CBC_SHA
-
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
-
SSL_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.
Setting Cipher Suites Using WLST: An Example
The following example shows 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.
Note:
For clarity, this WLST example script shows the username and password in clear text. However, you should avoid entering clear-text passwords in WLST commands in general, and you should especially avoid saving on disk WLST scripts that include clear-text passwords. In these instances you should use a mechanism for passing encrypted passwords instead. See Security for WLST in Understanding the WebLogic Scripting Tool.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()
An Important Note Regarding Null Cipher Use in SSL
SSL clients start the SSL handshake by connecting to the server. As part of the connection, the client sends the server a list of the cipher suites it supports. The server then selects a mutually-supported cipher suite from the list supplied by the client for the client and server to use for this session.
However, an incorrectly configured client might specify a set of cipher suites that contain only null ciphers. A null cipher passes data on the wire in clear-text. (An example of a cipher suite with a null cipher is SSL_RSA_WITH_NULL_MD5.) Using a null cipher makes it possible to see the SSL messages by using a network packet sniffer. In essence, SSL is used but does not provide any security.
The server selects the null cipher only when it is the only cipher suite they have in common. If the server selects a null cipher from the client's cipher suite list, the log contains the following message: SSL has established a session that uses a Null cipher.
This message is output only when the server has selected a null cipher from the client's list.
Note:
If there is any potential whatsoever that an SSL client might use a null cipher to inappropriately connect to the server, you should check the log file for this message. It is recommended that new client configurations be given extra attention with respect to the use of a null cipher to ensure that they are properly configured.
It is unlikely that an existing client configuration would suddenly start using null ciphers if it had not been doing so previously. However, an existing client configuration that is unknowingly configured incorrectly could be using null ciphers.
Other SSL errors unrelated to null ciphers are possible as well, and each will display an appropriate error message in the log.
See Configuring SSL. For information on viewing log files, see View Logs in Oracle WebLogic Remote Console Online Help.
WebLogic Server Control to Prevent Null Cipher Use
WebLogic Remote Console includes a control to prevent the server from using a null cipher.
In the Edit Tree, go to Environment, then Servers, then myServer. On the Security tab, select the SSL subtab and enable Show Advanced Fields.
The Allow Unencrypted Null Cipher control determines whether null ciphers are allowed. By default, this control is disabled and the use of a null cipher is not allowed on the server. In such a configuration, if the SSL/TLS clients want to use the null cipher suite (by indicating SSL_RSA_WITH_NULL_MD5 as the only supported cipher suite), the SSL/TLS handshake will fail.
If you enable this control, the null cipher suite (for example, SSL_RSA_WITH_NULL_MD5) is added to the list of supported cipher suites by the server. The SSL/TLS connection has a chance to use the null cipher suite if the client wants to do so. If the null cipher suite is used, the message will be unencrypted.
Caution:
Do not set this control in a production environment unless you are aware of the implications and consequences of doing so.
This control is also exposed as a system runtime parameter, weblogic.security.SSL.allowUnencryptedNullCipher
, and as an AllowUnencryptedNullCipher
attribute on the SSLMBean.
Note:
TLS anon and NULL cipher suites are disabled by default in the JDK.Using Debugging with JSSE SSL
If you debug SSL when the JSSE-based SSL implementation is enabled, you can use the logging properties listed and described in Table 38-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
).
For more information about the javax.net.debug
property, see Debugging Utilities - Java Secure Socket Extension (JSSE) Reference Guide in Security Developer’s Guide.