First of all I would suggest using the following debug flag in case of any kind of SSL issue on Weblogic server:
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:
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
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
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:
FINE: ……….. Eating Exception ……….
java.security.NoSuchAlgorithmException: Algorithm ECDH not available
+ at javax.crypto.KeyAgreement.getInstance(DashoA13*..)+
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.
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:
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.
- Client (WLS) Initiates the Handshake with the server (Remote Service).
- Server (Remote Service) will present its certificate to the Client (WLS).
- Client (WLS) will verify the certificate by looking into the Trust Keystores.
- That is why there is a need to import the Server Certificate (Remote Service certificate) here into WLS Trust Keystore.
- 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.
- Then Client will send the list of Ciphers to be used for encryption over the network.
- If the Server supports some of the cipher present by the Client then Handshake is successful and SSL communication will happen.
- If there is no common ciphers between the Client (WLS) and the Server then SSL will not happen.
How to debug:
- 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.
- 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.
- 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.