Java Security - URL with PATH/QUERY HostnameVerifier "wrong hostname"

Author

URL with PATH/QUERY HostnameVerifier "wrong hostname"

fritz-bayer@web.de

2005-05-20, 8:58 am

Hello,

I'm using https client-side authentification. Everything is working
fine, as long as I use the CN name (debian.lan) issued in the servers
public certificate.

The hostname "debian.lan" resolves to the ip address "192.168.1.4", and
so does "debian2.lan" and "debian3.lan".

If I try to establish a connection to "debian2.lan", "debian3.lan or to
the ip address "192.168.1.4", then the connection is refused and I get
the following error:

hostname wrong: should be <192.168.1.4>

In order to resolve this hostname mismatch, I create a HostnameVerifier
and initialize my HttpsURLConnection accordingly.

My HostnameVerifier always returns true and writes some information to
standard output so that I can check that it gets called.

And indeed the "verify(String s, SSLSession sslSession)" method gets
called. However, I still get the same error message even though it
always return true!

I have googled a lot and it works for the rest of the world but not for
me. For example this guy had success:

http://groups.google.com/groups?hl=...%
3DSuche

Well, I figured after trial and error that it also works for me, but
only if I leave out the path and/or query of the URL.

The URL I request is "http://debian2.lan/controller?config=1", or for
example "http://192.168.1.4/controller?config=1".

If I use

new URL("http://debian2.lan"); or
new URL("http://192.168.1.4");

then I can connect and the root document is delivered by the webserver.

Can somebody explain to me why I get an error message, if I specify a
path but not if I don't?

It seems strange since my HostnameVerifier always returns true. So the
comparison does NOT depend on the URL anyway.

So there must be another comparision done somewhere, which fails if a
url with a path is provided.

Maybe it's because I'm using client-side authentification, whereas the
rest of the world uses "simple" server authentification only???

For people who really want to dig in this and help me out here there
are some more facts worthwhile to know about my setup:

1. Client side authentification works fine for the URL provided in the
servers public certificate for any path and or query.

2. The HostnameVerifier is installed and gets called. It always returns
true.

3. If I remove the path from the URL I can establish the connection,
for the other hostnames not in the servers certificate.

4. If I remove the HostnameVerfier I can't.

5. I use java version "1.4.2_07" and the "javax.net.ssl.*" classes. Not
the old "com.sun...".

Please help me - I'm desperate,
Fritz

Fritz Bayer

2005-05-21, 8:58 am

fritz-bayer@web.de wrote in message news:<1116585304.575990.184170@g14g2000cwa.googlegroups.com>...
> Hello,
>
> I'm using https client-side authentification. Everything is working
> fine, as long as I use the CN name (debian.lan) issued in the servers
> public certificate.
>
> The hostname "debian.lan" resolves to the ip address "192.168.1.4", and
> so does "debian2.lan" and "debian3.lan".
>
> If I try to establish a connection to "debian2.lan", "debian3.lan or to
> the ip address "192.168.1.4", then the connection is refused and I get
> the following error:
>
> hostname wrong: should be <192.168.1.4>
>
> In order to resolve this hostname mismatch, I create a HostnameVerifier
> and initialize my HttpsURLConnection accordingly.
>
> My HostnameVerifier always returns true and writes some information to
> standard output so that I can check that it gets called.
>
> And indeed the "verify(String s, SSLSession sslSession)" method gets
> called. However, I still get the same error message even though it
> always return true!
>
> I have googled a lot and it works for the rest of the world but not for
> me. For example this guy had success:
>
> http://groups.google.com/groups?hl=...%
3DSuche
>
> Well, I figured after trial and error that it also works for me, but
> only if I leave out the path and/or query of the URL.
>
> The URL I request is "http://debian2.lan/controller?config=1", or for
> example "http://192.168.1.4/controller?config=1".
>
> If I use
>
> new URL("http://debian2.lan"); or
> new URL("http://192.168.1.4");
>
> then I can connect and the root document is delivered by the webserver.
>
> Can somebody explain to me why I get an error message, if I specify a
> path but not if I don't?
>
> It seems strange since my HostnameVerifier always returns true. So the
> comparison does NOT depend on the URL anyway.
>
> So there must be another comparision done somewhere, which fails if a
> url with a path is provided.
>
> Maybe it's because I'm using client-side authentification, whereas the
> rest of the world uses "simple" server authentification only???
>
> For people who really want to dig in this and help me out here there
> are some more facts worthwhile to know about my setup:
>
> 1. Client side authentification works fine for the URL provided in the
> servers public certificate for any path and or query.
>
> 2. The HostnameVerifier is installed and gets called. It always returns
> true.
>
> 3. If I remove the path from the URL I can establish the connection,
> for the other hostnames not in the servers certificate.
>
> 4. If I remove the HostnameVerfier I can't.
>
> 5. I use java version "1.4.2_07" and the "javax.net.ssl.*" classes. Not
> the old "com.sun...".
>
> Please help me - I'm desperate,
> Fritz

Actually I solved the puzzle. It was at a totally different location.
I actually missed to setup the virtual hosts for the additional
domains.

Sponsored Links