This chapter includes the following sections:
Secure Sockets Layer (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.
See Table 3-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,
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:
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.
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.
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.
To set up SSL:
If you use the CertGen utility to generate certificates, see Limitation on CertGen Usage for information about limitations on its use. Certificates generated by CertGen are for demo purposes only and should not be used in a production environment.
This release of WebLogic Server supports private keys and trusted CA certificates stored in files, or in the WebLogic Keystore provider for the purpose of backward compatibility only.
FIPS mode is supported for JSSE via the RSA JSSE provider, as described in Enabling FIPS Mode.
For information about configuring identity and trust for WebLogic Server, see the following sections:
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. For information, see "SSL" in Command Reference for Oracle WebLogic Server. Note that the
weblogic.security.SSL.sessionCache.size command-line argument is ignored.