Two Way SSL implementation in Oracle SOA Suite Using TLS

Hello Everyone,

Hope you all are doing well, Today i will be going to discuss how we can configure SOA server to implement two way SSL by which request/response encryption and secure/trusted connection can be done.

You will see lots of blog over it, Here i am not going to discuss in theory about it as who ever is going to start work with two way SSL implementation, Must read below oracle documentation and make clear about terms and their specifications.

https://docs.oracle.com/middleware/12213/soasuite/administer/GUID-5E4E3425-F0E3-4E97-B5AE-2EEE7A205ACF.htm

Here we will focus how we can make a SOA composite two way SSL enabled, You need to follow same type of implementation when you are in process of consuming any third party SOAP service in SOA composites.


Let's Start, Before actual implementation let's have a show review of terms will be used in this implementation.

SSL/TLS: S SL stands for Secure Sockets Layer. SSL is the predecessor of TLS. SSL should be considered insecure since in October 2014 the POODLE attack was announced. TLS currently has 4 versions. TLS 1.0, 1.1, 1.2 and 1.3. 1.3 is not widely supported/adopted yet. SSL/TLS provide integrity checks, security and authentication.

Identity:

A server which hosts traffic on a port which has SSL/TLS enabled, has an identity keystore. This identity keystore contains a private key and a public key/certificate. The public key/certificate can safely be given to other parties. With websites when visiting an HTTPS website (HTTP with SSL enabled), the public key is send to you. The other party / client can use the public key to encrypt messages meant for the server. The only one who can decrypt the messages is the one having the private key of the server. This is usually only the server.

Trust:

Can you trust a server? You can use a certificate authority to create a signed public key. If someone trust the certificate authority, that someone also automatically trusts the signed key. With websites you often see a green lock when a certain website uses HTTPS with a public certificate signed by a (by your webbrowser) trusted certificate authority.

Usually a truststore is used to store trusted certificate authorities or specific trusted certificates. If you have many servers in your application landscape, it is recommended to use a certificate authority since it is cumbersome to load every public key of every server in every truststore. Trusting a single certificate authority makes things a lot easier.

Certificate authority:

A certificate authority has a private key which it can use to sign a so-called certificate signing request. From this certificate signing request you can create a signed public key.

Certain companies such as Google and Microsoft provide certain checks to confirm someones identity before providing them with a signed public key. You can pay these companies to provide those checks and give you a signed certificate. Most of these companies are trusted certificate authorities by default in several OSs and browsers. This way for a website for example, you do not have to make changes on a client for your certificate to be trusted.

If you run several servers within your internal company network, you often do not require these external checks. You can create your own certificate authority private key and create a signed public key yourself. This certificate authority is not trusted by default so you should trust the public certificate of your self-signed certificate authority in order establish trust.

Cipher:

A cipher is an algorithm for encryption and decryption. With SSL, during the handshake phase (the phase which establishes an SSL session), a cipher is determined. The client usually provides a list of the ciphers it supports and the server chooses which one to use. During an SSL handshake you can see in logfiles which cipher is chosen.

Pre-Requirement: Here i have two SOA installation, You can use same machine with two installation. In my case i am working on single machine with two installation.

Create a self-signed certificate authority: A blog about creating self-signed certificate authority can be found here. Read it to understand more about it.

• First create a private key for your certificate authority:
• openssl genrsa -des3 -out rootCA.key 2048

Keep this key private! It allows you to sign public keys (see later in this post) and create trust.

Next I self-sign this generated key. This creates a public signed key for the certificate authority. I can load this key in truststores to achieve trust for keys which are signed with this certificate:

• openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem -subj ‘/CN=Conclusion/OU=Integration/O=AMIS/L=Nieuwegein/ST=Utrecht/C=NL’ -extensions v3_ca

You can use the certificate authority private key and certificate as server identity but you shouldn’t. This will give certain validation errors because of the ‘extensions v3_ca’.

Create server identity keys:

Next we create a private key which will be used as identity of the WebLogic server

• openssl genrsa -des3 -out soaserver1.key 2048

After we have created this private key, we can create a certificate signing request for this private key

• openssl req -new -key soaserver1.key -out soaserver1.csr -subj ‘/CN=soaserver1/OU=Integration/O=AMIS/L=Nieuwegein/ST=Utrecht/C=NL’

Next sign the certificate using the information in the private key and certificate of the certificate authority.

• openssl x509 -req -in soaserver1.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out soaserver1.crt -days 1024 -sha256

The next time you sign a certificate, you can use:

• openssl x509 -req -in soaserver1.csr -CA rootCA.pem -CAkey rootCA.key -CAserial rootCA.srl -out soaserver1.crt -days 1024 -sha256

This will increase the previous serial with 1, making sure it is unique.

Creating an identity keystore:

Now you have a signed certificate and a private key. Time to make a Java keystore (JKS) which can be used in WebLogic server and SOA Suite and other pieces of Java.

• openssl pkcs12 -export -in soaserver1.crt -inkey soaserver1.key -chain -CAfile rootCA.pem -name “soaserver1” -out soaserver1.p12
• keytool -importkeystore -deststorepass Welcome01 -destkeystore soaserver1identity.jks -srckeystore soaserver1.p12 -srcstoretype PKCS12

The above steps;

• creating a private key
• creating a certificate signing request
• signing the certificate with the private key of the certificate authority
• creating an identity keystore

need to be done for every server.

Creating a trust keystore:

Creating a truststore is easy and you can do this once and use the same trust.jks file in all your servers.

• keytool -import -alias rootCA -file rootCA.pem -keystore trust.jks -storepass Welcome01

Now role of SOA will came in light, We will see what configuration need to be done on SOA/Weblogic Servers.

Configuration implemented over weblogic server:

Enable SSL for the managed server: 

First Enable the listen port for SSL. In WebLogic console, environment, servers, specify your server, configuration, general and indicate ‘SSL Listen port enabled’. You can also specify the SSL port here.

Specify the keystores for identity and trust: 

In WebLogic console, environment, servers, specify your server, configuration, keystores. You can specify the identity and trust keystores you have created during the above steps.

Configure incoming SSL specifics:

In WebLogic console, environment, servers, specify your server, configuration, SSL. You can specify the identity key used for the server and several checks which can be done when establishing the SSL connection.

Force TLS1.2:

If you want to force WebLogic / SOA Suite to use TLS 1.2 you can specify the following JVM parameters in the setDomainEnv.sh file.

• -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2 -Dhttps.protocols=TLSv1.2

Configuration implemented over SOA server:

Specify identity store:

First you have to specify the identity store which the SOA Suite will use for outbound connections. You can find this setting by going to SOA, soa-infra, SOA Administration, Common Properties, (scroll down), ‘More SOA Infra Advanced Configuration Properties…’

• Here you have to specify the servers identity keystore. In my case /home/oracle/certs/soaserver1identity.jks.

Create a keystore password credential in the credential store:

Next you have to specify the keystore password. If you forget to do this, you will encounter errors like:

On the client:
<Unable to create SSL Socket Factory>

On the server:
Could not obtain keystore location or password

You can set the keystore password by going to your domain, Security, Credentials. You can create a credential map SOA with a keyname/user of KeyStorePassword with the password you have used for your keystore. It will use the same password for the key as for the keystore if not specified. You can create a KeyPassword entry for the password for the key if they differ.

Configure composite to use two-way SSL:

This step is easy. You have to add a binding property to your reference which indicates you want to use two-way SSL.

In the composite.xml file on your reference you can add:

• <property name=”oracle.soa.two.way.ssl.enabled”>true</property>

This causes the composite binding to use the identity (with the credential store password) for outbound SSL specified in the previously configured MBean.

You should of course also not forget to set the endpoint to a port which hosts HTTPS and indicate in the URL that it should use HTTPS to call this endpoint. In my example I’ve overridden the URL in the EM. Be aware though that overriding the endpoint URL might still cause the original endpoint to be called when the overridden endpoint is not accessible (if for example the SSL connection has issues).

Some useful tips to debug issues:

SSL debug logging:

If you want to see what is happening with your SSL connection, it is very helpful to provide some JVM switches in setDomainEnv.

• -Dweblogic.security.SSL.verbose -Djavax.net.debug=all -Dssl.debug=true

You can also enable WebLogic SSL debugging in WebLogic console. Open a server and enable weblogic.security.SSL

Wireshark:

Use Wireshark to monitor connections/handshakes.

• You can confirm the SSL/TLS version being used
• You can see the number of messages which have crossed the wire (allows you to distinguish retries of for example a handshake fails)
• Allows you to decrypt SSL traffic (if you have the private key)
• It allows you to confirm an SSL connection is actually being set up. If you do not see it in Wireshark, no message has been send and the connection build-up fails on the client. This for example happens when the SOA, KeyStorePassword entry has not been set in the SOA Suite credential store.