Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 12 Apr 2017 11:22:41 +0000 (UTC)
From: =?utf-8?Q?Kisr=C3=A1k=C3=B3i_Gyula_=28JIRA=29?= <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.13063445.1491996115000.264446.1491996161566@Atlassian.JIRA>
In-Reply-To: <JIRA.13063445.1491996115000@Atlassian.JIRA>
References: <JIRA.13063445.1491996115000@Atlassian.JIRA> <JIRA.13063445.1491996115802@jira-lw-us.apache.org>
Subject: [jira] [Created] (CXF-7334) HTTPS CN check errors when
 disableCNCheck is set to true
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 12 Apr 2017 11:22:48 -0000

Kisr=C3=A1k=C3=B3i Gyula created CXF-7334:
-----------------------------------

             Summary: HTTPS CN check errors when disableCNCheck is set to t=
rue
                 Key: CXF-7334
                 URL: https://issues.apache.org/jira/browse/CXF-7334
             Project: CXF
          Issue Type: Bug
          Components: Transports
    Affects Versions: 3.1.11, 3.1.10, 3.1.9
         Environment: OpenJDK 1.8.0_121, JBoss EAP 6.4.3.GA
            Reporter: Kisr=C3=A1k=C3=B3i 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 s=
ame configuration and environment on two server instances. On the first ser=
ver it works, we get no such error, on the second server (which is cloned f=
rom the first one) every request fails. I couldn't reproduce the error in o=
ur 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 bundle=
d ones in the application.

The HTTP conduit configuration for the client:
{code}
<http:conduit name=3D"{<namespace>}<port>.http-conduit">
=09<http:tlsClientParameters disableCNCheck=3D"true" useHttpsURLConnectionD=
efaultHostnameVerifier=3D"false" sslCacheTimeout=3D"1">
...
{code}

The HTTP conduit configuration is applied to the requests, I see the follow=
ing in the debug log:
{code}
<date> DEBUG org.apache.cxf.transport.http.HTTPConduit - Conduit '{<namespa=
ce>}<port>.http-conduit' has been configured for TLS keyManagers [sun.secur=
ity.ssl.SunX509KeyManagerImpl@a4cb362]trustManagers [sun.security.ssl.X509T=
rustManagerImpl@34ed52cf]secureRandom nullDisable Common Name (CN) Check: t=
rue
{code}

The error:
 <date> WARN org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {=
<namespace>}port#{<namespace>}<operation> has thrown exception, unwinding n=
ow
 org.apache.cxf.interceptor.Fault: Could not send Message.
=09at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi=
ngInterceptor.handleMessage(MessageSenderInterceptor.java:64)
=09at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept=
orChain.java:308)
=09at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
=09at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
=09at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
=09at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
=09at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
=09at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13=
9)
=09at com.sun.proxy.$Proxy241.<operation>(Unknown Source)
.....
Caused by: java.io.IOException: IOException invoking https://<server-ip>:<p=
ort>/<service>/<path>: The https URL hostname does not match the Common Nam=
e (CN) on the server certificate in the client's truststore.  Make sure ser=
ver certificate is correct, or to disable this check (NOT recommended for p=
roduction) set the CXF client TLS configuration property "disableCNCheck" t=
o true.
=09at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
=09at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct=
orAccessorImpl.java:62)
=09at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC=
onstructorAccessorImpl.java:45)
=09at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
=09at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapExce=
ption(HTTPConduit.java:1385)
=09at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H=
TTPConduit.java:1369)
=09at hu.logesz.cxf.logging.LoggingOutInterceptor$OutputStreamWrapper.close=
(LoggingOutInterceptor.java:203)
=09at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:5=
6)
=09at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:653)
=09at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi=
ngInterceptor.handleMessage(MessageSenderInterceptor.java:62)
=09... 53 more
Caused by: java.io.IOException: The https URL hostname does not match the C=
ommon Name (CN) on the server certificate in the client's truststore.  Make=
 sure server certificate is correct, or to disable this check (NOT recommen=
ded for production) set the CXF client TLS configuration property "disableC=
NCheck" to true.
=09at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirst=
Write(HTTPConduit.java:1291)
=09at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionW=
rappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:305)
=09at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOu=
tputStream.java:47)
=09at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresho=
ldOutputStream.java:69)
=09at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H=
TTPConduit.java:1341)
=09... 57 more


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)