2016-07-21 10 views
0

Ich verwende einen REST-Dienst auf Wildfly 9 unter Verwendung von https mit einem selbstsignierten Zertifikat unter Verwendung dieser configuration.Trikotfehler zum Herstellen einer Verbindung zum Dienst unter Verwendung von HTTPS unter Java 6

die ssl Überprüfung umgehen ich diesen Code bin mit:

public static Client createIgnoreSSLClient() { 
    ClientConfig clientConfig = new ClientConfig(); 
    clientConfig.connectorProvider(new HttpUrlConnectorProvider()); 
    SSLContext sslcontext; 
    try { 
     sslcontext = SSLContext.getInstance("SSL"); 
     sslcontext.init(null, new TrustManager[]{new X509TrustManager() { 
      public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {} 
      public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {} 
      public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; } 

     }}, new java.security.SecureRandom()); 
    } catch (Exception e) { 
     throw new RuntimeException(e); 
    } 
    return ClientBuilder.newBuilder() 
      .sslContext(sslcontext) 
      .hostnameVerifier(createDummyHostnameVerifier()) 
      .withConfig(clientConfig) 
      .build(); 
} 

Ich verwende Jersey 2.6 Kompatibilität zu halten mit Java 6 (Einige Anwendungen sind in Jboss laufen 4).

<dependency> 
    <groupId>org.glassfish.jersey.core</groupId> 
    <artifactId>jersey-client</artifactId> 
    <version>2.6</version> 
</dependency> 

<dependency> 
    <groupId>org.glassfish.jersey.media</groupId> 
    <artifactId>jersey-media-moxy</artifactId> 
    <version>2.6</version> 
</dependency> 

Alles funktioniert mit feinen Java 8 und 7. Mit Java 6 Ich erhalte diese Fehlermeldung:

21/07/2016 16:38:36 org.glassfish.jersey.client.ClientRequest writeEntity 
SEVERE: Error while committing the request output stream. 
javax.net.ssl.SSLException: Received fatal alert: unexpected_message 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190) 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1682) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) 
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) 
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) 
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:904) 
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230) 
    at org.glassfish.jersey.client.HttpUrlConnector$3.getOutputStream(HttpUrlConnector.java:312) 
    at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200) 
    at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:194) 
    at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:262) 
    at org.glassfish.jersey.message.internal.OutboundMessageContext.commitStream(OutboundMessageContext.java:812) 
    at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:543) 
    at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:315) 
    at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:227) 
    at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:225) 
    at org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:671) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:228) 
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:423) 
    at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:667) 
    at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:423) 
    at org.glassfish.jersey.client.JerseyInvocation$Builder.put(JerseyInvocation.java:311) 
    at com.oki.casi.client.TesteLogin.testeLoginHttps(TesteLogin.java:79) 
    at com.oki.casi.client.TesteLogin.main(TesteLogin.java:58) 
Exception in thread "main" javax.ws.rs.WebApplicationException: HTTP 500 Internal Server Error 
    at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.writeTo(MOXyJsonProvider.java:810) 
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:263) 
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) 
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) 
    at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1154) 
    at org.glassfish.jersey.client.ClientRequest.writeEntity(ClientRequest.java:500) 
    at org.glassfish.jersey.client.HttpUrlConnector._apply(HttpUrlConnector.java:315) 
    at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:227) 
    at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:225) 
    at org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:671) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297) 
    at org.glassfish.jersey.internal.Errors.process(Errors.java:228) 
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:423) 
    at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:667) 
    at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:423) 
    at org.glassfish.jersey.client.JerseyInvocation$Builder.put(JerseyInvocation.java:311) 
    at com.oki.casi.client.TesteLogin.testeLoginHttps(TesteLogin.java:79) 
    at com.oki.casi.client.TesteLogin.main(TesteLogin.java:58) 
Caused by: javax.xml.bind.MarshalException 

Edit: Ich versuche, dieses Problem Testen der Client den Zugriff auf zwei Servern zu lösen, Jboss 7.1 .1 und Wildfliege 9.0.2.

In Jboss 7 kann ich mit https macht Client arbeitet Protokoll von TLSv1 zu SSL Wechsel:

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> 
    <ssl name="ciac-ssl" key-alias="ciac-cert" password="123456" certificate-key-file="../standalone/configuration/ciac-cert.keystore" protocol="SSL"/> 
</connector> 

Wie kann ich diese Konfiguration in Wildfly ändern?

+0

* Alles funktioniert gut mit Java 8 und 7. Mit Java 6 ... * ** _ Wait! _ Warum verwenden Sie Java 6 noch im Jahr 2016? ** [Die öffentlichen Updates für Java 6 wurden im Februar 2013 beendet und die öffentliche Updates für Java 7 wurden im April 2015 beendet] (http://www.oracle.com/technetwork/java/eol-135779.html#lts). –

+0

@ CássioMazzochiMolin Es gibt eine Anwendung in Jboss 4. –

+1

* Wie kann ich diese Konfiguration in Wildfly ändern? * Schauen Sie [hier] (https://docs.jboss.org/author/pages/viewpage.action?pageId = 66322705) und [hier] (http://reallifejava.com/configuring-ssl-in-wildfly-8/). –

Antwort

1

Wenn ich richtig verstehe, erhalten Sie die SSLException in Ihrer Client-Anwendung, die unter Java 6 ausgeführt wird. In diesem Client versuchen Sie auf einen Service auf Wildfly 9, die Java 7 oder höher verwendet. Dies bedeutet, dass der Server einen anderen Sicherheitsmechanismus verwendet. I stumbled upon the same earlier und wie Sie sehen können, gibt es auch keine Schlussfolgerung zu diesem Beitrag.

Und es macht Sinn, wenn Sie darüber nachdenken, warum es dem Entwickler ermöglichen, Dienste zu erstellen, die veraltete und unsichere Sicherheitsmechanismen verwenden?

Schließlich entschieden wir uns, mit einem JDK-Update zu gehen. Sie könnten auch versuchen, JBoss 4 unter JDK7 zu hosten. Zum Beispiel here können Sie einige interessante Schriften zu diesem Thema finden.

Verwandte Themen