You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Kisrákói Gyula (JIRA)" <ji...@apache.org> on 2017/04/12 11:22:41 UTC
[jira] [Updated] (CXF-7334) HTTPS CN check errors when
disableCNCheck is set to true
[ https://issues.apache.org/jira/browse/CXF-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kisrákói Gyula updated CXF-7334:
--------------------------------
Description:
We get CN check errors in some of our deployments, although 'disableCNCheck' is set to true in the config. The same application is deployed with the same configuration and environment on two server instances. On the first server it works, we get no such error, on the second server (which is cloned from the first one) every request fails. I couldn't reproduce the error in our test environment.
I've excluded all JBoss's built-in CXF classes in the deployment descriptor, so it's not a classloading problem, the CXF classes in use are the bundled ones in the application.
The HTTP conduit configuration for the client:
{code}
<http:conduit name="{<namespace>}<port>.http-conduit">
<http:tlsClientParameters disableCNCheck="true" useHttpsURLConnectionDefaultHostnameVerifier="false" sslCacheTimeout="1">
...
{code}
The HTTP conduit configuration is applied to the requests, I see the following in the debug log:
{code}
<date> DEBUG org.apache.cxf.transport.http.HTTPConduit - Conduit '{<namespace>}<port>.http-conduit' has been configured for TLS keyManagers [sun.security.ssl.SunX509KeyManagerImpl@a4cb362]trustManagers [sun.security.ssl.X509TrustManagerImpl@34ed52cf]secureRandom nullDisable Common Name (CN) Check: true
{code}
The error:
{code}
<date> WARN org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {<namespace>}port#{<namespace>}<operation> has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy241.<operation>(Unknown Source)
.....
Caused by: java.io.IOException: IOException invoking https://<server-ip>:<port>/<service>/<path>: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1369)
at hu.logesz.cxf.logging.LoggingOutInterceptor$OutputStreamWrapper.close(LoggingOutInterceptor.java:203)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:653)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 53 more
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 server 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:1291)
at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:305)
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:1341)
... 57 more
{code}
was:
We get CN check errors in some of our deployments, although 'disableCNCheck' is set to true in the config. The same application is deployed with the same configuration and environment on two server instances. On the first server it works, we get no such error, on the second server (which is cloned from the first one) every request fails. I couldn't reproduce the error in our test environment.
I've excluded all JBoss's built-in CXF classes in the deployment descriptor, so it's not a classloading problem, the CXF classes in use are the bundled ones in the application.
The HTTP conduit configuration for the client:
{code}
<http:conduit name="{<namespace>}<port>.http-conduit">
<http:tlsClientParameters disableCNCheck="true" useHttpsURLConnectionDefaultHostnameVerifier="false" sslCacheTimeout="1">
...
{code}
The HTTP conduit configuration is applied to the requests, I see the following in the debug log:
{code}
<date> DEBUG org.apache.cxf.transport.http.HTTPConduit - Conduit '{<namespace>}<port>.http-conduit' has been configured for TLS keyManagers [sun.security.ssl.SunX509KeyManagerImpl@a4cb362]trustManagers [sun.security.ssl.X509TrustManagerImpl@34ed52cf]secureRandom nullDisable Common Name (CN) Check: true
{code}
The error:
<date> WARN org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {<namespace>}port#{<namespace>}<operation> has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy241.<operation>(Unknown Source)
.....
Caused by: java.io.IOException: IOException invoking https://<server-ip>:<port>/<service>/<path>: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1369)
at hu.logesz.cxf.logging.LoggingOutInterceptor$OutputStreamWrapper.close(LoggingOutInterceptor.java:203)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:653)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 53 more
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 server 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:1291)
at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:305)
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:1341)
... 57 more
> HTTPS CN check errors when disableCNCheck is set to true
> --------------------------------------------------------
>
> Key: CXF-7334
> URL: https://issues.apache.org/jira/browse/CXF-7334
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.1.9, 3.1.10, 3.1.11
> Environment: OpenJDK 1.8.0_121, JBoss EAP 6.4.3.GA
> Reporter: Kisrákói Gyula
>
> We get CN check errors in some of our deployments, although 'disableCNCheck' is set to true in the config. The same application is deployed with the same configuration and environment on two server instances. On the first server it works, we get no such error, on the second server (which is cloned from the first one) every request fails. I couldn't reproduce the error in our test environment.
> I've excluded all JBoss's built-in CXF classes in the deployment descriptor, so it's not a classloading problem, the CXF classes in use are the bundled ones in the application.
> The HTTP conduit configuration for the client:
> {code}
> <http:conduit name="{<namespace>}<port>.http-conduit">
> <http:tlsClientParameters disableCNCheck="true" useHttpsURLConnectionDefaultHostnameVerifier="false" sslCacheTimeout="1">
> ...
> {code}
> The HTTP conduit configuration is applied to the requests, I see the following in the debug log:
> {code}
> <date> DEBUG org.apache.cxf.transport.http.HTTPConduit - Conduit '{<namespace>}<port>.http-conduit' has been configured for TLS keyManagers [sun.security.ssl.SunX509KeyManagerImpl@a4cb362]trustManagers [sun.security.ssl.X509TrustManagerImpl@34ed52cf]secureRandom nullDisable Common Name (CN) Check: true
> {code}
> The error:
> {code}
> <date> WARN org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {<namespace>}port#{<namespace>}<operation> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> at com.sun.proxy.$Proxy241.<operation>(Unknown Source)
> .....
> Caused by: java.io.IOException: IOException invoking https://<server-ip>:<port>/<service>/<path>: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1369)
> at hu.logesz.cxf.logging.LoggingOutInterceptor$OutputStreamWrapper.close(LoggingOutInterceptor.java:203)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:653)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> ... 53 more
> 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 server 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:1291)
> at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:305)
> 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:1341)
> ... 57 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)