Fehler beim Apache CXF-Client beim Testen des Servers, der Server Name Indication (SNI) benötigt

8

Wir hatten einen Client, der mit Apache CXF erstellt wurde und mit einem bestimmten Server funktionierte (zB: Ссылка ).

Aber der Server ist zu einer anderen IP gewechselt, und jetzt hat er zwei SSL-Zertifikate mit TLS und SNI (Server Name Indication) in der gleichen IP, und jetzt schlagen unsere Anwendungen mit diesem Fehler fehl:

%Vor%

Ich verstehe, dass dies der Fall ist, wenn https das falsche Zertifikat erhält (es hat einen anderen Servernamen) und stimmt daher nicht mit meinem überein.

Ich habe versucht, herauszufinden, was mit openssl passiert, und die URL funktioniert nur, wenn ich servername:

%Vor%

Der Fehler ist in diesem Punkt im generierten Apache-Client aufgetreten:

%Vor%

schlägt im neuen Operation_Service fehl:

%Vor%

javax.xml.ws.Service ruft javax.xml.ws.spi.ServiceDelegate auf, eine Klasse abastract, die von einer Klasse in org.apache.cxf.jaxws implementiert wird. Aber hier verliere ich sie weiß was zu sehen ...

Unser Client läuft in Java 7.0 mit Apache Cxf 3.0.4 auf einem Weblogic 12.1.1.0. Ich habe gelesen, dass es in Java 6 Probleme mit SNI gab, aber wir verwenden hier 7.0.

Ich weiß nicht, was ich tun kann. Gibt es eine Option in Java oder in unserem Client, um den Servernamen (wie in openssl) anzugeben, mit dem wir uns verbinden möchten?

    
Aitor 11.09.2015, 12:07
quelle

2 Antworten

4

Es ist eine Kombination von "Verbesserungen" in JDK 1.8 und der Tatsache, dass der Server mehrere Zertifikate hat.

Was in JDK 1.8 gebrochen ist, wird hier erklärt: Ссылка

Es geht so:

  • Es wird keine SNI-Erweiterung aufgrund eines Fehlers Ссылка gesendet.
  • Der Server gibt das Zertifikat "CN = otherserver.com" zurück, das wahrscheinlich auch SAN (SubjectAlternativeName) "otherserver.com" und kein anderes hat.
  • Die standardmäßigen URL-Spoofing-Prüfungen in JDK werden durchgeführt und vergleichen "serverexample.com" mit der URL und "otherserver.com" mit dem Zertifikat. Hoppla, du bekommst deine Ausnahme.

Die einfachste Korrektur besteht darin, alle WSDL- und XSD-Dateien herunterzuladen und sie irgendwo in Ihrem jar zu packen.

Wenn Sie wirklich die WSDL vom Remote-Server abrufen müssen, könnte dies hilfreich sein:

final URL wsdlURL = neue URL ("https: // andererserver.com / application / webservice? wsdl");

Dies funktioniert jedoch möglicherweise nicht, da "/ application / webservice" möglicherweise nur für serveexample.com bekannt ist. In diesem Fall erhalten Sie die TLS-Verbindung und dann den HTTP 404-Antwortcode.

Wenn das nicht funktioniert, müssen Sie auf alle Arten von SSL-Fabriken zurückgreifen (was ausführlich aber sicher möglich ist) und versucht, sie in javax.ws .... -Klassen einzubinden (was möglich sein sollte, aber nie getan diesen Teil).

    
user568826 13.10.2015, 07:32
quelle
0

hoffe, dass dies für Sie hilfreich ist:

für die Auflösung der SSL-Handshake-Ausnahme können Sie auf zwei Arten wählen: setze diese Systemeigenschaft am Anfang deines Codes:

System.setProperty("jsse.enableSNIExtension", "false");

oder

Legen Sie das VM-Argument für Ihr Programm wie folgt fest: -Djsse.enableSNIExtension=false

    
pinokio 20.09.2015 08:05
quelle

Tags und Links