12-4 Securing Oracle WebLogic Server
■
Section 11.4.2, Storing Private Keys, Digital Certificates, and Trusted Certificate Authority Certificates
12.5 Using Host Name Verification
A host name verifier ensures the host name in the URL to which the client connects matches the host name in the digital certificate that the server sends back as part of the
SSL connection. A host name verifier is useful when an SSL client or a WebLogic Server acting as an SSL client connects to an application server on a remote host. It
helps to prevent man-in-the-middle attacks.
By default, WebLogic Server has host name verification enabled. As a function of the SSL handshake, WebLogic Server compares the common name in the SubjectDN in the
SSL servers digital certificate with the host name of the SSL server used to accept the SSL connection. If these names do not match, the SSL connection is dropped. The SSL
client is the actual party that drops the SSL connection if the names do not match.
If anything other than the default behavior is desired, either turn off host name verification or configure a custom host name verifier. Turning off host name
verification leaves WebLogic Server vulnerable to man-in-the-middle attacks. Oracle recommends leaving host name verification on in production environments.
If you are using the default WebLogic Server host name verifier, host name verification passes if both of the following conditions exist:
■
The host name in the certificate matches the local machine’s host name.
■
The URL specifies localhost, 127.0.01, or the default IP address of the local machine.
For more information about using host name verification, see the following topics in the Oracle WebLogic Server Administration Console Help:
■
Verify host name verification is enabled
■
Disable host name verification
■
Configure a custom host name verifier
■
Servers: Configuration: SSL
12.6 SSL Debugging
SSL debugging provides more detailed information about the SSL events that occurred during an SSL handshake. The SSL debug trace displays information about:
■
Trusted certificate authorities
■
SSL server configuration information
■
Server identity private key and digital certificate
■
The encryption strength that is allowed
Note: If you are using the demo identity certificates in a multi-server
domain, Managed Server instances will fail to boot if they are started using the fully-qualified DNS name of the Administration Server. For
information about this limitation and suggested workarounds, see Section 11.4.1.2.2, Limitation on CertGen Usage.
Configuring SSL 12-5
■
Enabled ciphers
■
SSL records that were passed during the SSL handshake
■
SSL failures detected by WebLogic Server for example, trust and validity checks and the default host name verifier
■
IO related information SSL debugging dumps a stack trace whenever an ALERT is created in the SSL process.
The types and severity of the ALERTS are defined by the Transport Layer Security TLS specification.
The stack trace dumps information into the log file where the ALERT originated. Therefore, when tracking an SSL problem, you may need to enable debugging on both
sides of the SSL connection on both the SSL client or the SSL server. The log file contains detailed information about where the failure occurred. To determine where
the ALERT occurred, confirm whether there is a trace message after the ALERT. An ALERT received after the trace message indicates the failure occurred on the peer. To
determine the problem, you need to enable SSL debugging on the peer in the SSL connection.
When tracking an SSL problem, review the information in the log file to ensure:
■
The correct config.xml file was loaded
■
The setting for domestic, or export, is correct
■
The trusted certificate authority was valid and correct for this server.
■
The host name check was successful
■
The certificate validation was successful
12.6.1 Command-Line Properties for Enabling SSL Debugging
Use the following command-line properties to enable SSL debugging: -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
You can include SSL debugging properties in the start script of the SSL server, the SSL client, and the Node Manager. For a Managed Server started by the Node Manager,
specify this command-line argument on the Remote Start page for the Managed Server.
12.6.2 SSL Debugging When Using JSSE
If WebLogic Server is configured to use the JSSE-based SSL implementation see Section 12.12, Using the JSSE-Based SSL Implementation
, additional detailed debug logging may be enabled using the following command-line property:
-Djavax.net.debug=all Note the following:
■
The -Dssl.debug=true and -Dweblogic.StdoutDebugEnabled=true command-line properties still apply for JSSE. They enable debug logging of the
SSL calling code within Weblogic Server.
Note: Sev 1 type 0 is a normal close ALERT, not a problem.
12-6 Securing Oracle WebLogic Server
■
The -Djavax.net.debug=all property enables debug logging within the JSSE-based SSL implementation.
For information about using WebLogic logging properties with the JSSE SSL logging system, see
Section 12.12.4, Using Debugging with JSSE SSL. For information about debugging utilities available for JSSE, see Debugging Utilities
in the Java™ Secure Socket Extension JSSE Reference Guide, available at the following URL:
http:download.oracle.comjavase6docstechnotesguidessecuri tyjsseJSSERefGuide.htmlDebug
12.7 SSL Session Behavior
WebLogic Server allows SSL sessions to be cached. Those sessions live for the life of the server.
Clients that use SSL sockets directly can control the SSL session cache behavior. The SSL session cache is specific to each SSL context. All SSL sockets created by SSL socket
factory instances returned by a particular SSL context can share the SSL sessions.
Clients default to resuming sessions at the same IP address and port. Multiple SSL sockets that use the same host and port share SSL sessions by default, assuming the
SSL sockets are using the same underlying SSL context.
Clients that are not configured to use SSL sessions must call setEnableSessionCreationfalse on the SSL socket to ensure that no SSL
sessions are cached. This setting only controls whether an SSL session is added to the cache; it does not stop an SSL socket from finding an SSL session that was already
cached. For example, SSL socket 1 caches the session, SSL socket 2 sets setEnableSessionCreation to false but it can still reuse the SSL session from SSL
socket 1 because that session was put in the cache.
SSL sessions exist for the lifetime of the SSL context; they are not controlled by the lifetime of the SSL socket. Therefore, creating a new SSL socket and connecting to the
same host and port used by a previous session can resume a previous session as long as you create the SSL socket using an SSL socket factory from the SSL context that has
the SSL session in its cache.
By default, clients that use HTTPS URLs get a new SSL session for each URL because each URL uses a different SSL context and therefore SSL sessions can not be shared or
reused. You can retrieve the SSL session by using the weblogic.net.http.HttpsClient class or the
weblogic.net.http.HttpsURLConnection class. Clients can also resume URLs by sharing a SSLSocket Factory between them.
Session caching is maintained by the SSL context, which can be shared by threads. A single thread has access to the entire session cache, not just one SSL session, so
multiple SSL sessions can be used and shared in a single or multiple thread.
The following command-line arguments are ignored:
■
weblogic.security.SSL.sessionCache.size
■
weblogic.security.SSL.sessionCache.ttl
Configuring SSL 12-7
12.8 Configuring RMI over IIOP with SSL
