28 Overview of Configuring SSL in WebLogic Server
SSL: An Introduction
SSL provides secure connections by allowing two applications connecting over a network to authenticate each other's identity and by encrypting the data exchanged between the applications.
Authentication allows a server and optionally a client to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.
SSL in WebLogic Server is an implementation of the SSL and Transport Layer Security (TLS) specifications.
Note:
See Table 2-1 for the supported TLS and SSL versions.
WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL connection over HTTP, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs protocol in the connection URL, for example, https://myserver:7002.
Using SSL is compute intensive and adds overhead to a connection. Avoid using SSL in development environments when it is not necessary. However, always use SSL in a production environment.
This section includes the following topics:
One-Way and Two-Way SSL
SSL can be configured one-way or two-way:
-
With one-way SSL, the server must present a certificate to the client, but the client is not required to present a certificate to the server. The client must authenticate the server, but the server accepts a connection from any client. One-way SSL is common on the Internet where customers want to create secure connections before they share personal data. Often, clients will also use SSL to log on in order that the server can authenticate them.
-
With two-way SSL (SSL with client authentication), the server presents a certificate to the client and the client presents a certificate to the server. WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL connection.
Java Secure Socket Extension (JSSE) SSL Implementation Supported
This release of WebLogic Server uses an SSL implementation based on Java Secure Socket Extension (JSSE). JSSE is the Java standard framework for SSL and TLS and includes both blocking-IO and non-blocking-IO APIs, and a reference implementation including several commonly-trusted CAs.
The JSSE-based SSL implementation interoperates over SSL with instances of Weblogic Server version 8.1 and later that use the Certicom SSL implementation. That is, when WebLogic Server with JSSE SSL is used as either an SSL client or as the SSL server, it can communicate via SSL with instances of WebLogic Server (version 8.1 and later) that use the Certicom SSL implementation.
See Using the JSSE-Based SSL Implementation for information about using JSSE.
See the Java Secure Socket Extension (JSSE) Reference Guide (http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html) for complete information on JSSE.
Note:
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.
Setting Up SSL: Main Steps
To set up SSL, you must first obtain an identity and trust for Weblogic Server and then store them using keystores. You can, then, configure the identity and trust keystores followed by setting SSL configuration options for the private key alias and password using the WebLogic Server Administration Console.
Perform the following steps to set up SSL:
For information about configuring identity and trust for WebLogic Server, see the following sections:
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 setEnableSessionCreation(false) 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.
You can use the weblogic.security.SSL.sessionCache.ttl command-line argument to modify the default server-session time-to-live for SSL session caching. See SSL in Command Reference for Oracle WebLogic Server. Note that the weblogic.security.SSL.sessionCache.size command-line argument is ignored.