You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by wonderingWV <jo...@mantech.com> on 2008/11/11 18:47:44 UTC
Http-conduit disableCNCheck
I'm trying to get ssl to work with CXF, but continue to get
Caused by: java.io.IOException: The https URL hostname does not match the
Common
Name (CN) on the server certificate. To disable this check (NOT
recommended fo
r production) set the CXF client TLS configuration property "disableCNCheck"
to
true.
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirst
Write(HTTPConduit.java:1795)
at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOu
tputStream.java:42)
at
org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresho
ldOutputStream.java:69)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
TTPConduit.java:1852)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:6
6)
at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:593)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
ngInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 72 more
If I set disableCNCheck(true), then the code works properly. But I do not
want to leave that flag set to true in a production environment. I'm using
CXF 2.1.2. The service endpoint and http conduit is configured in a spring
xml file like so:
<jaxws:endpoint id="testSoapService"
implementor="#testServiceImpl"
address="/test/soap"
name="ns:TestService"
serviceName="ns:TestService"
endpointName="ns:TestServicePort"
xmlns:ns="http://test.service.run.com"/>
<http-conf:conduit name="*.http-conduit">
<http-conf:client AllowChunking="true" />
<http-conf:tlsClientParameters secureSocketProtocol="SSL">
<sec:keyManagers keyPassword="changeit">
<sec:keyStore type="JKS" password="changeit"
file="/home/jboss-4.2.2.GA/server/default/conf/server.keystore"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="changeit"
file="/home/jboss-4.2.2.GA/server/default/conf/server.truststore"/>
</sec:trustManagers>
</http-conf:tlsClientParameters>
</http-conf:conduit>
The client is configured programmatically using JaxWsProxyFactoryBean. The
client http-conduit is also configured programmatically like so:
Client client = ClientProxy.getClient(wsSSLBean.getClient());
HTTPConduit httpConduit = (HTTPConduit) client.getConduit();
try {
TLSClientParameters tlsParams = new TLSClientParameters();
//initialize store which you'll load the client truststore into
KeyStore trustStore = KeyStore.getInstance("JKS");
String trustPassword = wsSSLBean.getTruststorePassword();
// location of the svr cert stored on client box
File truststoreFile = new File(wsSSLBean.getTruststoreLoc());
trustStore.load(new FileInputStream(truststoreFile),
trustPassword.toCharArray());
//load truststore into httpConduit's tlsClientParams
TrustManagerFactory trustFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustFactory.init(trustStore);
TrustManager[] tm = trustFactory.getTrustManagers();
tlsParams.setTrustManagers(tm);
// initialize store which you'll load the client keystore into
KeyStore keyStore = KeyStore.getInstance("JKS");
String keyPassword = wsSSLBean.getKeystorePassword();
// location of client.keystore which houses the clients keys and
cert
File keystoreFile = new File(wsSSLBean.getKeystoreLoc());
keyStore.load(new FileInputStream(keystoreFile),
keyPassword.toCharArray());
// load keystore into httpConduit's tlsClientParams
KeyManagerFactory keyFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyFactory.init(keyStore, keyPassword.toCharArray());
KeyManager[] km = keyFactory.getKeyManagers();
tlsParams.setKeyManagers(km);
// set to be SSL
tlsParams.setSecureSocketProtocol("SSL");
// set Http Client Policy to allow chunking
HTTPClientPolicy clientPol = new HTTPClientPolicy();
clientPol.setAllowChunking(true);
// set tlsParams and HTTP policy into httpConduit
httpConduit.setTlsClientParameters(tlsParams);
httpConduit.setClient(clientPol);
}
catch (Exception e){
log.error("configureSSLOnClient:" + e.getMessage());
}
The common name on the cert and the hostName of the url match up so I not
sure why I continue to receive this error. Any advise would be greatly
appreciated.
Thanks,
wonderingWV
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20444655.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Julius Davies <ju...@gmail.com>.
I recommend HostnameVerifier.DEFAULT. From the javadoc:
----------------
The DEFAULT HostnameVerifier works the same way as Curl and Firefox.
The hostname must match either the first CN, or any of the
subject-alts. A wildcard can occur in the CN, and in any of the
subject-alts.
The only difference between DEFAULT and STRICT is that a wildcard
(such as "*.foo.com") with DEFAULT matches all subdomains, including
"a.b.foo.com".
----------------
>
> Cool. For CXF, which do you suggest is the "best" option to default in?
> Long term, we need to add config to make it configurable, but for the
> default, which do you suggest?
>
> Dan
>
>
--
yours,
Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/
Re: Http-conduit disableCNCheck
Posted by Daniel Kulp <dk...@apache.org>.
On Saturday 15 November 2008 1:56:42 am Julius Davies wrote:
> Hi,
>
> Feel free to use the not-yet-commons-ssl hostname verifier. I have a
> CLA on file (http://people.apache.org/~jim/committers.html). This
> code was accepted by httpcomponents, and is part of httpclient-4.x.
Yep. Actually, several other projects have taken it already. I happened to
grab it from Synapse since that's the first one Google popped up.
> I've been really inactive for the last year. The httpclient
> (http://hc.apache.org/) version is getting more attention. Might be
> more attractive to you (split across several files):
>
> http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/module-client/
>src/main/java/org/apache/http/conn/ssl/
Cool. For CXF, which do you suggest is the "best" option to default in?
Long term, we need to add config to make it configurable, but for the
default, which do you suggest?
Dan
>
> yours,
>
> Julius
>
> On Wed, Nov 12, 2008 at 5:26 PM, Daniel Kulp <dk...@apache.org> wrote:
> > On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
> >> If it helps, we use JDK 5 and the problem with the
> >> disableCNCheck(false) first appeared after we updated from CXF 2.0.* to
> >> CXF 2.1.*
> >
> > I just committed some changes that install a better HostnameVerifier to
> > check the certs. It would be great if you could checkout the 2.1.x
> > branch, build it, and give it a whirl. I'll try and upload new
> > snapshots tomorrow if doing a build is too much.
> >
> > Dan
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Http-conduit disableCNCheck
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 19 November 2008 1:30:59 pm wonderingWV wrote:
> The 2.1.4 SNAPSHOT corrected the issue as long as you use the workaround
> suggested in the "IllegalArgumentException: SSL" thread and set
> tlsParams.setSecureSocketProtocol("SSLv3") instead of just "SSL".
>
> Do you have an eta when the 2.1.4. build will be released?
Normally, it's about every 2 months or so. However, we released 2.1.3 on Oct
22. That would put the next right at Christmas time which might not be the
best option. I'm not sure if we want to move it up to maybe Dec 10th-15th
or so or move it out to the first week of Jan. Anyone have any thoughts?
Dan
>
> John
>
> dkulp wrote:
> > On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
> >> If it helps, we use JDK 5 and the problem with the
> >> disableCNCheck(false) first appeared after we updated from CXF 2.0.* to
> >> CXF 2.1.*
> >
> > I just committed some changes that install a better HostnameVerifier to
> > check
> > the certs. It would be great if you could checkout the 2.1.x branch,
> > build
> > it, and give it a whirl. I'll try and upload new snapshots tomorrow if
> > doing a build is too much.
> >
> > Dan
> >
> >> John
> >>
> >> Glen Mazza wrote:
> >> > The Metro guide seems to suggest the default verifier is a little bit
> >> > more intelligent than that:
> >>
> >> https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Secu
> >>r
> >>
> >> >ity__SSL__Workaround
> >> >
> >> > But perhaps this is a result of switching from JDK 5 to 6? Anyway,
> >> > the workaround they have above probably would take care of the user
> >> > configurability functionality you mention in your last sentence below.
> >> >
> >> > Glen
> >> >
> >> > dkulp wrote:
> >> >> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
> >> >>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was
> >> >>> *not*
> >> >>> ported to the 2.1 branch?
> >> >>
> >> >> Looking back at the change history, your changes seem to add the
> >> >> "AlwaysTrue"
> >> >> verifier only if DisableCNCheck flag is true. Previous to your
> >>
> >> change,
> >>
> >> >> the
> >> >> AlwaysTrue verifier was always added.
> >> >>
> >> >> With your change, if the flag is false, it now delegates to the JDK
> >> >> built in
> >> >> default verifier which seems to be very stupid and just does "return
> >> >> false".
> >> >> Pretty much useless. :-( Looks to me like we need to find a
> >> >> good HostNameVerifier if the flag is false. Additionally, we
> >> >> probably should allow the user to configure in their own
> >> >> HostNameVerifier somehow.
> >> >>
> >> >> Dan
> >> >>
> >> >>> Glen
> >> >>>
> >> >>> dkulp wrote:
> >> >>> > Looking at the decompiled source for the
> >> >>> > "DefaultHostnameVerifier", it literally just does a "return
> >> >>> > false;". Thus, I don't see how it's possible
> >> >>> > to do any SSL things with host bound certs right now without the
> >> >>> > DisableCNCheck thing. It looks like we need to write a new
> >> >>> > HostNameVerifier thing that would actually do some level of
> >> >>>
> >> >>> verification.
> >> >>>
> >> >>> > We might be able to grab the one synapse has:
> >>
> >> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/s
> >>
> >> >>>rc
> >> >>>
> >> >>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
> >> >>> >
> >> >>> > and use that. Someone would need to check that though. That
> >> >>> > looks
> >> >>>
> >> >>> like
> >> >>>
> >> >>> > it
> >> >>> > came from the not-yet-commons-ssl project at
> >> >>> > http://juliusdavies.ca/commons-ssl/
> >> >>> >
> >> >>> > There's probably some others floating around if we dig more.
> >> >>> >
> >> >>> > Dan
> >> >>> >
> >> >>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
> >> >>> >> If you can check the CXF source code (I don't have it with me
> >> >>> >> immediately,
> >> >>> >> but search the source code for the error message you're getting
> >> >>> >> to determine the class) -- you can place debugging statements on
> >> >>> >> what
> >> >>>
> >> >>> CXF
> >> >>>
> >> >>> >> thinks the hostname URL and the CN is to determine why it is
> >>
> >> failing
> >>
> >> >>> on
> >> >>>
> >> >>> >> you. Perhaps I made a mistake in my logic someplace--but as no
> >>
> >> one
> >>
> >> >>> else
> >> >>>
> >> >>> >> has complained about this yet, I would suspect, for some reason,
> >> >>> >> your
> >> >>>
> >> >>> CN
> >> >>>
> >> >>> >> actually isn't matching the hostname URL.
> >> >>> >>
> >> >>> >> Glen
> >> >>> >>
> >> >>> >> wonderingWV wrote:
> >> >>> >> > I understand why it was done, but the problem is I cannot get
> >>
> >> ssl
> >>
> >> >>> with
> >> >>>
> >> >>> >> > cxf to work unless the flag is set to true, which I do not want
> >>
> >> to
> >>
> >> >>> do
> >> >>>
> >> >>> >> in
> >> >>> >>
> >> >>> >> > a production environment.
> >> >>> >> >
> >> >>> >> > Glen Mazza wrote:
> >> >>> >> >> I'm unsure what the problem is. I had done that last March[1]
> >> >>>
> >> >>> after
> >> >>>
> >> >>> >> >> agreement with the team.
> >> >>> >> >>
> >> >>> >> >> Glen
> >> >>> >> >>
> >> >>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
> >> >>> >> >>
> >> >>> >> >> wonderingWV wrote:
> >> >>> >> >>> The common name on the cert and the hostName of the url match
> >>
> >> up
> >>
> >> >>> so
> >> >>>
> >> >>> >> >>> I not sure why I continue to receive this error. Any advise
> >> >>>
> >> >>> would
> >> >>>
> >> >>> >> >>> be greatly appreciated.
> >> >>> >
> >> >>> > --
> >> >>> > Daniel Kulp
> >> >>> > dkulp@apache.org
> >> >>> > http://dankulp.com/blog
> >> >>
> >> >> --
> >> >> Daniel Kulp
> >> >> dkulp@apache.org
> >> >> http://dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Http-conduit disableCNCheck
Posted by Julius Davies <ju...@gmail.com>.
Hi,
Feel free to use the not-yet-commons-ssl hostname verifier. I have a
CLA on file (http://people.apache.org/~jim/committers.html). This
code was accepted by httpcomponents, and is part of httpclient-4.x.
I've been really inactive for the last year. The httpclient
(http://hc.apache.org/) version is getting more attention. Might be
more attractive to you (split across several files):
http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/module-client/src/main/java/org/apache/http/conn/ssl/
yours,
Julius
On Wed, Nov 12, 2008 at 5:26 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
>> If it helps, we use JDK 5 and the problem with the disableCNCheck(false)
>> first appeared after we updated from CXF 2.0.* to CXF 2.1.*
>
> I just committed some changes that install a better HostnameVerifier to check
> the certs. It would be great if you could checkout the 2.1.x branch, build
> it, and give it a whirl. I'll try and upload new snapshots tomorrow if
> doing a build is too much.
>
> Dan
>
>
--
yours,
Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/
Re: Http-conduit disableCNCheck
Posted by wonderingWV <jo...@mantech.com>.
The 2.1.4 SNAPSHOT corrected the issue as long as you use the workaround
suggested in the "IllegalArgumentException: SSL" thread and set
tlsParams.setSecureSocketProtocol("SSLv3") instead of just "SSL".
Do you have an eta when the 2.1.4. build will be released?
John
dkulp wrote:
>
> On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
>> If it helps, we use JDK 5 and the problem with the disableCNCheck(false)
>> first appeared after we updated from CXF 2.0.* to CXF 2.1.*
>
> I just committed some changes that install a better HostnameVerifier to
> check
> the certs. It would be great if you could checkout the 2.1.x branch,
> build
> it, and give it a whirl. I'll try and upload new snapshots tomorrow if
> doing a build is too much.
>
> Dan
>
>
>>
>> John
>>
>> Glen Mazza wrote:
>> > The Metro guide seems to suggest the default verifier is a little bit
>> > more intelligent than that:
>> >
>> https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Secur
>> >ity__SSL__Workaround
>> >
>> > But perhaps this is a result of switching from JDK 5 to 6? Anyway, the
>> > workaround they have above probably would take care of the user
>> > configurability functionality you mention in your last sentence below.
>> >
>> > Glen
>> >
>> > dkulp wrote:
>> >> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
>> >>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was
>> >>> *not*
>> >>> ported to the 2.1 branch?
>> >>
>> >> Looking back at the change history, your changes seem to add the
>> >> "AlwaysTrue"
>> >> verifier only if DisableCNCheck flag is true. Previous to your
>> change,
>> >> the
>> >> AlwaysTrue verifier was always added.
>> >>
>> >> With your change, if the flag is false, it now delegates to the JDK
>> >> built in
>> >> default verifier which seems to be very stupid and just does "return
>> >> false".
>> >> Pretty much useless. :-( Looks to me like we need to find a good
>> >> HostNameVerifier if the flag is false. Additionally, we probably
>> >> should allow the user to configure in their own HostNameVerifier
>> >> somehow.
>> >>
>> >> Dan
>> >>
>> >>> Glen
>> >>>
>> >>> dkulp wrote:
>> >>> > Looking at the decompiled source for the "DefaultHostnameVerifier",
>> >>> > it literally just does a "return false;". Thus, I don't see how
>> >>> > it's possible
>> >>> > to do any SSL things with host bound certs right now without the
>> >>> > DisableCNCheck thing. It looks like we need to write a new
>> >>> > HostNameVerifier thing that would actually do some level of
>> >>>
>> >>> verification.
>> >>>
>> >>> > We might be able to grab the one synapse has:
>> >>>
>> >>>
>> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/s
>> >>>rc
>> >>>
>> >>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
>> >>> >
>> >>> > and use that. Someone would need to check that though. That looks
>> >>>
>> >>> like
>> >>>
>> >>> > it
>> >>> > came from the not-yet-commons-ssl project at
>> >>> > http://juliusdavies.ca/commons-ssl/
>> >>> >
>> >>> > There's probably some others floating around if we dig more.
>> >>> >
>> >>> > Dan
>> >>> >
>> >>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
>> >>> >> If you can check the CXF source code (I don't have it with me
>> >>> >> immediately,
>> >>> >> but search the source code for the error message you're getting to
>> >>> >> determine the class) -- you can place debugging statements on what
>> >>>
>> >>> CXF
>> >>>
>> >>> >> thinks the hostname URL and the CN is to determine why it is
>> failing
>> >>>
>> >>> on
>> >>>
>> >>> >> you. Perhaps I made a mistake in my logic someplace--but as no
>> one
>> >>>
>> >>> else
>> >>>
>> >>> >> has complained about this yet, I would suspect, for some reason,
>> >>> >> your
>> >>>
>> >>> CN
>> >>>
>> >>> >> actually isn't matching the hostname URL.
>> >>> >>
>> >>> >> Glen
>> >>> >>
>> >>> >> wonderingWV wrote:
>> >>> >> > I understand why it was done, but the problem is I cannot get
>> ssl
>> >>>
>> >>> with
>> >>>
>> >>> >> > cxf to work unless the flag is set to true, which I do not want
>> to
>> >>>
>> >>> do
>> >>>
>> >>> >> in
>> >>> >>
>> >>> >> > a production environment.
>> >>> >> >
>> >>> >> > Glen Mazza wrote:
>> >>> >> >> I'm unsure what the problem is. I had done that last March[1]
>> >>>
>> >>> after
>> >>>
>> >>> >> >> agreement with the team.
>> >>> >> >>
>> >>> >> >> Glen
>> >>> >> >>
>> >>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
>> >>> >> >>
>> >>> >> >> wonderingWV wrote:
>> >>> >> >>> The common name on the cert and the hostName of the url match
>> up
>> >>>
>> >>> so
>> >>>
>> >>> >> >>> I not sure why I continue to receive this error. Any advise
>> >>>
>> >>> would
>> >>>
>> >>> >> >>> be greatly appreciated.
>> >>> >
>> >>> > --
>> >>> > Daniel Kulp
>> >>> > dkulp@apache.org
>> >>> > http://dankulp.com/blog
>> >>
>> >> --
>> >> Daniel Kulp
>> >> dkulp@apache.org
>> >> http://dankulp.com/blog
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20586228.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote:
> If it helps, we use JDK 5 and the problem with the disableCNCheck(false)
> first appeared after we updated from CXF 2.0.* to CXF 2.1.*
I just committed some changes that install a better HostnameVerifier to check
the certs. It would be great if you could checkout the 2.1.x branch, build
it, and give it a whirl. I'll try and upload new snapshots tomorrow if
doing a build is too much.
Dan
>
> John
>
> Glen Mazza wrote:
> > The Metro guide seems to suggest the default verifier is a little bit
> > more intelligent than that:
> > https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Secur
> >ity__SSL__Workaround
> >
> > But perhaps this is a result of switching from JDK 5 to 6? Anyway, the
> > workaround they have above probably would take care of the user
> > configurability functionality you mention in your last sentence below.
> >
> > Glen
> >
> > dkulp wrote:
> >> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
> >>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was
> >>> *not*
> >>> ported to the 2.1 branch?
> >>
> >> Looking back at the change history, your changes seem to add the
> >> "AlwaysTrue"
> >> verifier only if DisableCNCheck flag is true. Previous to your change,
> >> the
> >> AlwaysTrue verifier was always added.
> >>
> >> With your change, if the flag is false, it now delegates to the JDK
> >> built in
> >> default verifier which seems to be very stupid and just does "return
> >> false".
> >> Pretty much useless. :-( Looks to me like we need to find a good
> >> HostNameVerifier if the flag is false. Additionally, we probably
> >> should allow the user to configure in their own HostNameVerifier
> >> somehow.
> >>
> >> Dan
> >>
> >>> Glen
> >>>
> >>> dkulp wrote:
> >>> > Looking at the decompiled source for the "DefaultHostnameVerifier",
> >>> > it literally just does a "return false;". Thus, I don't see how
> >>> > it's possible
> >>> > to do any SSL things with host bound certs right now without the
> >>> > DisableCNCheck thing. It looks like we need to write a new
> >>> > HostNameVerifier thing that would actually do some level of
> >>>
> >>> verification.
> >>>
> >>> > We might be able to grab the one synapse has:
> >>>
> >>> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/s
> >>>rc
> >>>
> >>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
> >>> >
> >>> > and use that. Someone would need to check that though. That looks
> >>>
> >>> like
> >>>
> >>> > it
> >>> > came from the not-yet-commons-ssl project at
> >>> > http://juliusdavies.ca/commons-ssl/
> >>> >
> >>> > There's probably some others floating around if we dig more.
> >>> >
> >>> > Dan
> >>> >
> >>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
> >>> >> If you can check the CXF source code (I don't have it with me
> >>> >> immediately,
> >>> >> but search the source code for the error message you're getting to
> >>> >> determine the class) -- you can place debugging statements on what
> >>>
> >>> CXF
> >>>
> >>> >> thinks the hostname URL and the CN is to determine why it is failing
> >>>
> >>> on
> >>>
> >>> >> you. Perhaps I made a mistake in my logic someplace--but as no one
> >>>
> >>> else
> >>>
> >>> >> has complained about this yet, I would suspect, for some reason,
> >>> >> your
> >>>
> >>> CN
> >>>
> >>> >> actually isn't matching the hostname URL.
> >>> >>
> >>> >> Glen
> >>> >>
> >>> >> wonderingWV wrote:
> >>> >> > I understand why it was done, but the problem is I cannot get ssl
> >>>
> >>> with
> >>>
> >>> >> > cxf to work unless the flag is set to true, which I do not want to
> >>>
> >>> do
> >>>
> >>> >> in
> >>> >>
> >>> >> > a production environment.
> >>> >> >
> >>> >> > Glen Mazza wrote:
> >>> >> >> I'm unsure what the problem is. I had done that last March[1]
> >>>
> >>> after
> >>>
> >>> >> >> agreement with the team.
> >>> >> >>
> >>> >> >> Glen
> >>> >> >>
> >>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
> >>> >> >>
> >>> >> >> wonderingWV wrote:
> >>> >> >>> The common name on the cert and the hostName of the url match up
> >>>
> >>> so
> >>>
> >>> >> >>> I not sure why I continue to receive this error. Any advise
> >>>
> >>> would
> >>>
> >>> >> >>> be greatly appreciated.
> >>> >
> >>> > --
> >>> > Daniel Kulp
> >>> > dkulp@apache.org
> >>> > http://dankulp.com/blog
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Http-conduit disableCNCheck
Posted by wonderingWV <jo...@mantech.com>.
If it helps, we use JDK 5 and the problem with the disableCNCheck(false)
first appeared after we updated from CXF 2.0.* to CXF 2.1.*
John
Glen Mazza wrote:
>
> The Metro guide seems to suggest the default verifier is a little bit more
> intelligent than that:
> https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Security__SSL__Workaround
>
> But perhaps this is a result of switching from JDK 5 to 6? Anyway, the
> workaround they have above probably would take care of the user
> configurability functionality you mention in your last sentence below.
>
> Glen
>
>
> dkulp wrote:
>>
>> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
>>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was
>>> *not*
>>> ported to the 2.1 branch?
>>
>> Looking back at the change history, your changes seem to add the
>> "AlwaysTrue"
>> verifier only if DisableCNCheck flag is true. Previous to your change,
>> the
>> AlwaysTrue verifier was always added.
>>
>> With your change, if the flag is false, it now delegates to the JDK built
>> in
>> default verifier which seems to be very stupid and just does "return
>> false".
>> Pretty much useless. :-( Looks to me like we need to find a good
>> HostNameVerifier if the flag is false. Additionally, we probably should
>> allow the user to configure in their own HostNameVerifier somehow.
>>
>> Dan
>>
>>
>>
>>>
>>> Glen
>>>
>>> dkulp wrote:
>>> > Looking at the decompiled source for the "DefaultHostnameVerifier", it
>>> > literally just does a "return false;". Thus, I don't see how it's
>>> > possible
>>> > to do any SSL things with host bound certs right now without the
>>> > DisableCNCheck thing. It looks like we need to write a new
>>> > HostNameVerifier thing that would actually do some level of
>>> verification.
>>> >
>>> > We might be able to grab the one synapse has:
>>> >
>>> >
>>> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/src
>>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
>>> >
>>> > and use that. Someone would need to check that though. That looks
>>> like
>>> > it
>>> > came from the not-yet-commons-ssl project at
>>> > http://juliusdavies.ca/commons-ssl/
>>> >
>>> > There's probably some others floating around if we dig more.
>>> >
>>> > Dan
>>> >
>>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
>>> >> If you can check the CXF source code (I don't have it with me
>>> >> immediately,
>>> >> but search the source code for the error message you're getting to
>>> >> determine the class) -- you can place debugging statements on what
>>> CXF
>>> >> thinks the hostname URL and the CN is to determine why it is failing
>>> on
>>> >> you. Perhaps I made a mistake in my logic someplace--but as no one
>>> else
>>> >> has complained about this yet, I would suspect, for some reason, your
>>> CN
>>> >> actually isn't matching the hostname URL.
>>> >>
>>> >> Glen
>>> >>
>>> >> wonderingWV wrote:
>>> >> > I understand why it was done, but the problem is I cannot get ssl
>>> with
>>> >> > cxf to work unless the flag is set to true, which I do not want to
>>> do
>>> >>
>>> >> in
>>> >>
>>> >> > a production environment.
>>> >> >
>>> >> > Glen Mazza wrote:
>>> >> >> I'm unsure what the problem is. I had done that last March[1]
>>> after
>>> >> >> agreement with the team.
>>> >> >>
>>> >> >> Glen
>>> >> >>
>>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
>>> >> >>
>>> >> >> wonderingWV wrote:
>>> >> >>> The common name on the cert and the hostName of the url match up
>>> so
>>> >> >>> I not sure why I continue to receive this error. Any advise
>>> would
>>> >> >>> be greatly appreciated.
>>> >
>>> > --
>>> > Daniel Kulp
>>> > dkulp@apache.org
>>> > http://dankulp.com/blog
>>
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20467179.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Glen Mazza <gl...@gmail.com>.
The Metro guide seems to suggest the default verifier is a little bit more
intelligent than that:
https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Security__SSL__Workaround
But perhaps this is a result of switching from JDK 5 to 6? Anyway, the
workaround they have above probably would take care of the user
configurability functionality you mention in your last sentence below.
Glen
dkulp wrote:
>
> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was *not*
>> ported to the 2.1 branch?
>
> Looking back at the change history, your changes seem to add the
> "AlwaysTrue"
> verifier only if DisableCNCheck flag is true. Previous to your change,
> the
> AlwaysTrue verifier was always added.
>
> With your change, if the flag is false, it now delegates to the JDK built
> in
> default verifier which seems to be very stupid and just does "return
> false".
> Pretty much useless. :-( Looks to me like we need to find a good
> HostNameVerifier if the flag is false. Additionally, we probably should
> allow the user to configure in their own HostNameVerifier somehow.
>
> Dan
>
>
>
>>
>> Glen
>>
>> dkulp wrote:
>> > Looking at the decompiled source for the "DefaultHostnameVerifier", it
>> > literally just does a "return false;". Thus, I don't see how it's
>> > possible
>> > to do any SSL things with host bound certs right now without the
>> > DisableCNCheck thing. It looks like we need to write a new
>> > HostNameVerifier thing that would actually do some level of
>> verification.
>> >
>> > We might be able to grab the one synapse has:
>> >
>> >
>> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/src
>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
>> >
>> > and use that. Someone would need to check that though. That looks
>> like
>> > it
>> > came from the not-yet-commons-ssl project at
>> > http://juliusdavies.ca/commons-ssl/
>> >
>> > There's probably some others floating around if we dig more.
>> >
>> > Dan
>> >
>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
>> >> If you can check the CXF source code (I don't have it with me
>> >> immediately,
>> >> but search the source code for the error message you're getting to
>> >> determine the class) -- you can place debugging statements on what CXF
>> >> thinks the hostname URL and the CN is to determine why it is failing
>> on
>> >> you. Perhaps I made a mistake in my logic someplace--but as no one
>> else
>> >> has complained about this yet, I would suspect, for some reason, your
>> CN
>> >> actually isn't matching the hostname URL.
>> >>
>> >> Glen
>> >>
>> >> wonderingWV wrote:
>> >> > I understand why it was done, but the problem is I cannot get ssl
>> with
>> >> > cxf to work unless the flag is set to true, which I do not want to
>> do
>> >>
>> >> in
>> >>
>> >> > a production environment.
>> >> >
>> >> > Glen Mazza wrote:
>> >> >> I'm unsure what the problem is. I had done that last March[1]
>> after
>> >> >> agreement with the team.
>> >> >>
>> >> >> Glen
>> >> >>
>> >> >> [1] http://www.jroller.com/gmazza/date/20080329
>> >> >>
>> >> >> wonderingWV wrote:
>> >> >>> The common name on the cert and the hostName of the url match up
>> so
>> >> >>> I not sure why I continue to receive this error. Any advise would
>> >> >>> be greatly appreciated.
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20449170.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote:
> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was *not*
> ported to the 2.1 branch?
Looking back at the change history, your changes seem to add the "AlwaysTrue"
verifier only if DisableCNCheck flag is true. Previous to your change, the
AlwaysTrue verifier was always added.
With your change, if the flag is false, it now delegates to the JDK built in
default verifier which seems to be very stupid and just does "return false".
Pretty much useless. :-( Looks to me like we need to find a good
HostNameVerifier if the flag is false. Additionally, we probably should
allow the user to configure in their own HostNameVerifier somehow.
Dan
>
> Glen
>
> dkulp wrote:
> > Looking at the decompiled source for the "DefaultHostnameVerifier", it
> > literally just does a "return false;". Thus, I don't see how it's
> > possible
> > to do any SSL things with host bound certs right now without the
> > DisableCNCheck thing. It looks like we need to write a new
> > HostNameVerifier thing that would actually do some level of verification.
> >
> > We might be able to grab the one synapse has:
> >
> > http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/src
> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
> >
> > and use that. Someone would need to check that though. That looks like
> > it
> > came from the not-yet-commons-ssl project at
> > http://juliusdavies.ca/commons-ssl/
> >
> > There's probably some others floating around if we dig more.
> >
> > Dan
> >
> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
> >> If you can check the CXF source code (I don't have it with me
> >> immediately,
> >> but search the source code for the error message you're getting to
> >> determine the class) -- you can place debugging statements on what CXF
> >> thinks the hostname URL and the CN is to determine why it is failing on
> >> you. Perhaps I made a mistake in my logic someplace--but as no one else
> >> has complained about this yet, I would suspect, for some reason, your CN
> >> actually isn't matching the hostname URL.
> >>
> >> Glen
> >>
> >> wonderingWV wrote:
> >> > I understand why it was done, but the problem is I cannot get ssl with
> >> > cxf to work unless the flag is set to true, which I do not want to do
> >>
> >> in
> >>
> >> > a production environment.
> >> >
> >> > Glen Mazza wrote:
> >> >> I'm unsure what the problem is. I had done that last March[1] after
> >> >> agreement with the team.
> >> >>
> >> >> Glen
> >> >>
> >> >> [1] http://www.jroller.com/gmazza/date/20080329
> >> >>
> >> >> wonderingWV wrote:
> >> >>> The common name on the cert and the hostName of the url match up so
> >> >>> I not sure why I continue to receive this error. Any advise would
> >> >>> be greatly appreciated.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Http-conduit disableCNCheck
Posted by Glen Mazza <gl...@gmail.com>.
Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was *not*
ported to the 2.1 branch?
Glen
dkulp wrote:
>
>
> Looking at the decompiled source for the "DefaultHostnameVerifier", it
> literally just does a "return false;". Thus, I don't see how it's
> possible
> to do any SSL things with host bound certs right now without the
> DisableCNCheck thing. It looks like we need to write a new
> HostNameVerifier thing that would actually do some level of verification.
>
> We might be able to grab the one synapse has:
>
> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/src/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
>
> and use that. Someone would need to check that though. That looks like
> it
> came from the not-yet-commons-ssl project at
> http://juliusdavies.ca/commons-ssl/
>
> There's probably some others floating around if we dig more.
>
> Dan
>
>
>
>
> On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
>> If you can check the CXF source code (I don't have it with me
>> immediately,
>> but search the source code for the error message you're getting to
>> determine the class) -- you can place debugging statements on what CXF
>> thinks the hostname URL and the CN is to determine why it is failing on
>> you. Perhaps I made a mistake in my logic someplace--but as no one else
>> has complained about this yet, I would suspect, for some reason, your CN
>> actually isn't matching the hostname URL.
>>
>> Glen
>>
>> wonderingWV wrote:
>> > I understand why it was done, but the problem is I cannot get ssl with
>> > cxf to work unless the flag is set to true, which I do not want to do
>> in
>> > a production environment.
>> >
>> > Glen Mazza wrote:
>> >> I'm unsure what the problem is. I had done that last March[1] after
>> >> agreement with the team.
>> >>
>> >> Glen
>> >>
>> >> [1] http://www.jroller.com/gmazza/date/20080329
>> >>
>> >> wonderingWV wrote:
>> >>> The common name on the cert and the hostName of the url match up so I
>> >>> not sure why I continue to receive this error. Any advise would be
>> >>> greatly appreciated.
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20448415.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Daniel Kulp <dk...@apache.org>.
Looking at the decompiled source for the "DefaultHostnameVerifier", it
literally just does a "return false;". Thus, I don't see how it's possible
to do any SSL things with host bound certs right now without the
DisableCNCheck thing. It looks like we need to write a new
HostNameVerifier thing that would actually do some level of verification.
We might be able to grab the one synapse has:
http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/src/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java
and use that. Someone would need to check that though. That looks like it
came from the not-yet-commons-ssl project at
http://juliusdavies.ca/commons-ssl/
There's probably some others floating around if we dig more.
Dan
On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote:
> If you can check the CXF source code (I don't have it with me immediately,
> but search the source code for the error message you're getting to
> determine the class) -- you can place debugging statements on what CXF
> thinks the hostname URL and the CN is to determine why it is failing on
> you. Perhaps I made a mistake in my logic someplace--but as no one else
> has complained about this yet, I would suspect, for some reason, your CN
> actually isn't matching the hostname URL.
>
> Glen
>
> wonderingWV wrote:
> > I understand why it was done, but the problem is I cannot get ssl with
> > cxf to work unless the flag is set to true, which I do not want to do in
> > a production environment.
> >
> > Glen Mazza wrote:
> >> I'm unsure what the problem is. I had done that last March[1] after
> >> agreement with the team.
> >>
> >> Glen
> >>
> >> [1] http://www.jroller.com/gmazza/date/20080329
> >>
> >> wonderingWV wrote:
> >>> The common name on the cert and the hostName of the url match up so I
> >>> not sure why I continue to receive this error. Any advise would be
> >>> greatly appreciated.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Http-conduit disableCNCheck
Posted by Glen Mazza <gl...@gmail.com>.
If you can check the CXF source code (I don't have it with me immediately,
but search the source code for the error message you're getting to determine
the class) -- you can place debugging statements on what CXF thinks the
hostname URL and the CN is to determine why it is failing on you. Perhaps I
made a mistake in my logic someplace--but as no one else has complained
about this yet, I would suspect, for some reason, your CN actually isn't
matching the hostname URL.
Glen
wonderingWV wrote:
>
> I understand why it was done, but the problem is I cannot get ssl with cxf
> to work unless the flag is set to true, which I do not want to do in a
> production environment.
>
>
> Glen Mazza wrote:
>>
>> I'm unsure what the problem is. I had done that last March[1] after
>> agreement with the team.
>>
>> Glen
>>
>> [1] http://www.jroller.com/gmazza/date/20080329
>>
>>
>> wonderingWV wrote:
>>>
>>> The common name on the cert and the hostName of the url match up so I
>>> not sure why I continue to receive this error. Any advise would be
>>> greatly appreciated.
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20445064.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by wonderingWV <jo...@mantech.com>.
I understand why it was done, but the problem is I cannot get ssl with cxf to
work unless the flag is set to true, which I do not want to do in a
production environment.
Glen Mazza wrote:
>
> I'm unsure what the problem is. I had done that last March[1] after
> agreement with the team.
>
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20080329
>
>
> wonderingWV wrote:
>>
>> The common name on the cert and the hostName of the url match up so I not
>> sure why I continue to receive this error. Any advise would be greatly
>> appreciated.
>>
>
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20444881.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Http-conduit disableCNCheck
Posted by Glen Mazza <gl...@gmail.com>.
I'm unsure what the problem is. I had done that last March[1] after
agreement with the team.
Glen
[1] http://www.jroller.com/gmazza/date/20080329
wonderingWV wrote:
>
> The common name on the cert and the hostName of the url match up so I not
> sure why I continue to receive this error. Any advise would be greatly
> appreciated.
>
--
View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20444711.html
Sent from the cxf-user mailing list archive at Nabble.com.