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.
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
Rhashimoto helped me find the solution that worked for me:
I downloaded OpenSSL for Windows 64 and then used this command to download the certificate chain:
Then I want to import it into my browser's keystore like so (from the JDK's home directory/jre/lib/security):
I believe using X509TrustManager could provide an effective solution as well.
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.
www.envmgr.com
orwww.starfieldtech.com
as trusted_certificate.pemkeytool
to import the certificate into a local keystore named my_keystore withkeytool -keystore my_keystore -importcert -file trusted_certificate.pem
wsimport -J-Djavax.net.ssl.trustStore=my_keystore https://www.envmgr.com/LabelService/EwsLabelService.asmx
The default Java certificate checks are pretty strict, and have apparently gotten stricter. One workaround is to initialize an
SSLContext
with a customX509TrustManager
. A trust manager that does nothing, i.e. is completely insecure, that I once wrote for testing looks like this: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 callSSLContext.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:
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:
Then I want to import it into my browser's keystore like so (from the JDK's home directory/jre/lib/security):
I believe using X509TrustManager could provide an effective solution as well.
Try this OUT, it accepts all