Java error: Trust anchor for certification path not found. - REDUX

Solar2D Network
#1

Hello @everyone.  I am in the beginning part of a debug effort and wanted to post in case anyone here has also seen and solved this issue.

Summary:

I am working on an app for a client that requires me to reach out to their server to get content.  Their server is secured (https) with an SSL cert.

In short, while I can run all the tests and interactions I want from my Windows desktop using the app in the simulator, once I run it on my Android device I get this error:

ERROR: network: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.: https://www.fanpoweredmusic.ne t/api/public/v1/token (javax.net.ssl.SSLHandshakeException)

This is the code that causes the problem:

https://github.com/roaminggamer/RG_FreeStuff/raw/master/ForumsImages/2018/certException.zip

local function listener(event) for(k,v) in pairs(event) do print(k,v) end end local request = { timeout = 30, headers = { Authorization = "Basic fakeToken"} } -- FYI: Fails for real token too. local urlString = 'https://www.fanpoweredmusic.net/api/public/v1/token' network.request( urlString, "POST", listener, request )

Steps Taken So Far:

  1. I have searched this site and found a similar post but with no resolution:

https://forums.coronalabs.com/topic/62706-java-error-trust-anchor-for-certification-path-not-found/

  1. I did follow the advice in the above thread, and it turns out there may be a problem with the server.  However, I’m pressing forward with the debugging till I hear back from the client’s server guy.

Possible Issues:

The server is not sending the required intermediate certificate.

Outdated Protocol Support

  1. Other reading on the WWW, but nothing so far.

Other Ideas:

I’m going to build and test on my iOS device when time permits (this is a slow path for me), but I expect the problem to still be present.

What I’m Looking For:

Basically, I’m hoping some guru out there has seen and solved this, but all insights are welcome.

I’ll post back when I resolve this and put some details on the actual resolution.

#2

It is definitely server SSL related and nothing you can do will resolve this IMHO.

Their insecure root cert expired ages ago

 Sat, 10 Dec 2016 19:24:23 UTC (expired 1 year and 3 months ago) EXPIRED

https://www.ssllabs.com/ssltest/analyze.html?d=www.fanpoweredmusic.net

#3

Thanks, and good eye! 

That is probably it.  They’re in dev and updating stuff on their server so my guess is this will self resolve soon.

I’ll ping them!

I’ll also post back when this is resolved just to tie a bow on it.

#4

I’m still working on this.

While I try to work this out with the site admin, I’m wondering if there is any way to make the network.* calls more forgiving.

So far, the ONLY place they work is in the simulator on Windows 10.  All other targets and the simulator on OS X get an error.

So, if you have any ideas for bypassing this, please feel free to write them below.

Meanwhile, debugging continues.

#5

Hello again.  I’ve resolved this and wanted to check-in with what I learned.

Certificates

We ended up bypassing this problem by using the client’s production server which is much more up-to-date with regards to certificates and standards.

That said, I am 99% that a protocol error devolved us to the no SNI case which then passed back the second certificate.  This second certificate was no longer valid.  So, any attempts to use it failed.

The solution would (IMHO) have been to edit the server files and remove the bad certificate.  However, as noted, we skipped this.

Requests and Assumptions About Defaults

Soon after, I learned a lesson (again) about assuming things.

Once I got past the initial handshake I found logins from Windows worked, but all devices and OS X failed.  

Investigation showed that in the failed cases, the body was empty.

Further investigation showed, that on Windows, the header was given a default mime content type of ‘application/x-www-form-urlencoded’.  In all other cases, no type was given.

The solution of course was the apply the type myself, and violla back in business:

 local headers = {} headers["Content-Type"] = "application/x-www-form-urlencoded"
#6

It is definitely server SSL related and nothing you can do will resolve this IMHO.

Their insecure root cert expired ages ago

 Sat, 10 Dec 2016 19:24:23 UTC (expired 1 year and 3 months ago) EXPIRED

https://www.ssllabs.com/ssltest/analyze.html?d=www.fanpoweredmusic.net

#7

Thanks, and good eye! 

That is probably it.  They’re in dev and updating stuff on their server so my guess is this will self resolve soon.

I’ll ping them!

I’ll also post back when this is resolved just to tie a bow on it.

#8

I’m still working on this.

While I try to work this out with the site admin, I’m wondering if there is any way to make the network.* calls more forgiving.

So far, the ONLY place they work is in the simulator on Windows 10.  All other targets and the simulator on OS X get an error.

So, if you have any ideas for bypassing this, please feel free to write them below.

Meanwhile, debugging continues.

#9

Hello again.  I’ve resolved this and wanted to check-in with what I learned.

Certificates

We ended up bypassing this problem by using the client’s production server which is much more up-to-date with regards to certificates and standards.

That said, I am 99% that a protocol error devolved us to the no SNI case which then passed back the second certificate.  This second certificate was no longer valid.  So, any attempts to use it failed.

The solution would (IMHO) have been to edit the server files and remove the bad certificate.  However, as noted, we skipped this.

Requests and Assumptions About Defaults

Soon after, I learned a lesson (again) about assuming things.

Once I got past the initial handshake I found logins from Windows worked, but all devices and OS X failed.  

Investigation showed that in the failed cases, the body was empty.

Further investigation showed, that on Windows, the header was given a default mime content type of ‘application/x-www-form-urlencoded’.  In all other cases, no type was given.

The solution of course was the apply the type myself, and violla back in business:

 local headers = {} headers["Content-Type"] = "application/x-www-form-urlencoded"