java - example - http cxf apache org jaxws
El nombre de host URL https no coincide con el Nombre común(CN) a pesar de establecer ''disableCNCheck'' en true (2)
Pon -Djsse.enableSNIExtension=false en las opciones de VM de tu servidor de aplicaciones.
Logré configurar mi cliente basado en CXF correctamente para que encuentre el certificado SSL correcto para el servidor en el que estoy ejecutando un servicio web:
<http:conduit name="https://myserver/myws/register/soap?wsdl:{http://glob.reg.com/myws}.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="changeit">
<sec:keyStore type="JKS" password="changeit"
file="C:/Program Files (x86)/Java/jdk1.6.0_45/jre/lib/security/cacerts"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="changeit"
file="C:/Program Files (x86)/Java/jdk1.6.0_45/jre/lib/security/cacerts"/>
</sec:trustManagers>
<sec:cipherSuitesFilter>
<!-- these filters ensure that a ciphersuite with
export-suitable or null encryption is used,
but exclude anonymous Diffie-Hellman key change as
this is vulnerable to man-in-the-middle attacks -->
<sec:include>.*_EXPORT_.*</sec:include>
<sec:include>.*_EXPORT1024_.*</sec:include>
<sec:include>.*_WITH_DES_.*</sec:include>
<sec:include>.*_WITH_AES_.*</sec:include>
<sec:include>.*_WITH_NULL_.*</sec:include>
<sec:exclude>.*_DH_anon_.*</sec:exclude>
</sec:cipherSuitesFilter>
</http:tlsClientParameters>
<http:authorization>
<sec:UserName>Betty</sec:UserName>
<sec:Password>password</sec:Password>
</http:authorization>
<http:client AutoRedirect="true" Connection="Keep-Alive"/>
</http:conduit>
Pero ... debido a que el certificado es para un nombre de subdominio que es diferente de la máquina de mi servidor (se asigna a la misma dirección IP), recibo el siguiente error:
Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN) on the server certificate in the client''s truststore. Make sure serv
er certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:183)
at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1293)
... 18 more
Entonces ... ya que este es un sistema de desarrollo / prueba, hice exactamente lo que el mensaje proponía (establezca la propiedad de configuración TLS del cliente CXF "disableCNCheck" en verdadero):
<http:tlsClientParameters disableCNCheck="true">
Además , agregué el siguiente código a la clase principal de mi cliente (según la sugerencia en este hilo ):
static {
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()
{
@Override
public boolean verify(String hostname, SSLSession session)
{
return true;
}
});
}
Pero ... sigo recibiendo el mismo error:
Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN) on the server certificate in the client''s truststore. Make sure serv
er certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:183)
at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1293)
... 18 more
¿Alguna idea de por qué?
Quiero decir, una de las soluciones anteriores debería haber sido suficiente para que el cliente ignore la discrepancia de URL del certificado pero, en mi caso, ni funciona ni la combinación de ambas .
¿Por qué?
He usado CXF en varios casos donde
<http:tlsClientParameters disableCNCheck="true">
fue suficiente para desactivar el control CN.
¿Está seguro de que su cliente está usando esa configuración de conducto? Según entiendo, el patrón del nombre del conducto debe coincidir con el URI del punto final de alguna manera.
Intente configurar el nombre del conducto de la siguiente manera para que cualquier punto final coincida y vea si eso cambia algo:
<http:conduit name="*.http-conduit">
Actualización 2 ene 2015
Resulta que la coincidencia del nombre de configuración del http-conduit tiene dos formatos de patrón. Uno involucra el espacio de nombres y el nombre del puerto del servicio. El otro formato admitido es una expresión regular que coincide con el punto final URL especificado en WSDL utilizado para crear el cliente.
Citando la Guía del usuario de Apache CXF con respecto al elemento http-conduit :
El nombre incluye el espacio de nombres del servicio, el nombre del puerto WSDL (como se encuentra en la sección wsdl: servicio del WSDL) y ".http-conduit". Sigue esta plantilla:
{WSDL Namespace}portName.http-conduitNota: es el nombre PORT, no el nombre del servicio.
..
Otra opción para el atributo de nombre es una expresión reg-ex (por ejemplo, " http://myserver.example.com : *") para la URL ORIGINAL del punto final. La configuración se corresponde con la creación del conducto, por lo que la dirección utilizada en el WSDL o utilizada para la llamada a JAX-WS Service.create (...) se puede utilizar para el nombre.