RSS

Configuring SSL for Oracle Weblogic (and OFMW)

16 Dec

We have a very basic domain: 3 physical servers, 1 containing the admin server, 2 containing 2 managed servers each, running in a cluster. Nice picture to follow. :)

name of the servers: server01 (Admin) / server02 (MS1+MS2) / server03 (MS3+MS4)

Step 0 – The Weblogic Demo Certificates (the reason why)

If you ever checked your Weblogic production logs and found the Security Alert below, then your Weblogic domain has a huge gaping security hole. Even if you don’t want SSL communication for your webservices or applications. The internal (administrative) processes in your Weblogic domain still relies on the default demotrust and with this everyone can access your domain.

</pre>
&nbsp;

<Alert> <Security> <SERVER02> <rbx_dev_soa_ms01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <BEA-090152> <Demo trusted CA certificate is being used in production mode: [
[
  Version: V3
  Subject: CN=CACERT, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

  Key:  Sun RSA public key, 512 bits
  modulus: 95501928778692415440753....
  public exponent: 65537
  Validity: [From: Thu Mar 21 21:12:27 CET 2002,
               To: Tue Mar 22 21:12:27 CET 2022]
  Issuer: CN=CACERT, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
  SerialNumber: [    33f10648 fcde0deb 4199921f d64537f4]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
]

]
  Algorithm: [MD5withRSA]
  Signature:
0000: 9D 26 4C 29 C8 91 C3 A7   06 C3 24 6F AE B4 F8 82  .&L)......$o....
0010: 80 4D AA CB 7C 79 46 84   81 C4 66 95 F4 1E D8 C4  .M...yF...f.....
0020: E9 B7 D9 7C E2 23 33 A4   B7 21 E0 AA 54 2B 4A FF  .....#3..!..T+J.
0030: CB 21 20 88 81 21 DB AC   90 54 D8 7D 79 63 23 3C  .! ..!...T..yc#<

] The system is vulnerable to security attacks, since it trusts certificates signed by the demo trusted CA.>

Step 1 – generate the identity java keystore

We first generate a java keystores containing a private key for each physical server, since SSL hostname verifiation is based on machine names. We use “welcome1″ as password here, but make sure to choose a complex password here, use it during these steps and then lock it safely away.


keytool.exe -genkey -keysize 2048 -keyalg RSA -alias server01 -keystore server01_identity.jks

Enter keystore password: welcome1
 Re-enter new password: welcome1
 What is your first and last name?
   [Unknown]:  server01
 What is the name of your organizational unit?
   [Unknown]:
 What is the name of your organization?
   [Unknown]:  Rubix
 What is the name of your City or Locality?
   [Unknown]:
 What is the name of your State or Province?
   [Unknown]:
 What is the two-letter country code for this unit?
   [Unknown]:  NL
 Is CN=server01, OU=, O=Rubix, L=, ST=, C=NL correct?
   [no]:  yes
<br>

Step 2 – generate signing request

keytool.exe -certreq -alias server01 -file server01.csr -keystore server01_identity.jks</div>
Repeat step 1 + 2 for each physical server, replacing the -alias parameter, -keystore parameter and CN name with the correct server0* value.
 

 

Step 3 – the Certificate Authority (CA)

Now comes the tricky part that you probably need some outside forces. You will need the correct Certificate Authority to sign your certificate requests (the .CSR files you generated). You can create your own CA and self-sign them, but I would not recommend that unless you know what you are doing and understand the consequences. You could use an external Internet CA provider, but this becomes very costly and time consuming when you need such an external provider to sign every SSL enabled server in your landscape. The best situation for us would be if the current organization already has an internal CA provider, especially when the rootCA is trusted by the servers and machines in your landscape.
 
Let’s assume however that you receive the signed response, including the public keys of the rootCA and a intermediateCA. CA instances often use a intermediate CA to authorize certificates, so if they have “problems” they can withdraw this intermediate CA and don’t need to withdraw the whole RootCA making it useless.
So the situation should be that you know hold 3 PEM/DER files.
 

 

Step 4 – importing the CA response

Import the certificates in your keystore, starting with the rootCA, then the intermediateCA, then the specific server alias. Example for server01:
keytool -importcert -trustcacerts -alias rootca -file rootCA.cer -keystore server01_identity.jks

keytool -importcert -alias intermediateca -file intermediateCA.cer -keystore server01_identity.jks

keytool -importcert -alias server01 -file server01.cer -keystore server01_identity.jks
Repeat these steps for server02 and server03. So we know have 3 identity keystores for each server containing the signed private key and it’s certificate chain.
 

 

Step 5 – generate the trust java keystore

Now let’s generate a truststore for each server. Altough you can use the identical keystore for both identity and trust, it’s always a good practice to separate them. The identity keystone contains the private key and normally never changes during it’s lifetime, so you should secure it with a complex password. The trust store contains the certificates that you trust and as your middleware landscape grows, this file might grow and more administrators will need access to it.
 
Example generating the truststore for server01, repeat for 02 & 03.
 
keytool -importcert -trustcacerts -alias rootca -file rootCA.cer -keystore server01_trust.jks
keytool -importcert -alias intermediateca -file intermediateCA.cer -keystore server01_trust.jks
 

Step 6 – copy the java keystore files to each server

 Make sure that each server had the files stored on disk. We use the windows server example “c:\oracle\security” in this blogpost. So server01 should hold:
- c:\oracle\security\server01_identity.jks
- c:\oracle\security\server01_trust.jks
 

 

Step 7 – configure the Node Manager for SSL

The nodemanger by default uses the demoIdentity and demoTrust keystores.
So on each server hosting a managed server (server02 and server03) we will need to change this.
Open the nodemanager.properties and add the following lines:
 
### SSL config
KeyStores=CustomIdentityAndCustomTrust
# CustomIdentityKeyStoreType=JKS
CustomIdentityKeyStoreFileName=c://oracle//security//server01_identity.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=server01
CustomIdentityPrivateKeyPassPhrase=welcome1
# CustomTrustKeyStoreType=JKS
CustomTrustKeyStoreFileName=c://oracle//security//server01_trust.jks
Restart the NodeManager to activate the changes. The passwords in the properties file will automatically become encrypted.
 
Possible error:
For server rbx_dev_soa_ms03, the Node Manager associated with machine server03 is not reachable. All of the servers selected are currently in a state which is incompatible with this operation or are not associated with a running Node Manager or you are not authorized to perform the action requested. No action will be performed.
Possible solution:
Your AdminServer can not communicate with a node manager. Make sure it’s running, check Environment -> Machines in the Weblogic console if the machine has state reachable, check if the address configured there, and the address in the nodemanager.properties and the CN-name used in SSL have the same value, check if Weblogic and Nodemanager use the same SSL configuration (trust+identity).
 

 

Step 8 – configure Weblogic for SSL

Log in the Weblogic console, in our example: http://server01:7001/console
 
 
Step 8.1 – configure Weblogic for SSL, enable SSL
 
Log in the Weblogic console (in our case http://server01:7001/console) and make sure that each server has the SSL port enabled. You can find the setting “SSL Listen Port Enabled” for each server under “Configuration -> General”. Enable it and make sure you use a correct and free port.
 

Step 8.2 – configure Weblogic for SSL, changing keystores

For each server (Admin + MS) we have to change the KeyStore configuration.
So for each server go to: Configuration -> Keystores
 
  • Keystores -> “Change” = “Custom Identity and Custom Trust”
  • Custom Identity Keystore = c:/Oracle/security/serverXX_identity.jks
  • Custom Identity Keystore Type = JKS
  • Custom Identity Keystore Passphrase = welcome1
  • Custom Trust keystore = c:/Oracle/security/serverXX_trust.jks
  • Custom Trust Keystore Type = JKS
  • Custom Trust Keystore Passphrase = welcome1
 
 

Step 8.3 – configure Weblogic for SSL, changing identity:

For each server (Admin + MS) we have to change the SSL configuration.
So for each server go to: Configuration -> SSL
 
  • Private Key Alias = serverXX
  • Private Key Passphrase = welcome1
 

Step 9 – Weblogic start scripts:

By default Weblogic uses the DemoTrust.jks truststore. Since we changed this in the console configuration you would hope this would be enough. However the SetDomainEnv.sh / SetDomainEnv.cmd script still contains a reference. So for each server:
 
  • Go to %domain_home%/bin/
  • Open the SetDomainEnv script
  • Search the argument: -Djavax.net.ssl.trustStore=
  • Make sure the value is not referring to the demo trust.jks but “c:/oracle/security/serverXX_trust.jks
When you are finished restart your whole Weblogic environment (Admin + MS).
 

Step 10 – Configure Enterprise Manager:

This took me some research and the Oracle Forums to get it working. Navigate to the enterprise manager console (/em)
 

Step 10.1 – Security Provider Configuration:

I’m actually not really sure if this step is still necessary in 11g, but hey .. why not be sure:
 
  • Click Weblogic -> right-click domain
  • Select Security -> Security Provider Configuration -> KeyStore Configure
  • Keystore Path = c:/oracle/security/server01_identity.jks
 

Step 10.2 – SOA Infra properties

 
  • Click SOA -> right-click soa-infra
  • Select SOA Administration -> Common Properties
  • Click More SOA Infra Advanced Properties
  • Keystore Location = c:/oracle/security/serverXX_identity.jks

Step 10.3 – Credential Mapping:
The next step is to configure the credential mapping keys

  • Click Weblogic -> right-click domain name
  • Select Security -> Credentials
  • Create a Map named “SOA”
  • Click Create a key
  • Key = KeyPassword
  • User Name = KeyPassword
  • Password = welcome1
  • Click Create Key:
  • Key = KeyStorePassword
  • User Name = KeyStorePassword
  • Password = welcome1
 
Possible error:
</div>
<div>

<Warning> <oracle.as.jmx.framework.MessageLocalizationHelper> <J2EE JMX-46041> <The resource for bundle "oracle.soa.management.config.bpel.mbeans.MessageBundle_en" with key "oracle.soa.BPELConfigBean.auditFlushByteThreshold" cannot be found.>
INFO: SSLSocketFactoryManagerImpl.getKeystoreLocation SOA Keystore location: c:/oracle/security/server04_identity.jks
INFO: SSLSocketFactoryManagerImpl.getKeystorePassword Obtained null or empty keystore password
INFO: SSLSocketFactoryManagerImpl.getKeyPassword Obtained null or empty key password
INFO: SSLSocketFactoryManagerImpl.getSSLSocketFactory Could not obtain keystore location or password

</div>
<div>
 
Possible solution:
You did not configure the SOA key mapping correctly as mentioned above in 9.3

 

Conclusion:

Enabling SSL takes a lot of steps, and we didn’t even mentioned it for enabling SSL client identity in OSB (Service Key Provider) and communication with an LDAP over SSL. But there’s more to come I guess.
If you have any remarks please let me know in the comments. Hope it helps. :)
 
 

Links:

About these ads
 
11 Comments

Posted by on 16-12-2011 in Security, SOA Suite, Weblogic

 

Tags: ,

11 responses to “Configuring SSL for Oracle Weblogic (and OFMW)

  1. Jacco H. Landlust

    04-01-2012 at 10:45

    About Step 10.1:

    Please be carefull when you have followed the EDG and separated adminserver from managed servers on different machines. This keystore is not copied from the adminserver to the managed server by weblogic, you have to do this manually.

    Other products might have installed keys in this default-keystore.jks (located at $DOMAIN_HOME/config/fmconfig) e.g. IDM installs a key with alias xell. If you change the keystore you have to move these keys too. Since these are private keys, which cannot be exported with keytool. I recommend using pkeytool for this ( http://pkeytool.couchpotato.net). I would advise to always check the default key for existing keys before changing the value in /em.

    About Step 10.2
    SOA seems to be using a wallet for it’s keys instead of a JKS (haven’t really dug into it yet). This might just explain why you are getting the error at step 10.3

     
    • jvzoggel

      08-01-2012 at 16:40

      Hi Jacco, thanks for the input. Another thing I find weird from the EM configuration is the fact that it doesn’t allow you to configure different keystores for each instance. Weblogic allows unique SSL configuration for each Managed Server in the domain. So no problem there if these are running on different machines with different hostnames.

      I believe step 10.1 is not necessary anymore, and everything is handled in WLS now-a-days.
      The error in 10.3 is what I got when I didn’t configure the mapping (which holds no keystore filenames, just passwords).
      The steps in 10.2 do contain a specific filename where I used the hostname as part of it.

      This I guess would mean that if you have a cluster of multiple MS servers hosting your SOASuite you will eventually need to make sure the keystores all have an identical filename (step 10.2) and identical password (step 10.3).

       
    • jvzoggel

      08-01-2012 at 16:43

      I’m still stuck to get SSL communication to work between Weblogic and OID (configured in the the OIDAuthenticator). Got it working with Active Directory however OID is puzzling me. I succeeded changing the Wallet configuration of OID allowing it to use the new private identity and correct thrusts. However when I change the WLS configuration to SSL I can see in my Weblogic logging that it expects an SSL handshake from OID but remains getting clear-text communication. The whole configuration still works, but I’m not able to “force” OID to actually use SSL.

       
  2. deandrephelps@arcor.de

    23-12-2012 at 04:00

    Hi, just wanted to say, I liked this post. It was helpful.
    Keep on posting!

     
  3. Kris

    24-01-2013 at 21:13

    Thank you for the post. really helped to gain knowledge on SSL from novice to expert. Please do post on enabling SSL client identity in OSB (Service Key Provider). Thank you.

     
  4. Mario MAdera

    25-01-2013 at 16:27

    HI,

    I’m starting to walk a similar path. The difference is that we have configure the Administration Server listening in a DNS name that points to a virtual migratable IP address. In this way, we can startup the AdminServer in any of the hosts that are used by prodcution cluster.

    Our cluster is composed by 4 different host, each of them running 3 managed servers, and the admin server in one of them.

    Alse, the cluster is behind a hardware loadbalancer and the users use a unique URL.

    Is there any consideration when using this schema?

    Regards,
    Mario

     
  5. Shak

    28-01-2013 at 16:33

    Hello, I didn’t create any private key using keytool but I received PFX from our company Admin. I converted PFX to PEM and I see private kay and server certificate but not root and intermediate.

    What could be the correct process in this case. I tried the following steps1
    1) converted pfx to PEM
    2) converted PEM to PKCS12 using openSSL
    3) converted PKCS12 to keystore. Key store has only 1 entry (not sure why it is not showing the certificate and no intermediate and chain)
    4) Configured the keystore using custom identity and standard trust option.
    5) Accessed the website and no broken certs found in any browser
    6) But when checked the URL using http://www.sslshopper.com/ssl-checker.html, the cheker says that certificate chain has broken. Even our clients who consume the services also complain the same.

    Any inputs will be highly appreciated.

     
  6. BA

    17-02-2013 at 18:06

    Thanks for your marvelous posting! I actually enjoyed reading it, you could be a great
    author. I will always bookmark your blog and may come back someday.

    I want to encourage one to continue your great job, have a
    nice holiday weekend!

     
  7. presto pressure cooker

    22-03-2013 at 03:33

    Hi there, I desire to subscribe for this weblog to take most up-to-date updates, so where can i do it please
    help.

     
  8. Pierluigi Vernetto (@publicpierre)

    30-07-2013 at 17:11

    Hi Jan, very informative as usual. Is there a way to automate the configuration of EM? I don’t want to click around, I am just lazy.

     
  9. Cecilia

    07-01-2014 at 00:54

    I coulԁn’t refrain from commenting. Very well written!

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 335 other followers

%d bloggers like this: