Daniel F Daniel F - 5 months ago 144
Android Question

Debugging javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found

I'm trying to use a WebSocket client (on Android) to connect to an NGINX proxy via secure wss.

I have two servers, one in the intranet and one AWS.

When trying to connect to the local server, the connection fails with a

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.


When connecting to the server on AWS I get a
com.neovisionaries.ws.client.OpeningHandshakeException: The status code of the opening handshake response is not '101 Switching Protocols'. The status line is: HTTP/1.1 404 Not Found
which is to be expected because the NGINX instance on AWS has not been configured to switch the protocol and connect to the upstream websocket server. This is being developed on the local server. But this is an indication that TLS/SSL is working on AWS, which is enough for me.

Also, a connection to
wss://echo.websocket.org
succeeds and messages are getting echoed back.

Now, here's the odd thing: The NGINX instance on AWS, which runs inside a docker container, has the same codebase as the one on the local machine. Both are NGINXs running in a docker container, the volumes mounted the same way, with very similar configuration files. The only thing that differs is the domain name and the associated SSL certificates.

Those are DV certificates from Comodo (Positive SSL). I've also tried LetsEncrypt certificates with the same result.

I don't understand why the two containers behave so differently, and I can't find a reason to blame the servers hosting the docker service (both Ubuntu 14.04)

So I'm wanting to dissect the certificates (and their chain) in the Android client application.

How can I print the contents of the certificate chain?

Chrome Browser JavaScript wss connections to the local server do work, from the Android device as well as from PCs.

~~~~ Update ~~~~

Ok, I progressed with the help from @CommonsWare. Here are new questions, which start getting interesting.

The server in the intranet hosts a self-signed certificate as a catchall https response. The logic behind it is that if someone from the internet visits the IP address of the public IP of that intranet via https://<IP-INTRANET-GATEWAY>, it gets served that dummy certificate. The reason for this is that it should not return the certificate for the intranet (https://intranet.example.com).

Several domain names with different certificates point to that IP address https://intranet.example.com, https://testing.intranet.example.com, so there are multiple SSL certificates served for this IP

In NGINX it would be:

server {
listen 443;
server_name _;
ssl on;
ssl_certificate /etc/nginx/self-signed-dummy.pem;
ssl_certificate_key /etc/nginx/self-signed-dummy.key;
location / {
return 404;
}
}

server {
listen 443;
server_name intranet.example.com;
ssl on;
ssl_certificate /etc/nginx/intranet.example.com.pem;
ssl_certificate_key /etc/nginx/intranet.example.com.key;
location / {
...
}
}

server {
listen 443;
server_name testing.intranet.example.com;
ssl on;
ssl_certificate /etc/nginx/testing.intranet.example.com.pem;
ssl_certificate_key /etc/nginx/testing.intranet.example.com.key;
location / {
...
}
}


This is a difference to the server on AWS, which has no self-signed certificate on it.

Any idea why the client could get served the dummy certificate?

Also, how can I dump the certificate whithout an exception, for example in order to analyze the certificate (+chain) returned by the AWS server?

Answer

getCause() on the SSLHandshakeException probably returns a CertPathValidatorException, given the text of the error. That has a getCertPath() method, which returns a CertPath, which has a getCertificates() method representing the chain. If needed, those certificates should be able to be cast to X509Certificate objects, which give you a variety of details about the cert.

"Internet Widgits Pty Ltd" and I wonder why that is getting served

I don't know, but an Internet search on that string does not sound promising.

Comments