1. Zuhause
  2. Frage und Antwort
  3. Umgehung der Zertifikatsüberprüfung mit SSLSocketFactory

Umgehung der Zertifikatsüberprüfung mit SSLSocketFactory

2016-07-18 10 views
-1

Ich erstelle eine clientseitige Anwendung, die über eine Soap-Nachricht eine Verbindung mit einem Server eines Drittanbieters herstellt. Ich benutze jax-ws 2.1.9 und jdk 1.6_18, die auf JBoss 4.2.3 laufen.Umgehung der Zertifikatsüberprüfung mit SSLSocketFactory

Das Problem selbst ist, dass der Server, der nur für Testzwecke konfiguriert ist, ein abgelaufenes Zertifikat zurückgibt, und daher wirft meine Anwendung die Ausnahme unten.

13:43:26,738 ERROR [STDERR] Caused by: javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message 
13:43:26,739 ERROR [STDERR]  at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:404) 
13:43:26,739 ERROR [STDERR]  at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:314) 
13:43:26,739 ERROR [STDERR]  at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172) 
13:43:26,739 ERROR [STDERR]  at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152) 
13:43:26,739 ERROR [STDERR]  at $Proxy724.solicitarBaixaOperation(Unknown Source) 
13:43:26,740 ERROR [STDERR]  at com.totvs.foundation.exchange.connector.ptu.implementation.v70_batch.InvoiceWriteOffConnector.process(InvoiceWriteOffConnector.java:91) 
13:43:26,740 ERROR [STDERR]  ... 98 more 
13:43:26,740 ERROR [STDERR] Caused by: java.io.IOException: Could not transmit message 
13:43:26,740 ERROR [STDERR]  at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:255) 
13:43:26,740 ERROR [STDERR]  at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:73) 
13:43:26,741 ERROR [STDERR]  at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:339) 
13:43:26,741 ERROR [STDERR]  at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:302) 
13:43:26,741 ERROR [STDERR]  ... 102 more 
13:43:26,741 ERROR [STDERR] Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker. java.security.cert.CertificateExpiredException: NotAfter: Thu Sep 11 09:35:00 GMT-03:00 2014. 
13:43:26,741 ERROR [STDERR]  at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:348) 
13:43:26,742 ERROR [STDERR]  at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:137) 
13:43:26,742 ERROR [STDERR]  at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) 
13:43:26,742 ERROR [STDERR]  at org.jboss.remoting.Client.invoke(Client.java:1634) 
13:43:26,742 ERROR [STDERR]  at org.jboss.remoting.Client.invoke(Client.java:548) 
13:43:26,742 ERROR [STDERR]  at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:233) 
13:43:26,743 ERROR [STDERR]  ... 105 more 
13:43:26,743 ERROR [STDERR] Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Thu Sep 11 09:35:00 GMT-03:00 2014 
13:43:26,743 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) 
13:43:26,743 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611) 
13:43:26,744 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187) 
13:43:26,744 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181) 
13:43:26,744 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1035) 
13:43:26,744 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124) 
13:43:26,744 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516) 
13:43:26,745 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454) 
13:43:26,745 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884) 
13:43:26,745 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112) 
13:43:26,745 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139) 
13:43:26,745 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) 
13:43:26,746 ERROR [STDERR]  at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) 
13:43:26,746 ERROR [STDERR]  at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) 
13:43:26,746 ERROR [STDERR]  at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:904) 
13:43:26,746 ERROR [STDERR]  at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230) 
13:43:26,746 ERROR [STDERR]  at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:277) 
13:43:26,747 ERROR [STDERR]  ... 110 more 
13:43:26,747 ERROR [STDERR] Caused by: java.security.cert.CertificateExpiredException: NotAfter: Thu Sep 11 09:35:00 GMT-03:00 2014 
13:43:26,747 ERROR [STDERR]  at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:256) 
13:43:26,747 ERROR [STDERR]  at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:570) 
13:43:26,747 ERROR [STDERR]  at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134) 
13:43:26,748 ERROR [STDERR]  at sun.security.validator.Validator.validate(Validator.java:218) 
13:43:26,748 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126) 
13:43:26,748 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209) 
13:43:26,748 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249) 
13:43:26,748 ERROR [STDERR]  at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1014) 
13:43:26,749 ERROR [STDERR]  ... 122 more

Also, zu Testzwecken versuche ich diese Validierungen zu umgehen. Ich habe einige Blogs und Beiträge gefunden, die mich alle zum unten stehenden Codeausschnitt geführt haben.

/** 
Inner class for set a blind TrustManager 
**/ 
public class BlindTrustManager implements X509TrustManager { 
    public X509Certificate[] getAcceptedIssuers() { 
     return new X509Certificate[0]; 
    } 
    public void checkClientTrusted(X509Certificate[] chain, String authType) 
      throws CertificateException { 
    } 
    public void checkServerTrusted(X509Certificate[] chain, String authType) 
      throws CertificateException { 
    } 
} 

/*Get the port instance of the web service interface created by JAX-WS*/ 
SolicitarBaixaPortType port = InvoiceWriteOffWebService.getInstance(serviceName, wsdlLocation); 

/*set the socket factory*/ 
SSLContext ctx = SSLContext.getInstance("TLSv1"); 
      ctx.init(null, new TrustManager[] { new BlindTrustManager() }, null); 
      SSLSocketFactory sslSocketFactory = ctx.getSocketFactory(); 
      ((BindingProvider) port).getRequestContext().put(BindingProviderProperties.SSL_SOCKET_FACTORY, sslSocketFactory); 
((BindingProvider) port).getRequestContext().put(com.sun.xml.internal.ws.client.BindingProviderProperties.SSL_SOCKET_FACTORY, sslSocketFactory); 

/*message is the Object Jax generated*/ 
response = port.solicitarBaixaOperation(message);

Obwohl ich die SSLSocketFactory die CertificateExpiredException gesetzt hatte, noch werfen wird. So wirft es die folgenden Fragen:

  1. Bin ich es richtig zu machen?
  2. Wie kann ich sicher sein, dass die Verbindung meine BlindTrustManager Klasse sieht? Denn ich kann keine Erwähnung davon auf dem Baumstamm sehen.
  3. Wie kann ich sicher der richtige String sein, die ich meinen BindingProvider Anforderungskontext übergeben müssen es meine SSLSocketFactory finden kann?
  4. Gibt es eine andere Konfiguration, die ich in JBoss tun muss?

Dank

Quelle

2016-07-18 Eduardo Dani

+0

'Für Testzwecke' schlägt immer die Angst vor Gott in mich. Die eigentliche Frage ist, warum ist das Zertifikat abgelaufen? Das Schreiben von "zu Testzwecken" Code, um dies zu umgehen, ist nur eine Möglichkeit, den "Testzweck" -Code in die Produktion zu verlagern, wo er jahrelang ungeprüft und unsicher bleiben wird. Das Problem lösen*. Behandle nicht nur das Symptom. – EJP

+0

Ich stimme Ihnen zu, dass dies das Problem nicht löst, aber das Zertifikat ist abgelaufen, weil der Besitzer des Webdienstes es nicht in seiner Testumgebung repariert. Wie ich bereits sagte, ist es ein Dienst von Drittanbietern, zu dem ich mich nicht einmischen kann. Gibt es eine Möglichkeit, dieses Problem ohne Eingriff des Eigentümers zu lösen? –

Antwort

0

Das ist eine Vermutung, wie ich mit dem Rahmen nicht vertraut bin, aber wenn Jboss verwendet url.openConnection() dann denke ich, Sie die JVM weiten Standard

einstellen müssen 
javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(sslSocketFactory);

nb Dies könnte weitere Auswirkungen haben, und vielleicht könnten Sie dieses Zertifikat speziell auf die weiße Liste setzen, wenn dies funktioniert.

Quelle

2016-07-19 08:55:42

Verwandte Themen

 Verwandte Themen