42

I have been struggling for almost one week to get my applications up running after moving my applications from Windows 2000 to Windows 2008 R2 Server.

The procedure:

  1. Installed Java JDK 1.7.0_25
  2. Set system environment variable JAVA_HOME to C:\Progra~1\Java\jdk1.7.0_25\
  3. Imported the certificate into cacerts with keytool
  4. Ensured that the certificate exists in keytool with -list.

I have tried to repeat step 3 with InstallCert to ensure that i havent messed anything up.

The above methods did not solve my problem, so i tried to do it programmatically:

System.setProperty("javax.net.ssl.trustStore", "C:/Progra~1/Java/jdk1.7.0_25/jre/lib/security/cacerts"); System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Still without any luck. I am stuck and not quite sure which direction to go from here.

Stack trace:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868) at sun.security.ssl.Handshaker.process_record(Handshaker.java:804) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) at util.SMS.send(SMS.java:93) at domain.ActivationSMSSenderMain.sendActivationMessagesToCustomers(ActivationSMSSenderMain.java:80) at domain.ActivationSMSSenderMain.<init>(ActivationSMSSenderMain.java:44) at domain.ActivationSMSSenderMain.main(ActivationSMSSenderMain.java:341) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) at sun.security.validator.Validator.validate(Validator.java:260) at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323) ... 14 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380) ... 20 more

UPDATE:

Both System.out.println(System.getProperty("javax.net.ssl.trustStore")); and System.out.println(System.getProperty("javax.net.ssl.keyStore"));

returns null.

Improve this question
10
  • have you added your intermediate certs? Commented Aug 22, 2013 at 11:28
  • Im not quite sure which you mean, but i haven't touched the default certificates in cacerts. Commented Aug 22, 2013 at 11:29
  • intermediate cert refers to your cert issuer. if your cert issuer is not trusted, your cert is also untrusted. for example, to authenticate google.com, you will also need to add Google Internet Authority and GeoTrust to truststore. Commented Aug 22, 2013 at 11:36
  • So if i open the Certification path in Chrome, i see a tree structure Geotrust Global CA -> RapidSSL CA -> *.thedomain.com. I need to add the two first aswell? Commented Aug 22, 2013 at 11:47
  • yes, they are required. Commented Aug 22, 2013 at 11:48

6 Answers 6

Reset to default
40

I ran into similar issues whose cause and solution turned out both to be rather simple:

Main Cause: Did not import the proper cert using keytool

NOTE: Only import root CA (or your own self-signed) certificates

NOTE: don't import an intermediate, non certificate chain root cert

Solution Example for imap.gmail.com

  1. Determine the root CA cert: 

    openssl s_client -showcerts -connect imap.gmail.com:993

    in this case we find the root CA is Equifax Secure Certificate Authority

  2. Download root CA cert.
  3. Verify downloaded cert has proper SHA-1 and/or MD5 fingerprints by comparing with info found here

  4. Import cert for javax.net.ssl.trustStore: 

    keytool -import -alias gmail_imap -file Equifax_Secure_Certificate_Authority.pem
  5. Run your java code
Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

In case you have many JRE installed, you can specify the keystore you want to import the certificate adding -keystore path/to/jre/lib/security/cacerts to the command in the step 4.
10

You've imported the certificate into the truststore of the JRE provided in the JDK, but you are running the java.exe of the JRE installed directly.

EDIT

For clarity, and to resolve the morass of misunderstanding in the commentary below, you need to import the certificate into the cacerts file of the JRE you are intending to use, and that will rarely if ever be the one shipping inside the JDK, because clients won't normally have a JDK. Anything in the commentary below that suggests otherwise should be ignored as not expressing my intention here.

A far better solution would be to create your own truststore, starting with a copy of the cacerts file, and specifically tell Java to use that one via the system property javax.net.ssl.trustStore.

You should make building this part of your build process, so as to keep up to date with changes I the cacerts file caused by JDK upgrades.

Improve this answer

9 Comments

Yes, because you've imported the certificate into one truststore and you're using another one. Do read the answer.
EJP, i think i understand now. But i have tried to initialize the certificates into cacerts aswell, without any difference.
@JavaCake every JRE has a cacerts keystore. What EJP is saying to you, is to make sure that when you run the program the JRE of the JDK (with the cacerts where the certificate is imported) is used and not some other JRE installed in your machine. Use System.getProperty("java.runtime.version") to check if this is actually the case
@EJP I have not suggested to change the JRE. I have just elaborated on your answer
@c.s. You wrote, and I quote: 'make sure that when you run the program the JRE of the JDK (with the cacerts where the certificate is imported) is used and not some other JRE installed in your machine'. I really should not have to quote your own words at you.
|
3

If you are using Eclipse just cross check in Eclipse Windows--> preferences---->java---> installed JREs is pointing the current JRE and the JRE where you have configured your certificate. If not remove the JRE and add the jre where your certificate is installed

Improve this answer

Comments

0

Per your pastebin, you need to add the proxy.tkk.com certificate to the truststore.

Improve this answer

5 Comments

Do you know how i can retrieve the certificate for proxy.tkk.com? This is a local proxy. I assumed that InstallCert handled all certificate dependencies.
If all of your connections are going through an SSL-inspecting proxy, you'll need the generic certificate which is signing all of the pseudo-certs for the sites visited. This is likely installed in the browser trust stores, or you should be able to get it from the proxy admin. If you're not going through the proxy for these connections, you simply need to get the 'correct' certificate for the sites you're trying to trust, which appear to be issued by RapidSSL and not proxy.tkk.com. The server admins can provide these, or you can get them from outside the proxy environment.
In my other web based applications that do not require SSL i need to use the proxyHost parameter to get access, but that is not enough in this case i assume.
Ahhhh, and you are not doing so here? That is, are you going around the proxy to make this connection?
Without the proxyHost parameter i get a HTTP 407.
0

On Windows you can try these steps:

  1. Download a root CA certificate from the website.
  2. Find a file jssecacerts in the directory /lib/security with JRE (you can use a comand System.out.println(System.getProperty("java.home"); to find the folder with the current JRE). Make a backup of the file.
  3. Download a program portecle.
  4. Open the jssecacerts file in portecle.
  5. Enter the password: changeit.
  6. Import the downloaded certificate with porticle (Tools > Import Trusted Certificate).
  7. Click Save.
  8. Replace the original file jssecacerts.
Improve this answer

Comments

-2

In my case the issue was resolved by installing Oracle's official JDK 10 as opposed to using the default OpenJDK that came with my Ubuntu. This is the guide I followed: https://www.linuxuprising.com/2018/04/install-oracle-java-10-in-ubuntu-or.html

Improve this answer

1 Comment

It's not the real solution. OpenJDK just works. Abusing the word "official" doesn't help. OpenJDK has been the reference implementation of Java for years (since Java 7 as far as I remember). Your problem was probably elsewhere.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.