Java: Sun.Security.Provider.Certpath.Suncertpathbuilderexception: Unable to Find Valid Certification Path to Requested Target

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

1. Go to URL in your browser:

• firefox - click on HTTPS certificate chain (the lock icon right next to URL address). Click "more info" > "security" > "show certificate" > "details" > "export..". Pickup the name and choose file type example.cer
• chrome - click on site icon left to address in address bar, select "Certificate" -> "Details" -> "Export" and save in format "Der-encoded binary, single certificate".

2. Now you have file with keystore and you have to add it to your JVM. Determine location of cacerts files, eg.
   C:\Program Files (x86)\Java\jre1.6.0_22\lib\security\cacerts.

3. Next import the example.cer file into cacerts in command line (may need administrator command prompt):

keytool -import -alias example -keystore "C:\Program Files (x86)\Java\jre1.6.0_22\lib\security\cacerts" -file example.cer

You will be asked for password which default is changeit

Restart your JVM/PC.

source:
http://magicmonster.com/kb/prg/java/ssl/pkix_path_building_failed.html

Unable to find valid certification path to requested target - error even after cert imported

Unfortunately - it could be many things - and lots of app servers and other java 'wrappers' are prone to play with properties and their 'own' take on keychains and what not. So it may be looking at something totally different.

Short of truss-ing - I'd try:

java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=trustStore ...

to see if that helps. Instead of 'all' one can also set it to 'ssl', key manager and trust manager - which may help in your case. Setting it to 'help' will list something like below on most platforms.

Regardless - do make sure you fully understand the difference between the keystore (in which you have the private key and cert you prove your own identity with) and the trust store (which determines who you trust) - and the fact that your own identity also has a 'chain' of trust to the root - which is separate from any chain to a root you need to figure out 'who' you trust.

all            turn on all debugging
ssl            turn on ssl debugging

The   following can be used with ssl:
    record       enable per-record tracing
    handshake    print each handshake message
    keygen       print key generation data
    session      print session activity
    defaultctx   print default SSL initialization
    sslctx       print SSLContext tracing
    sessioncache print session cache tracing
    keymanager   print key manager tracing
    trustmanager print trust manager tracing
    pluggability print pluggability tracing

    handshake debugging can be widened with:
    data         hex dump of each handshake message
    verbose      verbose handshake message printing

    record debugging can be widened with:
    plaintext    hex dump of record plaintext
    packet       print raw SSL/TLS packets

Source: # See http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The SSL certificate isn't trusted by Java. The certificate may be self-signed, or it may be signed by a CA (Certificate Authority) whose root certificate is not in the Java certificate store. The set of root certificates known by Java isn't as extensive as the set that your web browser knows about.

Assuming you do indeed trust the certificate in question, you can add it to the Java certificate store (which is called cacerts) using the keytool command. For example (change paths as appropriate for your installation and OS):

keytool -import -trustcacerts -file NewRootCACertificate.crt -keystore "C:\Program Files\Java\jre1.8.0_31\lib\security\cacerts"

By default the cacerts keystore has a password of changeit.

UPDATE:

Problem resolved to a working system in chat, although not with ideal configuration.

• It looks like the previously working set-up was not using SSL.
• This set-up stopped working, perhaps because of software updates changing the configuration (my speculation) to prevent login in the plain.
• starttls was switched on to address the inability to login in the plaintext IMAP mode.
• The lack of suitably-trusted certificate then emerged as an issue, hence the error in the question.
• The certificate that was there (probably default created during installation of the mail server) didn't have the right domain name in the Common Name, but even with a fresh certificate, and adding it to what seemed to be the right cacerts key store (the key store path was mentioned in the application logs) the client failed to trust the certificate. We never got to the bottom of that.
• Working set-up was arrived at with the following configuration (i.e. trusting the server by hostname and connecting directly with SSL rather than using starttls):
  
  • props.setProperty("mail.imap.ssl.enable", "true");
  • props.setProperty("mail.imap.ssl.trust", "mydomain.com");

This isn't ideal, however the client application is running on the same machine as the IMAP server, so this is probably not a huge risk.

In the long run, you may want to make a note that you did this work-around, and see whether you can get the certificate verification happening by other means, possibly a custom certificate verification handler or explicitly specifying the certificate store.

CXF:PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The error was actually a CXF one and not a certificate one. Specifically, the Binding Provider actually ignores JAXWS properties and i had to pass the SSL context as shown below:

SSLContext sc = "your custom SSL Context"
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setUseHttpsURLConnectionDefaultSslSocketFactory(false);
tlsParams.setSSLSocketFactory(sc.getSocketFactory());

Repeatedly getting PKIX path building failed and unable to find valid certification path to requested target

I am able to resolve this issue by replacing the cacert file. To be more precise I have replace cacert of Eclipse Adoptium\jdk-17.0.1.12-hotspot with Eclipse Adoptium\jre-8.0.312.7-hotspot to fix it.

Things to my surprises is that, After replacing new cacaert file I did not had to use keytool to load certificate manually. It's still mystery why old cacert file was causing trouble.

NOTE: Take backup of original cacert file before you replace with new one.

try this solution if still not resolved.

---

Related Topics