Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 687
  • Last Modified:

https: Unable to find valid certification path to requested target

To connect to an https domain I use the following code:
      //uri is a string containing the server https domain address
      URL urlGift = new URL("https://" + uri + ":443/process.cgi");
      HttpsURLConnection conn = (HttpsURLConnection) urlGift.openConnection();
      OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());

      // Get the response
      BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
      String res = "";
      String line;
      while ( (line = rd.readLine()) != null) {
        res += line;
      return res;
If I add our certificate (.cer) to my cacerts it works fine, but I'm assuming that since our certificate was signed by GoDaddy (up there must reach a CA that presumably is in my cacerts). Nevertheless I keep getting this error: PKIX path building failed: unable to find valid certification path to requested target.
I'm thinking that this is not very different from having a self-signed certificate. One it expires we will have to add the new one to cacerts and distribute it to 100's of users, which is what we want to avoid.
In short, I want to know why the connection is not able to go "up the chain" of certificates to trust the certificate we have.
I know I can create my own trust manager and accept whatever I want. But then what's the point of having a signed certificate by a CA?
Any takers?
  • 5
  • 4
1 Solution
In short, I want to know why the connection is not able to go "up the chain" of certificates to trust the certificate we have.

Possibly because you haven't added ALL the certs required to form that chain. Check with GoDaddy as to what you should be doing with what they supply
check following interesting explanation, link
RNMisrahiAuthor Commented:
Thanks CEHJ.
I understand what you're saying, but the way I understand it, we shouldn't need to have the whole chain of trust in our cacerts but only the root certificate. Just as a browser will trust Certificate A if it was signed by Certificate B, which was signed by Certificate C, which I trust because it's in my list of trusted certificates. I.e. a browser doesn't have the chain of every certificate. It'd be an enormous list.
In our case, our certificate is signed by:
GeoTrus DV SSL which is signed by GeoTrust Global CA.

I find it very strange that I have to add any of these intermediate certificates. Again, a browser does recognize it as a safe server because as far as I understand, the chain leads to one of the trusted certificates. Moreover, I have a C# and a Delphi application that communicate with this same site and it doesn't require me to add anything.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Is that your server you're trying to connect to?
RNMisrahiAuthor Commented:
Yes, this is my server. We have a few hundred users. We used to have a certificate of a different type that's expiring soon.
So we bought this certificate that has a path from GeoTrust Global to GeoTrust DV SSL to our actual certificate.
RNMisrahiAuthor Commented:

I've listed the cacerts and I can see there what's expected:

The original cacerts (before I import anything) has the GeoTrust Global CA but NOT the GeoTrust DV SSL.
Our certificate is signed by GeoTrust DV SSL, which is signed by GeoTrust Global CA.
Again, I would expect Java to "see" our certificate, signed by DV SSL, which signed by Global CA, which is on our cacerts.

It doesn't surprise me that when I add DV SSL to cacerts our certificate is accepted, since DV SSL signs our certificate. This is as if Java is able to only one step up the chain!

There must be a way to tell HttpsURLConnection to keep going up the chain more than one step.
CEHJCommented: shows something similar to what i guessed: no fewer than 4 certs needing to be imported
RNMisrahiAuthor Commented:
CEHJ, could you expand a bit on this?

What does it mean in practice:
Do we need to change the cacerts of our users when the Secondary Certificate (DV SSL) expires? Why can't we rely on the Primary (Global CA) which expires in 20 years?

And so we understand:
Why a browser can go up the chain of signed certificates to the root and Java can go only one certificate up?

I'm ready to assign all points as soon as we get an answer.

My guess for the first question is yes. But you need to check with GoDaddy. You need to understand that i work for free here, which is one thing, but quite another to be working for free for GoDaddy too (i assume you paid them for this certification?)

The answer to the last question (and by extension to the one preceding it) is that browsers are probably able to import chains whereas java is able only to work on single entities
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now