Configuring SSL for WebLogic using Self-Signed Certificates and TLS

In this article I am going to show you how to secure WebLogic using Secure-Sockets-Layer, or SSL.  In order to do this we must configure “Identity” and “Trust” for WebLogic using certificates and keystores. Identity tells us who the server is and Trust tells us who can be trusted. This is very important when establishing an SSL connection between clients and servers.

In the case of 1-way SSL when a client initiates a request to a server over SSL, the SSL handshake process begins with the server presenting the client its public certificate or identity. The client must trust the server by validating the server’s certificate against its own trust store.

When dealing with configuring SSL for WebLogic servers in a multi-host environment, I tend to create certificates for each host, not for each WebLogic server. A host-specific certificate is easier to manage then a WebLogic server-specific certificate. Cert management is a pain, so make life easy(ier) and stick to create host-specific certs.

These host-specific certs will be used to identify both running Node Manager instances and WebLogic server instances.

SSL3 / POODLE Vulnerability

As you may or may not know, SSL3 suffers from the POODLE vulnerability. By default, WebLogic 11g and 12c both enable SSL3. So whether or not you have SSL configured already, this post will show you how to disable SSL3 by only enabling TLS.  SSL3 should NOT be used in production environments or any environment that is exposed outside of your internal network.

To find out more about the SSL3/POODLE vulnerability,  check out this post on Stack Exchange.

Certificates and Keystores

In order to configure SSL for WebLogic we must create certificates for each of our application hosts.  We can either have certificates issued by a Certificate Authority or we can generate self-signed certificates. There are certainly pros and cons to both.

The benefits of issued certificates from a trusted CA is that the certificate will (ideally) be trusted on the open internet. Self-signed certificates though are not issued by a trusted CA and as such will not be trusted on the open internet. However, it costs quite a bit of money to have a trusted CA issue certificates. If your environment will be accessible on the internet then you probably want certificates issued by a CA.

If your environment is inside a firewall or DMZ, then self-signed certificates or an internal CA is appropriate.

In this post I will show you how to generate self-signed certificates for use with Oracle WebLogic.

Step 1: Generate Host Identity Keys and Identity Keystore

I am going to show you how to use keytool to generate strong certificates and create JCEKS keystores for your application host.

The following command will create both a host certificate and keystore using keytool. The certificate or key will be signed with SHA256 with an expiration date of 3 years. I use hostname -f where possible to ease key and keystore generation. This is useful if you’re going to script this process to use across multiple servers.

The keystore is a JCEKS type keystore. This is a JCE-type keystore.

Step 2: Export Root Identity Certificate

Next we must export the identity certificate from the generated identity keystore. This identity certificate will then be imported into the trust keystore.

Step 3: Import Identity Certificate into Trust Keystore

Next we need to create a JCEKS trust keystore. The trust keystore contains either cert chains or certificates that are used to establish trust during an SSL handshake.

Once the certificates and keystores are created, store them in a safe location – a directory with restricted access. You want the WebLogic process owner to have read-only access to the certs and keystores.

Step 4: Configuring WebLogic Keystores

Now that we have created certificates and keystores for identity and trust, we must configure WebLogic to use them. The following steps are for the Admin Server, but are applicable to both admin and managed servers.

1. Start the admin server
2. Log into the admin console
3. Navigate to Environment > Servers > Admin Server
   
4. Click on the Keystores tab
5. Click on the Keystores button and select “Custom Identity and Custom Trust“
6. Specify the fully qualified path to the identity keystore under Custom Identity Keystore
7. Specify JCEKS under Custom Identity Keystore Type
8. Specify the passphrase for the identity keystore under Custom Identity Keystore Passphrase
9. Configure the Custom Trust Keystore, Custom Trust Keystore Type, and Passphrase as you did with the Identity keystore
10. Save the changes

Here’s a screenshot of my environment:

 

Step 4: Configure WebLogic SSL

Now that we have configured the identity and trust keystores, we can go ahead and configure SSL for WebLogic.

1. Click on the SSL tab
2. Specify the Private Key Alias. Use the alias that was defined when you created the private key and identity keystore
3. Specify the Private Key Passphrase
4. Click Save

Here’s a screenshot of my SSL configuration:

Step 5: Test SSL Configuration

We can test the SSL configuration by enabling the SSL listen port for the WebLogic server.

1. In the admin console, go to the server configuration tab under Environment > Servers > Admin Server
2. Enable the SSL Listen Port Enabled checkbox
3. Note the SSL Listen Port
4. Save the changes

To verify that the changes were successful, take a look at the admin server’s server log. You should see the admin server listening securely if everything worked well.

<Jun 9, 2015 7:42:20 AM MDT> <Notice> <Server> <BEA-002613> <Channel “DefaultSecure” is now listening on 192.168.1.165:7002 for protocols iiops, t3s, CLUSTER-BROADCAST-SECURE, ldaps, https.>
<Jun 9, 2015 7:42:20 AM MDT> <Notice> <Server> <BEA-002613> <Channel “DefaultSecure[1]” is now listening on fe80:0:0:0:224:81ff:feed:a092:7002 for protocols iiops, t3s, CLUSTER-BROADCAST-SECURE, ldaps, https.>
<Jun 9, 2015 7:42:21 AM MDT> <Notice> <Server> <BEA-002613> <Channel “DefaultSecure[2]” is now listening on 0:0:0:0:0:0:0:1:7002 for protocols iiops, t3s, CLUSTER-BROADCAST-SECURE, ldaps, https.>
<Jun 9, 2015 7:42:21 AM MDT> <Notice> <Server> <BEA-002613> <Channel “DefaultSecure[3]” is now listening on 127.0.0.1:7002 for protocols iiops, t3s, CLUSTER-BROADCAST-SECURE, ldaps, https.>