Debugging javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Vertrauensanker für Zertifizierungspfad nicht gefunden

Question

Ich versuche a WebSocket client (unter Android) zu verwenden, um über einen sicheren wss eine Verbindung zu einem NGINX-Proxy herzustellen.

Ich habe zwei Server, einen im Intranet und einen AWS.

Wenn auf dem lokalen Server zu verbinden versuchen, scheitert die Verbindung mit einem javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

Wenn auf den Server, auf AWS Verbindungs ​​ich ein 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 Founderhalten, die zu erwarten ist, weil die NGINX Instanz auf AWS nicht gewesen konfiguriert, um das Protokoll zu wechseln und eine Verbindung zum Upstream-Websocket-Server herzustellen. Dies wird auf dem lokalen Server entwickelt. Aber das ist ein Hinweis darauf, dass TLS/SSL an AWS arbeitet, was für mich ausreicht.

Auch eine Verbindung zu ist erfolgreich und Nachrichten werden zurückgesendet.

Jetzt ist die seltsame Sache: Die NGINX-Instanz in AWS, die in einem Docker Container ausgeführt wird, hat die gleiche Codebasis wie die auf dem lokalen Computer. Bei beiden handelt es sich um NGINXs, die in einem Andock-Container ausgeführt werden, die Volumes werden auf die gleiche Weise mit sehr ähnlichen Konfigurationsdateien gemountet. Das einzige, was sich unterscheidet, ist der Domainname und die zugehörigen SSL-Zertifikate.

Das sind DV-Zertifikate von Comodo (Positive SSL). Ich habe auch LetsEncrypt-Zertifikate mit dem gleichen Ergebnis versucht.

Ich verstehe nicht, warum die beiden Behälter so unterschiedlich verhalten, und ich kann keinen Grund, die Schuld, die Server-Hosting der Docker Service (beide Ubuntu 14.04)

So will ich sezieren das finden Zertifikate (und ihre Kette) in der Android-Client-Anwendung.

Wie kann ich den Inhalt der Zertifikatskette drucken?

Chrome Browser JavaScript wss Verbindungen zum lokalen Server funktionieren, sowohl vom Android-Gerät als auch von PCs.

~~~~ aktualisieren ~~~~ Bitte antworten Sie nicht auf die Sachen unten, wie ich es in eine separate Frage gespalten wird

Ok, ich fortgeschritten mit Hilfe von @CommonsWare . Hier sind neue Fragen, die interessant werden.

Der Server im Intranet hostet ein selbstsigniertes Zertifikat als Catchall-HTTPS-Antwort. Die Logik dahinter ist, dass wenn jemand aus dem Internet die IP-Adresse der öffentlichen IP dieses Intranets über https://<IP-INTRANET-GATEWAY> besucht, wird es dieses Dummy-Zertifikat geliefert. Der Grund dafür ist, dass das Zertifikat für das Intranet nicht zurückgegeben werden sollte (https://intranet.example.com).

Mehrere Domain-Namen mit verschiedenen Zertifikaten verweisen auf diese IP-Adresse https://intranet.example.com, https://testing.intranet.example.com, so gibt es mehrere SSL-Zertifikate diente für diese IP-

In NGINX wäre es:

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/{ 
    ... 
    } 
} 

Dies ist ein Unterschied an den Server in AWS, auf dem kein selbstsigniertes Zertifikat vorhanden ist.

Eine Idee, warum der Client das Dummy-Zertifikat erhalten konnte?

Wie kann ich das Zertifikat auch ohne Ausnahme ausgeben, um beispielsweise das vom AWS-Server zurückgegebene Zertifikat (+ Kette) zu analysieren?

Eine einfache HttpURLConnection mit https funktioniert ohne Probleme.

Answer 1

getCause() auf die SSLHandshakeException gibt wahrscheinlich eine CertPathValidatorException, angesichts des Textes des Fehlers. Das hat eine getCertPath() Methode, die eine CertPath zurückgibt, die eine getCertificates() Methode hat, die die Kette darstellt. Bei Bedarf können diese Zertifikate in X509Certificate Objekte umgewandelt werden, die Ihnen eine Vielzahl von Details über das Zertifikat geben.

„Internet Widgits Pty Ltd“ und ich frage mich, warum die

Ich weiß es nicht, sondern eine Internet-Suche auf dieser Zeichenfolge klingt nicht viel versprechend serviert bekommen.