This week's book giveaways are in the AI and JavaScript forums.
We're giving away four copies each of GANs in Action and WebAssembly in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of GANs in ActionE this week in the AI forum
or WebAssembly in Action in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Joe Ess
  • salvin francis
  • fred rosenberger

URL/PATH mismatch ... HostnameVerifier "hostname wrong"

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 "", 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 "", then the connection is refused and I get the following error:

hostname wrong: should be <>

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:*java*%2Bhostnameverifier%2Bfoo%26btnG%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 "".

If I use

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

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 "*" classes. Not the old "com.sun...".

Please help me - I'm desperate,
Legend has it that if you rub the right tiny ad, a genie comes out.
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!