Reputation: 1085
I've been given a jar file without access to the code (or ability to modify) and a .cer
ca certificate file.
When running the jar file; I get this error (I put the placeholder.hostname.com
):
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "placeholder.hostname.com": PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I've trusted the ca certificate system-wide on my linux machine and seem to be able to talk to the server through curl
and the browser. I also added it to this /etc/ssl/certs/java/cacerts/
with keytool
(not sure if that makes sense as I'm not a java developer). However, I still get the same error as above.
Is there a way to make java trust the certificate outside the code? Or is that not even the problem?
(sorry if my security/cert terms are off)
Thanks
Upvotes: 0
Views: 147
Reputation:
What the error message is saying is this: TLS client was unable to construct a complete certificate path from the leaf cert provided by the server during the TLS handshake to any of the trusted certs in the truststore. In the absence of more details, and as you are saying that curl and the browser work fine, I assume that both browser and curl use a truststore which includes required cert. If this is really the case, truststore used by the Java application probably doesn't contain the same certificate. In other words, it uses different truststore.
First thing you should check is the truststore actually used by the Java application. To do that, run your Java application with -Djavax.net.debug=ssl,handshake
. Unless javax.net.ssl.trustStore
has been overriden, it will use one of the truststores according to the following hierarchy:
[...] If the javax.net.ssl.trustStore system property was not specified, then: if the file java-home/lib/security/jssecacerts exists, that file is used; if the file java-home/lib/security/cacerts exists, that file is used; if neither of these files exists, then the TLS cipher suite is anonymous, does not perform any authentication, and thus does not need a truststore. [...]
I suspect you've added the cert to system-wide truststore but not to the Java-specific.
Upvotes: 1