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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
Exploring ASP.NET Core: Fundamentals

Learn to build web apps and services, IoT apps, and mobile backends by covering the fundamentals of ASP.NET Core and  exploring the core foundations for app libraries.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.