SSL Concept and How to debug SSL issues with weblogic server

Let's get some good understanding on SSL.

- Two parties wants to exchange data securely over the network.

- So they need uncrackable encryption algorithm support to achieve secure communication between two parties irrespective of platforms.

- Encrypted data is not understandable to the application layers as its needs to be decrypted before data/content could  be used by app layers.

- Hence, top of  application layer, one more layer is introduced and is called Secure Socket Layer or SSL Server.

- In essence, Client ( browser) connects to SSL Layer and SSL Layer in turn communicates with App Layer, typically, Https (ssl) to Http (app layer).

- By requirement, requests from Client Browser to SSL Layer must be secured with the use of some good encryption technique however SSL Layer to App Layer can remain as non secured.

- A Typical example: User logs into ebay website and uses his/her credit card to purchase items  over internet.

- Credit Card Data entered by User cannot be sent in plain text to server due to man in the middle attack problems.

- So, secure communication is achieved using a public-private key encryption mechanism on the data to be exchanged between two parties.

- Private key will be known to SSL Server only.

- Common Public Key will be issued by SSL server to the public who wants to communicate with it.

- One must remember that Client ( public key )  and the SSL Server ( Private Key) doesn't know each other.

- Man in the middle attacker can act as a ebay web site and can steal credit card details. Because the public certificate can also be issued by masqueraded ebay SSL server dynamically on demand to the client.  

- So, In theory, there is nothing called secured communication.

- As solution, both the Client and Server needs to trust some third party vendor (for ex:Govt) who can verify and authorize EBAY type of vendors for their real identity. 

- So, both the user (client) and ebay (SSL server) will have to trust upon third party vendors whose job is to know EBAY company in detail. 

- The third party vendors are the trusted authorities who sells the certificates to ebay type of apps or webapps(to be imported on SSL Layer of web apps) and they are one who issues a unique private (for ebay)  and common public key (client) as part of this certificate they sell.

- One can buy the certificate by submitting CSR information at vendor site. 

- Some of the well re-known vendors in the market are Geo Trust or Verisign.

So, without a TRUST no secured communication can be established. The name trusted keystore is meant on this same context  as well.

Anybody can sell certificates but not all of them can be trusted source. Usually, the browser or server api languages comes installed with trusted root CA certificates. Having these certificates installed on browser or at server means these are the vendors  trusted by borwser or servers. If browser shows the cross or warnings sign then user needs to carefully deal with such sites before making any transactions or giving away valuable information over the net

A look at SSL Handshake using symmetric session key:  

At look at SSL handshake in general:

Let's get some basic understanding on one way SSL communication:

One way SSL is the encryption process that happens from client to server only.

Key points to note down:

The SSL server will have a private key installed as server certificate.

The User or Client (browser) who wants to communicate to SSL Layer would need a public key to encrypt and send the data securely over the network. This public key certificate will be downloaded by client from SSL Server on demand.

The data encrypted by client can only be decrypted by private key at SSL Layer. 

For the reverse communication i.e Server (encrypts the data) to client(decrypts data)  one needs use two way SSL Mechanism. In other words, its also called peer to peer two way SSL communication where both the peers will have the private certificates installed at their ends using their separate private-public key for decryption and encryption mechnanisms.

WLS as Client:

Remote Service as a Server to be accessed over SSL layer:

This is broader picture of SSL.

1. Client (WLS) Initiates the Handshake with the server (Remote Service).
2. Server (Remote Service) will present its remote public certificate to the Client (WLS).
3. Client (WLS) will verify the certificate by looking into the Trust Keystores.
4. This is the reason why we would need to import the remote public Certificate (Remote Service certificate) into WLS Trust Keystore in order to successfully handshake with remote SSL Server.
5. By default DemoTrust.jks keystore is used as a Trusted keystore by WLS and hence the Remote public certificate is imported generally into the DemoTrust.jks file.
6. Then Client will send the list of Ciphers to be used for encryption over the network to the remote SSL server.
7. If the SSL Server supports the ciphers sent by the Client, then first level of handshaking will succeed and then SSL communication will be established between client and SSL server.
8. If there are no common ciphers available between the Client (WLS) and the Server then secure communication will fail.

How to debug:

1. Try testing the Remote Service connectivity with the standalone client to test whether the service is accessible over SSL or not. This way we will be clear enough whether the issue is on remote server or on the client side.
2. Check to see standalone java code is using the same JRE as used by WLS.

The following Java command line system property variables can be used to enable debug log in SSL modules used by weblogic modules.

-Dweblogic.StdoutDebugEnabled=true

-Dssl.debug=true

 If we need to debug any Javax Net API related All/SSL problems then one could use the following debug flags at the java command line:

-Djavax.net.debug=all :                 This is for turning all debugging.

-Djavax.net.debug=ssl :                This is for turning SSL debugging.

Common Errors:

Symptom 1:

Errors:

FINE: Cannot complete the certificate chain: No trusted cert found

FINE: Validating certificate 0 in the chain: Serial number: 1398096
Issuer:C=CZ, CN=I.CA – Standard root certificate, O=Prvni certifikacni autorita a.s.
Subject:C=SK, CN=damas.sepsas.sk, ST=Slovakia, L=Bratislava, O=Slovenska elektrizacna prenosova sustava, a.s., OU=Damas Energy, ?=ICA – 595029
Not Valid Before:Tue Aug 11 12:07:51 CEST 2009
Not Valid After:Wed Aug 11 12:07:51 CEST 2010
Signature Algorithm:SHA1withRSA

FINE: validationCallback: validateErr = 16

Resolution:

We can follow below steps to resolve:
1: If you are running Java code in a standalone command prompt then you could use the following command to run the Java code to make use of SSL resources at client side:
java -Djavax.net.ssl.trustStore=<<JKSTRUSTSTORE.jks>> -Djavax.net.ssl.trustStorePassword=<<TRUSTPASSWORD>> YourJAVAclass

where,
JKSTRUSTSTORE: is the keystore which should have the root certificate from the SSL server hosting the service.
TRUSTPASSWORD: keystore password for the trustStore.

2: If the java code is running on the WLS server then WLS server being the client you should use:
-Djava.protocol.handler.pkgs=weblogic.net
-Dweblogic.security.SSL.trustedCAKeyStore=trustStore

You can set the above envrionment properties using System.setProperty("");

——————————————————————————————————————————————————-

Symptom 2:

Error:

FINE: ……….. Eating Exception ……….
java.security.NoSuchAlgorithmException: Algorithm ECDH not available
+ at javax.crypto.KeyAgreement.getInstance(DashoA13*..)+

Reason:

This is like both the Htps Client and the HttpS Server is not able to negotiate on a common Cipher (Algorithm) and hence the handshake is failing.

Just to give you a brief idea: the Cipher is an encryption algorithm which is typically initialized by the Client end and the same Ciper algorithms should be supported at SSL Sever so as to choose any one of the Ciphers presented to be used to establish a secure communication over SSL layer.
If the Server doesn't support any such Cipher algorithms as with Client then the communication will not succeed.

It is also possible to force the Client (Weblogic) to use the weaker ciphers provided if the Server doesn't have any constraints in using the limited ciphers then connection over SSL could be established.

Resolution:

By default Weblogic Server uses the certicom implementation of SSL. Considered to to be faster than sun.

The above exception is seen because of the certicom implementation of SSL where it is unable find a common cipher during SSL handshaking process between client and server.

We can hint Weblogic server to use the SUN implementation of SSL instead to solve the issue.

In order to use the SUN implementation of SSL the following properties has be to set as a command line parameters in the Weblogic server:

-Djavax.net.ssl.keyStore
-Djavax.net.ssl.keyStoreType
-Djavax.net.ssl.keyStorePassword
-Djavax.net.ssl.trustStore
-Djavax.net.ssl.trustStoreType
-Djavax.net.ssl.trustStorePassword
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

all the above properties can also be also set programmatically  or can be overidden in the code thats deployed on weblogic server so that the WLS JVM would use these values at runtime rather than using its own implementation.

System.setProperty( “javax.net.ssl.keyStore”, “***” );

System.setProperty( “javax.net.ssl.keyStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.keyStorePassword”, “***” );
System.setProperty( “javax.net.ssl.trustStore”, “***” );
System.setProperty( “javax.net.ssl.trustStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.trustStorePassword”, “***” );
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
System.setProperty( “java.protocol.handler.pkgs”, “com.sun.net.ssl.internal.www.protocol” );

————————————————————————————————————-

——————————————————————————————————————–

Symptom 3:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

How to debug above Error:

The above error denotes that the URL you are trying to access does not have a Valid Certificate or the Certificate used by the URL provider is not issued by a Trusted Certificate Authority.

in Order to resolve the above error message, there can be two scenarios:

1: When client accesses the SSL URL in a Java Standalone code then it is needed to import the root certificate of the SSL URL into the cacerts file, which can be located @JAVA_HOME/jre/lib/security/ directory.

2: If the Client is the WLS server here, which is trying to access the SSL URL, then we need to determine what is the Trust Store configured at Weblogic Server.

If the Weblogic server is using DemoTrust then we can import the root certificate of the URL in the cacerts file of the JAVA used by the WLS server.

If the Weblogic Server is using Custom Trust then we can import the root certificate of the URL in the Custom Trust keystore used by the weblogic server.

How to get the root certificate of the URL:

1: Copy the URL and paste in the browser address bar , let us say IE and press Enter.

2: Typically, the page show a warning message indicating the certificate is not valid, Click on the view certificate option of the pop-up and then we have to click on the Install certificate.

3: Once installed, then open the IE >>> Internet Options >>> contents >>> certificates >>> Trusted Certificate option.

Find the certificate that was just installed and export that certificate into DER encoded binary format and store it as root_vendorName.cer

To import the new certificate into the cacert file or into any keystore we will have to use the following keytool utility that comes pre-installed in JDK/bin folder :

keytool -importcert -v -alias root_cert -file c:/root.cer -keystore c:/java/jdk/jre/lib/security/cacerts -storepass changeit

-alias: this can be anything .

-file: this is the file needs to be imported.

-keysotore: this is the keystore file where we need to import the certificate.

-storepass: this is the password for the keystore file, which is “changeit” by default for cacerts.

Reference:

http://www.weblogic-tips.com/2010/05/11/how-to-debug-ssl-issues-with-weblogic-server/

The Secure Socket Layer, SSL for short, is a protocol by which many services that communicate over the Internet can do so in a secure fashion. Before we discuss how SSL works and what kinds of security it provides, let us first see what happens without SSL.

Life on the Internet without SSL

Let us compare communications between computers on the Internet and communications between people over the telephone. Without SSL, your computer-to-computer communications suffer from the same security problems from which your telephone communications suffer:

• Who are you talking to? In a phone conversation, how can you be sure that the person who picks up the phone at the other end is really the person you are trying to call (especially if you have never spoken to them before)? What if your phone call was intercepted or re-routed, or what if someone else is answering your call recipient’s phone? There really is no way to be sure you have reached the right person, especially if they are actively trying to fool you.
• Eavesdropping? As you are aware of from watching TV or reading, it is very easy to tap phone lines: the police and spies do this all the time to covertly gather information. It is not easy to detect if your lines are tapped. The same applies with communications over the Internet — how can you be sure that your communications are not being “tapped” and recorded?  This is especially problematic in public wifi hotspots.

This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the right servers  (i.e. those at your bank and not those at a hacker’s or phisher’s web site), and 2. knowing that your data is safe from prying eyes during transit to those computers. This is where SSL comes in.

Enter the Secure Socket Layer (SSL)

To solve these problems to a large degree, most Internet services support use of SSL as a mechanism for securing communications. To illustrate how SSL works, let us use another analogy.

Client wants to communicate with a company to send important information back and forth. Client wants to be 100% sure that s/he is communicating with this particular company and that no one can eavesdrop on or intercept the communications. How can s/he do this?

• Client sends a courier to the company’s address.
• The company has envelopes that, when closed, can only be opened by the company. The company and the courier go together to a trusted third party — a notary — which makes the company provide documentation to prove its identity. The notary certifies the company’s secure envelopes and the courier takes these back to the client.
• The client gets the envelopes and, if it trusts the notary’s reputation, can be sure that they are actually from the company indicated.
• The client also has secure envelopes that, once sealed, only the client can open. It puts some of these in one of the company’s secure envelopes and sends them back to the company.
• The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has the client’s secure envelopes.
• The company has another kind of envelope that can be opened and sealed only by using a special combination. The company puts this special envelope with the combination lock, together with the combination, into one of the client’s secure envelopes. The company seals the envelope.
• The company has another type of secure envelope that anyone can open, but which only the company can seal. If you open one of these sealed envelopes, you know for sure that it was sent by the company. The company puts the whole package inside this and sends it to the client.
• When the client gets the secure envelope, it opens it and thus knows that it came from the company. It then opens the next secure envelope inside that can only be opened by the client. Inside it gets out the combination-envelope and the combination itself.
• The client the puts his data in the combination envelope, seals it and sends it to the company.
• The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
• The procedure is repeated as often as necessary for required communications.

SSL relies on the concept of “public key cryptography” to accomplish these tasks. In normal encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate these passwords to people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the user’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe and secure, and private.

If John sends Mary a message encrypted with Mary’s public key, then only Mary can open it, as only she has her private key. This is like an envelope that anyone can seal but which only Mary can open.

If John sends Mary a message encrypted with John’s private key, then anyone can open it, as everyone has access to John’s public key. However, successfully opening the message proves that it was sent by John and no one else, as only John has access to his private key. This is like an envelope that only John can seal, but which anyone can open and thus prove that John sealed it.

SSL in Action

So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

• A company wishes to secure communications to their server company.com.
• They create a public and private key for company.com (this is also known as as “SSL Certificate“).
• They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
• Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s private key… we will see why below.

Then, when Client wishes to communicate with the company at company.com,

• Client makes a connection to company.com with its computer. This connection is made to a special “port” (address) on company.com that is set up for SSL communications only.
• When Client connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
• Client gets the public key and decides if it is OK…
  • If the public key has expired, this could be a problem
  • If the public key claims to be for some domain that is not company.com that could be a problem.
  • Client has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, client can decrypt the validation information, prove the validation is from Thawte and verify that the public key is certified by Thawte. If Client trusts Thawte, then Client can trust that he/she is really communicating with Company. If Client doesn’t trust Thawte, or whatever Third Party company is actually being used, then the identity of who is running the computers to which Client is connecting is suspect.
• If client decides to trust the public key, then Client will send to the company the Client’s public key.
• The company will then generate a “password” and encrypt it using both Client’s public key and Company’s private key, in succession, and send it back to the client.
• Client will decrypt the password. This process proves that the company sent the password and that only Client was able to read it.
• If the client doesn’t trust the server, then the communication is terminated.
• If the client has its own SSL certificate installed, it may send that to the server at this point to see if the server trusts the client.  Client-side SSL certificates are not commonly used, but provide a good way for the client to authenticate itself with the server without using a username or password.  In the case where this is used, the server would have to know about the client’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.
• Once the client is happy with the server (and the server with the client, if needed), then the client choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (password) for use with that Cipher.  The client encrypts this password using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this password, which is now shared by both the client and server.
• The client will then start communicating with the company by encrypting all data using this password and the chosen Cipher. Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly the client) to prove its identity and right to domain.com and to enable the client and server to generate and securely communicate a common password.

So, Are there Limitations to This Process?

This all sounds great — what are the down sides? There are a few.

Key Length: The statement that “only someone with the private key can decrypt something encrypted with the public key” is true so long as the private key cannot be “guessed”. Hackers may try to do this by trying all possible private key combinations. Older “40bit” keys can be broken by trial and error if one has access to vast computer resources and a good amount of time. These days, keys used in SSL are 128bit or better. There are so many possible keys with 128bit that it would take significantly longer than the age of the universe to “guess” one.

Trust: While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are actually communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization. Some “secure sites” do not bother to get a third party’s approval and have their keys approved by “themselves”. Others use third parties that are almost free and which spend very little effort in validating the company. In these cases, SSL provides you with no real assurance that you are really talking to your intended company and not some hacker trying to forge their identity to communicate with you in a manner in which you think you are safe.

For defensive use of the web, you should pay attention to warnings generated by SSL when you connect to secure sites. Such warnings include “expired certificates”, “domain name mismatches” — where the domain name presented by the company is different than the one to which you are connecting, and “non trusted certificates” — where the public key (certificate) presented by the company was not validated by a third party that your computer trusts. In all of these cases, you should be wary.

Ciphers: SSL uses one of a large variety of possible “ciphers” to perform the symmetric encryption.  Use of a poor/weak cipher can result in fast SSL that is easily compromised.  Currently, it is recommended that one use 128-bit or stronger AES encryption as your cipher.  See: 256-bit AES Encryption for SSL and TLS: Maximal Security.

What Services Can be Protected With SSL?

Almost any Internet service can be protected with SSL. Common ones include WebMail and other secure web sites such as banking sites and corporate sites, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and communications over all of these and other services.