cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kisrákói Gyula (JIRA) <j...@apache.org>
Subject [jira] [Updated] (CXF-7334) HTTPS CN check errors when disableCNCheck is set to true
Date Wed, 12 Apr 2017 11:22:41 GMT

     [ 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)

Mime
View raw message