example consumir consume java ssl webservice-client

consumir - java web service client certificate authentication example



javax.net.ssl.SSLHandshakeException: el host remoto cerró la conexión durante el protocolo de enlace durante la comunicación del servicio web (19)

Aún no es una respuesta, pero es demasiado para un comentario. Claramente, este no es un problema de certificación de servidor; los síntomas de eso son bastante diferentes. Desde el punto de vista de su sistema, el servidor parece estar cerrándose durante el saludo. Hay dos posibilidades:

El servidor realmente se está cerrando, lo cual es una violación del protocolo SSL / TLS aunque bastante menor; Hay bastantes razones por las que un servidor puede fallar en su comunicación, pero primero debe enviar una alerta fatal, que su JSSE o el equivalente weblogic debería indicar. En este caso, puede haber información útil en el registro del servidor, si puede (y se le permite) comunicarse con los administradores del servidor con conocimiento. O puede intentar poner un monitor de red en su máquina cliente, o uno lo suficientemente cerca como para ver todo su tráfico; personalmente me gusta www.wireshark.org. Pero esto generalmente solo muestra que el cierre se produjo inmediatamente después de ClientHello, lo que no reduce mucho. No dice si debe y ha configurado un "certificado de cliente" (en realidad, clave y certificado, en forma de Java privateKeyEntry) para este servidor; si el servidor lo requiere y no es correcto, algunos servidores pueden percibirlo como un ataque y violar intencionalmente el protocolo al cerrarse, aunque oficialmente deberían enviar una alerta.

O bien, algún middlebox en la red, más a menudo un firewall o proxy supuestamente transparente, está decidiendo que no le gusta su conexión y forzar su cierre. El Proxy que usas es un sospechoso obvio; cuando diga que el "mismo código" funciona para otros hosts, confirme si quiere decir a través del mismo proxy (no solo un proxy) y usando HTTPS (no está claro HTTP). Si no es así, intente probar con otros hosts con HTTPS a través del proxy (no necesita enviar una solicitud SOAP completa, solo un GET / si es suficiente). Si puede, intente conectarse sin el proxy, o posiblemente un proxy diferente, y conecte HTTP (no S) a través del proxy al host (si ambos admiten claro) y vea si funcionan.

Si no le importa publicar el host real (pero definitivamente no hay credenciales de autenticación), otros pueden intentarlo. O puede ir a www.ssllabs.com y solicitar que prueben el servidor (sin publicar los resultados); esto probará varias variaciones comunes en la conexión SSL / TLS e informará cualquier error que vea, así como cualquier debilidad de seguridad.

Estoy obteniendo javax.net.ssl.SSLHandshakeException: el host remoto cerró la conexión durante la excepción de handshake cuando trato de hacer una publicación Https de un servicio web a través de Internet. Pero el mismo código funciona para otros servicios web alojados en Internet. Intenté muchas cosas, nada me está ayudando. Publiqué mi código de muestra aquí. ¿Puede alguien ayudarme a resolver este problema?

public static void main(String[] args) throws Exception { String xmlServerURL = "https://example.com/soap/WsRouter"; URL urlXMLServer = new URL(xmlServerURL); // URLConnection supports HTTPS protocol only with JDK 1.4+ Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress( "xxxx.example.com", 8083)); HttpURLConnection httpsURLConnection = (HttpURLConnection) urlXMLServer .openConnection(proxy); httpsURLConnection.setRequestProperty("Content-Type","text/xml; charset=utf-8"); //httpsURLConnection.setDoInput(true); httpsURLConnection.setDoOutput(true); httpsURLConnection.setConnectTimeout(300000); //httpsURLConnection.setIgnoreProxy(false); httpsURLConnection.setRequestMethod("POST"); //httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY); // send request PrintWriter out = new PrintWriter( httpsURLConnection.getOutputStream()); StringBuffer requestXML = new StringBuffer(); requestXML.append(getProcessWorkOrderSOAPXML()); // get list of user out.println(requestXML.toString()); out.close(); out.flush(); System.out.println("XML Request POSTed to " + xmlServerURL + "/n"); System.out.println(requestXML.toString() + "/n"); //Thread.sleep(60000); // read response BufferedReader in = new BufferedReader(new InputStreamReader( httpsURLConnection.getInputStream())); String line; String respXML = ""; while ((line = in.readLine()) != null) { respXML += line; } in.close(); // output response respXML = URLDecoder.decode(respXML, "UTF-8"); System.out.println("/nXML Response/n"); System.out.println(respXML); }

Stacketrace completo:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) at com.labcorp.efone.vendor.TestATTConnectivity.main(TestATTConnectivity.java:43) Caused by: java.io.EOFException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.read(InputRecord.java:482) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927) ... 8 more

En realidad, hay dos escenarios aquí. Cuando trabajo como un programa Java independiente obtengo la excepción anterior. Pero cuando trato de ejecutar en el servidor de aplicaciones weblogic, obtengo la siguiente excepción: ¿Alguna pista de cuál podría ser el motivo?

java.io.IOException: Connection closed, EOF detected at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:637) at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515) at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:96) at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:75) at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:448) at weblogic.socket.JSSESocket$JSSEOutputStream.write(JSSESocket.java:93) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:192) at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:433) at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37) at com.labcorp.efone.service.impl.WorkOrderServiceImpl.processATTWorkOrder(ATTWorkOrderServiceImpl.java:86) at com.labcorp.efone.bds.WorkOrderBusinessDelegateImpl.processATTWorkOrder(WorkOrderBusinessDelegateImpl.java:59) at com.labcorp.efone.actions.ATTWorkOrderAction.efonePerformForward(ATTWorkOrderAction.java:41) at com.labcorp.efone.actions.EfoneAction.efonePerformActionForward(EfoneAction.java:149) at com.labcorp.efone.actions.EfoneAction.execute(EfoneAction.java:225) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) at javax.servlet.http.HttpServlet.service(HttpServlet.java:751) at javax.servlet.http.HttpServlet.service(HttpServlet.java:844) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at com.labcorp.efone.security.EfoneAuthenticationFilter.doFilter(EfoneAuthenticationFilter.java:115) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3367) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3333) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57) at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2220) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2146) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2124) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564) at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295) at weblogic.work.ExecuteThread.run(ExecuteThread.java:254) Exception: java.io.IOException: Connection closed, EOF detected

Cómo lo resolverías yendo a

  1. Configuraciones

  2. Buscar "Red"

  3. Elija "Usar la configuración proxy general de IDEA como Subversion predeterminada"

Creo que te faltan tus certificados.

Puede intentar generarlos utilizando la aplicación InstallCerts. Aquí puede ver cómo usarlo: http://www.opentox.org/tutorials/q-edit/how-to-install-ssl-certificates

Una vez que obtenga su certificado, debe colocarlo debajo de su directorio de seguridad dentro de su hogar jdk, por ejemplo:

C:/Program Files/Java/jdk1.6.0_45/jre/lib/security

Déjame saber si funciona.

Ejecuto mi aplicación con Java 8 y Java 8 trajo el certificado de seguridad a su tienda de confianza. Luego cambié a Java 7 y agregué lo siguiente a las opciones de VM:

-Djavax.net.ssl.trustStore=C:/<....>/java8/jre/lib/security/cacerts

Simplemente señalé la ubicación donde está el certificado.

En mi caso, tuve este problema porque le había dado al servidor un certificado inexistente, debido a un error tipográfico en el archivo de configuración. En lugar de lanzar una excepción, el servidor procedió como siempre y envió un certificado vacío al cliente. Por lo tanto, vale la pena verificar para asegurarse de que el servidor proporciona la respuesta correcta.

Experimenté este error al usar Jersey Client para conectarme a un servidor. La forma en que lo resolví fue depurando la biblioteca y viendo que realmente recibía un EOF en el momento que intentaba leer. También intenté conectarme usando un navegador web y obtuve los mismos resultados.

Solo escribo esto aquí en caso de que termine ayudando a alguien.

Encontré este problema con Java 1.6. Ejecutar bajo Java 1.7 solucionó mi versión particular del problema. Creo que la causa subyacente fue que el servidor al que me estaba conectando debe haber requerido un cifrado más sólido que el disponible en 1.6.

Encontré un problema similar con el servidor de aplicaciones de Glassfish y Oracle JDK / JRE pero no con Open JDK / JRE.

Cuando me conecté a un dominio SSL siempre me encontré con:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake ... Caused by: java.io.EOFException: SSL peer shut down incorrectly

La solución para mí fue instalar los archivos de política de jurisdicción de fuerza ilimitada de la extensión criptográfica de Java (JCE) porque el servidor solo entendía los certificados que no están incluidos en Oracle JDK de forma predeterminada, solo OpenJDK los incluye. Después de instalar todo funcionó como Charme.

JCE 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

JCE 8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

Enfrenté el mismo problema una vez. Creo que es debido a la URL

String xmlServerURL = " https://example.com/soap/WsRouter ";

Compruebe si es uno adecuado o no?

javax.net.ssl.SSLHandshakeException se debe a que el servidor no puede conectarse a la URL especificada debido a los siguientes motivos:

  • O la identidad del sitio web no está verificada.
  • El certificado del servidor no coincide con la URL.
  • O bien, el certificado del Servidor no es de confianza.

Enfrenté el mismo problema, lo resolví añadiendo:

System.setProperty("https.protocols", "TLSv1,TLSv1.1,TLSv1.2");

antes del método openConnection .

Estaba usando el p12 que exporté con Keychain en mi MacBook, sin embargo, no funcionó en mi código de servidor java-apns. Lo que tuve que hacer fue crear una nueva clave p12 como se indica here , usando mis claves de pem ya generadas:

openssl pkcs12 -export -in your_app.pem -inkey your_key.pem -out your_app_key.p12

Luego actualicé la ruta a ese nuevo archivo p12 y todo funcionó perfectamente.

Gracias a todos por compartir sus respuestas y ejemplos. El mismo programa independiente funcionó para mí mediante pequeños cambios y agregando las líneas de código a continuación.

En este caso, el proveedor del servicio web proporcionó el archivo del almacén de claves.

// Small changes during connection initiation.. // Please add this static block static { HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession arg1) { // TODO Auto-generated method stub if (hostname.equals("X.X.X.X")) { System.out.println("Return TRUE"+hostname); return true; } System.out.println("Return FALSE"); return false; } }); } String xmlServerURL = "https://X.X.X.X:8080/services/EndpointPort"; URL urlXMLServer = new URL(null,xmlServerURL,new sun.net.www.protocol.https.Handler()); HttpsURLConnection httpsURLConnection = (HttpsURLConnection) urlXMLServer .openConnection(); // Below extra lines are added to the same program //Keystore file System.setProperty("javax.net.ssl.keyStore", "Drive:/FullPath/keystorefile.store"); System.setProperty("javax.net.ssl.keyStorePassword", "Password"); // Password given by vendor //TrustStore file System.setProperty("javax.net.ssl.trustStore"Drive:/FullPath/keystorefile.store"); System.setProperty("javax.net.ssl.trustStorePassword", "Password");

Java 7 se predetermina a TLS 1.0, que puede causar este error cuando no se acepta ese protocolo. Me encontré con este problema con una aplicación Tomcat y un servidor que ya no aceptaba las conexiones TLS 1.0. yo añadí

-Dhttps.protocols=TLSv1.1,TLSv1.2

a las opciones de Java y eso lo solucionó. (Tomcat estaba ejecutando Java 7.)

Me encontré con un problema similar y descubrí que estaba llegando al puerto equivocado. Después de arreglar el puerto, las cosas funcionaron muy bien.

System.setProperty ("https.protocols", "TLSv1, TLSv1.1, TLSv1.2");

¡Funciono bien para mi!

Tuve el mismo error, pero en mi caso fue causado por el modo DEBUG en Intellij IDE. La depuración ralentizó la biblioteca y luego el servidor finalizó la comunicación en la fase de establecimiento de enlace. El "RUN" estándar funcionó perfectamente.

Usted puede escribir este código a continuación insdie su programa java actual

System.setProperty ("https.protocols", "TLSv1.1");

o

System.setProperty ("http.proxyHost", "proxy.com"); System.setProperty ("http.proxyPort", "911");

Esto es lo que resuelve mi problema.

Si está tratando de usar el depurador, asegúrese de que el punto de corte no esté en URL o URLConnection simplemente ponga su punto de interrupción en el BufferReader o dentro de while loop.

Si nada funciona, intente utilizar la biblioteca de apache http://hc.apache.org/index.html .

sin SSL, sin necesidad de actualizar JDK, sin necesidad de establecer propiedades, solo truco simple :)