5

I have an example command-line java application from a vendor; it depends on SSL authentication. I have the vendor's certificate(s), I can see them in my java 7 cacerts file (windows, c:\program files\java\jdk1.7.0_07\jre\lib\security\cacerts). If I open the java 8 cacerts file, they are not there (c:\program files\java\jre1.8.0_66\lib\security\cacerts)

If I set a path so that java 8 is first, the program works. If I change the path so that java 7 is first, the program fails with a certification error:

C:\project\tryCerts\Demo2>path=c:\program files\java\jdk1.7.0_07\bin;c:\program files\java\jre1.8.0_66\bin


C:\project\tryCerts\Demo2>java -jar vendorCmd.jar user1 password2 environment3
Dec 22, 2015 11:11:35 AM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser]  parse
INFO: WSP5018: Loaded WSIT configuration from file: jar:file:/C:/project/tryCerts/Demo2/vendorCmd/dist/vendorCmd.jar!/META-INF/wsit-client.xml.
Unable to log in: com.sun.xml.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: sun.security.validator.Va
lidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to re
quested target

C:\project\tryCerts\Demo2>path=c:\program files\java\jre1.8.0_66\bin;c:\program files\java\jdk1.7.0_07\bin

C:\project\tryCerts\Demo2>java -jar vendorCmd.jar acc03\acc03_ws_user accwbS3rv!ceS acc03_p_production
Dec 22, 2015 11:21:34 AM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser]  parse
INFO: WSP5018: Loaded WSIT configuration from file: jar:file:/C:/project/tryCerts/Demo2/vendorCmd/dist/vendorCmd.jar!/META-INF/wsit-client.xml.
logged in
Dec 22, 2015 11:21:35 AM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser]  parse
INFO: WSP5018: Loaded WSIT configuration from file: jar:file:/C:/project/tryCerts/Demo2/vendorCmd/dist/vendorCmd.jar!/META-INF/wsit-client.xml.
Signed Info:org.jcp.xml.dsig.internal.dom.DOMSignedInfo@3f071328
AccountNumber: 279105/ Firstname: null/ LastName: null
AccountNumber: 1005118/ Firstname: null/ LastName: COMPANY1
AccountNumber: 2102765/ Firstname: null/ LastName: COMPANY2
AccountNumber: 2101373/ Firstname: null/ LastName: COMPANY3
AccountNumber: 2119664/ Firstname: null/ LastName: COMPANY4
AccountNumber: 2119668/ Firstname: null/ LastName: ET CETERA

C:\project\tryCerts\Demo2>dir/s cacerts
 Volume in drive C is OS
 Volume Serial Number is 9896-211D
File Not Found

C:\project\tryCerts\Demo2>

This is exactly opposite from what I was expecting -- it is the cacerts file in the java 7 folders that has the vendor certificate chain, and java 8 that does not have it. Yet running the program on Java 7 fails with a certification error, and running it with 8 succeeds.

Can anyone tell me what I should look for to explain this?

arcy
  • 11,973
  • 8
  • 54
  • 89
  • 1
    You should run with `-Djavax.net.debug=all`, and actually see what the reported `trustStore is` (it's in the first 10 lines of the debug output) as to what it is using. – Petesh Dec 22 '15 at 16:54
  • Thanks! that confirms what I thought they were. Would still like to know why the one without the vendor certificate works and the one with the vendor certificate does not work. – arcy Dec 22 '15 at 17:01
  • I've no useful approaches here - generally I'd verify the vendor chain outside of Java and then check each element of the chain in the two Java trust stores; apart from that, no real ideas. – Petesh Dec 22 '15 at 17:06
  • @Petesh If you will please put your suggestion into an answer, I will accept it -- it answered the original question and led me to the overall answer. I dumped the output of both commands and compared them, and found a mention of a 'trusted certificate' in one that isn't in the other. I haven't worked out the details yet, but this looks like it. And what I originally asked was how to find out which cacert store was being used, which you did answer (and I should have thought of). – arcy Dec 22 '15 at 17:18

1 Answers1

9

To determine the trust store that's being used, without having to resort to tools like strace (linux) and process explorer (windows), you can pass the debug flag -Djavax.net.debug=ssl to the java command line, which dumps all the ssl related debug information (I mentioned all in the original comment, but that adds even more noise to the output):

java -Djavax.net.debug=ssl -jar vendorCmd.jar user1 password2 environment3

In the first 10ish lines of the debug output, will be a line:

trustStore is: <path to>cacerts

this indicates the trust store that's being used.

Wit the =ssl option, it also dumps all the trusted certs that are being added to the list of certs that are considered trusted by the JVM. This can be used to verify that the certs you think are in the trust store are actually in the trust store - in this case you should be able to see the vendor's certs in the list.

A full list of the debug options for javax.net.debug are detailed in the JSSE reference guide.

Petesh
  • 82,900
  • 3
  • 91
  • 111