PKIX path building failed: unable to find valid certification path to requested target

charybr's picture

Problem:
While trying to establish an HTTPS connection to a Web Service, we get the exception:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
In this case I was trying to establish HTTPS connection to MS Exchange 2007 Web service. What this usually means is that the server is using a test certificate.

Solution:
WSO2 WSAS should recognize this test certificate by means of truststore. One way is to upload keystore in WSO2 WSAS Admin UI. But uploading in Admin UI requires a private key.

Below is the alternative way:
1 Generated truststore using http://blogs.sun.com/andreas/entry/no_more_unable_to_find
2 Place the generated trustsore file (jssecacerts) in "wso2wsas-2.1\conf".
3 In the program, set the System property
 System.setProperty("javax.net.ssl.trustStore", "conf/jssecacerts");
 System.setProperty("javax.net.ssl.trustStorePassword", "<password>");


Best Regards,
Chary

nandanam's picture

Are you trying to use WSO2 WSAS as a client ?

Chary,
     Can you please explain the scenario in more detail.
1.) Are you using WSAS as a client to the web service MS Exchange 2007 ?
If you want to upload a public key certificate to a existing key store in WSAS, this can be done using "Import certificate" functionality of Admin UI. This doesn't require private key. You can import certificate using Manage -> Key Stores -> Import Certificate ( Gold shield icon )
 
Thanks, Nandana

jim.telford@infousa.com's picture

What is the password

---------------------------------------------------------
Problem:
While trying to establish an HTTPS connection to a Web Service, we get the exception:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
In this case I was trying to establish HTTPS connection to MS Exchange 2007 Web service. What this usually means is that the server is using a test certificate.
Solution:
WSO2 WSAS should recognize this test certificate by means of truststore. One way is to upload keystore in WSO2 WSAS Admin UI. But uploading in Admin UI requires a private key.
Below is the alternative way:
1 Generated truststore using http://blogs.sun.com/andreas/entry/no_more_unable_to_find
2 Place the generated trustsore file (jssecacerts) in "wso2wsas-2.1\conf".
3 In the program, set the System property
 System.setProperty("javax.net.ssl.trustStore", "conf/jssecacerts");
 System.setProperty("javax.net.ssl.trustStorePassword", "<password>");
Best Regards,
Chary
---------------------------------------------
Thanks for the info, but what is the password that I should use?  I have tried the default for WSAS as well as a number of others, but none seem to work when I run the InstallCert java app.
 
Thanks again for the info!

nandanam's picture

Password of the keystore

Hi Chary,
       This is the password of the keystore. Looking at the tutorial you used, this has to be "changeit" if you used the command "java InstallCert <host>[:port]" and if you used it giving a password like "java InstallCert <host>[:port] [passphrase]" then the password is the [passphrase] you used.
thanks,
/nandana
 

jim.telford@infousa.com's picture

password of the keystore

That's it!!
Thanks Nandana!!

alex.denipaul.gmail.com's picture

We are having an application

We are having an application that connects to the LDAP through JNDI ssl/non-ssl. When it tries to connect through SSL it throws the following exception in Windows (uses sun JRE)

Root exception is 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 on cheap web hosting.

For this exception, I have tried quite a bit of things from internet. Most of them say that I have to install the rootCA certificate. Nothing helped.

The value of the trust store is assigned at the run-time (in the JNDI code) using the api
System.setProperty("javax.net.ssl.trustStore", c:\\certificates\\mystore);

In AIX (using IBM JRE), the same code throws the following exception.

Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:java.security.cert.CertPathValidatorException: The certificate issued by is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error

Our application has a application server, webserver and a database. To isolate the problem, I wrote a standalone JNDI program. It connects to the same LDAP with same set of certs from the same machine (both Windows and AIX) through SSL.

Finally I found out 2 ways to make the application work.

1. When I import the certificates in to jssecacerts iniside the jre\lib\security I am able to connect through SSL. The trust store path is not necessary here.
2. When I give the path of the trust store along with the Java VM options in my appserver configuration file and reboot, it works. I think it is similar to giving the keystore path in the command line, i.e.,

c:\> java -Djavax.net.ssl.trustStore=c:\\certificates\\mystore

From this I would say the certificates are not the problem. My app is not able to get the trust store path when I set the path at runtime or the value of the path gets overwritten at some point.

Unfortunately I can resort to any of the above 2 solutions. Have anyone come across these kind of problems? Any help would be appreciated.

edwin.jesas.gmail.com's picture

Really nice and informative

Really nice and informative post.Looking for dedicated server reviews.

clarkandreson.gmail.com's picture

hello every one

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks

Clark
cissp
USA

Hot Topic
Hot
Topic

Google Gadgets are a nice way to develop user interfaces for distributed services. The fact that they can be hosted anywhere over a network, not necessarily in the very portal server they eventually run in makes them re-usable and allows users to quickly...

Latest Webinar
In this webinar we'll share the range of concerns we've heard from the industry, and survey some of the new and sometimes subtle types of lock-in associated with cloud technologies.
Wednesday, 8 September, 10.00 AM (PDT)