How to debug SSL issues with weblogic server

First of all I would suggest using the following debug flag in case of any kind of SSL issue on Weblogic server:

-Dweblogic.StdoutDebugEnabled=true

-Dssl.debug=true

 

If you need to debug any SSL issue with the standalone JAVA class then you can use the following debug flag:

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

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

Then In case if you are getting the following exception in the debug trace:

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

Then you can follow the following steps to resolve this issue:
1: If you are running your java code as a standalone class then you should use the following to run the java code:
java -Djavax.net.ssl.trustStore=trustStore -Djavax.net.ssl.trustStorePassword=trustStorePassword YouJAVAclass

where,
trustStore: is the keystore which should contain the root certificate from the server hosting the service.
trustStorePassword: 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

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

Error:

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

Reason:

This is something like both the Client and the 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 initialized by the Client end and Sever has to choose any one of the Ciphers presented by the Client to communicate on SSL.
If the Server does not supports any such Cipher algorithm which is common to Client then the communication will not happen.

So, If can force the Client (Weblogic) to use the weaker ciphers and the Server does not have any constraints on using the limited ciphers then we can make the connection over SSL.

Resolution:

As by default Weblogic Server uses the certicom implementation of SSL.

The above exception is because the certicom implementation of SSL is not able get a common cipher negotiation.

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

In order to use the SUN implementation of SSL we can use the following properties 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 be used as JAVA properties so that the WLS JVM uses these values rather than using its own implementation.

We can also use the above properties in our code as mentioned below:

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” );

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

Let us understand one way SSL behavior:

WLS as Client:

Remote Service as Server to be accessed over SSL:

This is broader picture of SSL.

  1. Client (WLS) Initiates the Handshake with the server (Remote Service).
  2. Server (Remote Service) will present its certificate to the Client (WLS).
  3. Client (WLS) will verify the certificate by looking into the Trust Keystores.
  4. That is why there is a need to import the Server Certificate (Remote Service certificate) here into WLS Trust Keystore.
  5. Since by default DemoTrust.jks is used as the Trust keystore by WLS hence the Remote Service 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.
  7. If the Server supports some of the cipher present by the Client then Handshake is successful and SSL communication will happen.
  8. If there is no common ciphers between the Client (WLS) and the Server then SSL will not happen.

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 is clear whether the issue is with the server or the client.
  2. If the service is accessible with standalone client and it is not accessible from WLS then we should try to run the standalone class with the same JDK/JRE which is being used by the WLS.
  3. This is clear up whether the issue is with the JDK/JRE or it is the issue with the WLS configuration.

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

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 simply means that the URL that you are trying to access does not have a Valid Certificate or the Certificate used by the URL provider is not issue by a Trusted Certificate Authority.

in Order to remove the above error message, there can be two secnarios:

1: When the Client which is trying to access the URL is a Java Standalone Client then we have to import the root certificate of the URL into the cacerts file present in the JAVA/jdk/jre/lib/security/ directory.

2: If the Client is the WLS server trying to access the URL, then we need to determine what is the Trust Store used by the 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: It will show a waring message showing the certificate is not valid, we have to click on the view certificate option of the pop-up and then we have to click on the Install certificate.

3: Then we need to open the IE >>> Internet Options >>> contents >>> certificates >>> Trusted Certificate option.

Find the certificate just installed and export that certificate into DER encoded binary format and store it as C:/root.cer

Now in order to import this certificate into the cacert file or into any keysttore we have to use the following keytool utility from JAVA :

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.

FB Comments

comments

27 Comments

  1. weblogictips September 10, 2014
  2. Krishna September 10, 2014
  3. weblogictips September 10, 2014
  4. Krishna September 10, 2014
  5. weblogictips August 14, 2014
  6. srinivas August 14, 2014
  7. bagdagol March 10, 2014
  8. weblogictips February 16, 2012
  9. Raj February 15, 2012
  10. Raj February 15, 2012
  11. Raj February 15, 2012
  12. Raj February 15, 2012
  13. weblogictips February 15, 2012
  14. weblogictips February 15, 2012
  15. weblogictips February 15, 2012
  16. Raj February 14, 2012
  17. weblogictips December 19, 2011
  18. Reena December 15, 2011
  19. Reena December 15, 2011
  20. weblogictips December 14, 2011
  21. Reena December 13, 2011
  22. Sukrut Wagh May 31, 2011
  23. Ajeeb Peter April 20, 2011
  24. weblogictips April 19, 2011
  25. Ajeeb Peter April 18, 2011
  26. weblogictips March 8, 2011
  27. Ravish Mody March 7, 2011

Leave a Reply

Your email address will not be published. Required fields are marked *