PKIX Path does not chain with any of the trust anchors error in Windows Environment

Question

I am a bit of an idiot to how SSL and Webservices work at the fine-grained level. I am developing a system that calls several web services, some with secured URLs and others that are not with little problem. Currently, however, I am doing an integration with Endicia's LabelServer Web API. The webservice is used to calculate and print postage.

The test URL and WSDL is at: https://www.envmgr.com/LabelService/EwsLabelService.asmx

I used wsimport to create and setup a Java client for connecting to this webservice but when I try to all it I get the error

PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors

This error is documented here: Java7 Refusing to trust certificate in trust store

in which it's discussed how Java 7 forces an error with self-signed certificates with "bad" keyusage. Bad in this situation is defined as not containing keyCertSign. The webservice does work with Java 6. I can believe this situation might apply to this certificate since it's only being used as a test server, but I don't know how to verify that.

There's a bug report on it that is solved (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7018897), but I'm not sure how any of this translates to fixing the problem for a Windows Tomcat environment. I exported the certificate onto my machine, but am uncertain of how to proceed from there.

EDIT: I tried using OpenSSL to modify the certificate and add it to my keystore as described in the "Refusing to trust certificate in trust store" link and it didn't work. It seems like this is a process that is done by the owner of the certificate, right? I wonder if there's some way I can configure my Java 7 environment to let this certificate through.

Answer 1

The default Java certificate checks are pretty strict, and have apparently gotten stricter. One workaround is to initialize an SSLContext with a custom X509TrustManager. A trust manager that does nothing, i.e. is completely insecure, that I once wrote for testing looks like this:

TrustManager[] trustAllCerts = new TrustManager[]{
   new X509TrustManager() {
      public java.security.cert.X509Certificate[] getAcceptedIssuers()
         {
            return null;
         }
      public void checkClientTrusted(
         java.security.cert.X509Certificate[] certs,
         String authType )
         {
         }
      public void checkServerTrusted(
         java.security.cert.X509Certificate[] certs,
         String authType )
         {
         }
   }
};

Obviously you would want to actually check the certificate chain in a real program. You could then try to initialize an SSLContext with it and call SSLContext.setDefault() if your API has no other way of configuring SSL. If the API uses the default SSL context then this should work.

Key usage does not appear to be the issue in this case as the certificate chain is not self-signed. Testing the URL appears to show that the leaf certificate is not self-signed and (2) the other two certificates in the chain appear to have certificate signing enabled. An alternative possibility is that Java 6 and Java 7 have separate trust stores and the root certificate is not in the Java 7 store. You may want to double-check that. If you have access to OpenSSL, you can get the certificate chain from the server with:

openssl s_client -host www.example.com -port 443 -showcerts

---

Apparently updating the trust store was the key (pun intended). The OP reports:

I downloaded OpenSSL for Windows 64 and then used this command to download the certificate chain:

openssl s_client -host www.webserviceurl.com -port 443 -showcerts > c:\temp\certchain_output.crt

Then I want to import it into my browser's keystore like so (from the JDK's home directory/jre/lib/security):

keytool -import -alias ca -file certchain_output.crt -keystore cacerts -storepass changeit

I believe using X509TrustManager could provide an effective solution as well.

Answer 2

The certificate chain validation logic has indeed changed between Java 6 and Java 7. It seems that the certificate chain is considered to be invalid because the validity end date of the intermediate certificate is after the validity end date of the root certificate. This is a Java bug which was fixed with JDK 1.7.0_72 and 1.8.0_25.

If you can't upgrade your JDK, here is is a workaround since you say are in a debug environment and you have control over your keystore. You can't change any of the certificates of course (since you don't have the private keys), but you can import the intermediate or the server certificate into a local keystore, which means it will be trusted by default, and the rest of the chain validates without any problem.

1. Download the certificate for www.envmgr.com or www.starfieldtech.com as trusted_certificate.pem
2. Use keytool to import the certificate into a local keystore named my_keystore with keytool -keystore my_keystore -importcert -file trusted_certificate.pem
3. Launch wsimport -J-Djavax.net.ssl.trustStore=my_keystore https://www.envmgr.com/LabelService/EwsLabelService.asmx

Answer 3

Try import the certificate you need into java truststore located into jdk_xxx/jre/lib/security/cacerts using keytool

set the jvm parameter Djavax.net.debug=ssl to see more debug information