SNI clientseitiges Rätsel mit Java8

ch habe einen Apache-Webserver, auf dem mehrere TLS-Virtualhosts mit unterschiedlichen Zertifikaten und SNI ausgeführt werde

Ich kann auf die verschiedenen virtuellen Hosts problemlos per Curl zugreifen (vermutlich funktioniert das mit SNI). Ich kann sie auch problemlos mit einem kleinen Java-Kommandozeilenprogramm aufrufen, das im Grunde genommen nur openConnection () auf einer URL enthält.

In meiner Tomcat-Anwendung greift derselbe clientseitige Basiscode auf denselben Apache-Server wie ein Client zu, erhält jedoch immer das Standardzertifikat (defaulthost.defaultdomain) anstelle des Zertifikats des virtuellen Hosts, das in der angegebenen URL angegeben wurde es versucht zuzugreifen. (Dies führt zu einer SunCertPathBuilderException. Grundsätzlich kann der Zertifikatspfad zum Zertifikat nicht überprüft werden. Dies ist natürlich der Fall, da es sich um ein nicht offizielles Zertifikat handelt. Dann sollte das Standardzertifikat jedoch nicht verwendet werden.)

Es ist so, als wäre SNI in meiner Anwendung / in Tomcat clientseitig deaktiviert worden. Ich bin ratlos, warum es sich zwischen meiner App und der Befehlszeile anders verhalten sollte. gleiches JDK, gleicher Host etc.

Ich habe eine Immobilie gefundenjsse.enableSNIExtension, aber ich habe überprüft, dass es für beide Fälle auf true gesetzt ist. Fragen

Irgendwelche Ideen, auch wilde, warum sich diese beiden Programme unterschiedlich verhalten?

Haben Sie eine Idee, wie ich das debuggen würde?

Dies ist Arch Linux unter 86_64, JDK 8u77, Tomcat 8.0.32.

Antworten auf die Frage(4)

Ihre Antwort auf die Frage