1

One of our clients receives this error when attempting to access our app. The error message is:

"You attempted to reach xxx.foo.com, but instead you actually reached a server identifying itself as yyy.bar.com. This may be caused by a misconfiguration on the server or by something more serious ... "

The only request in our application that goes to yyy.bar.com is a javascript file in our header (format: https://yyy.bar.com/script.js).

I have been unable to duplicate this issue locally, and no other users are reporting this issue. I'm convinced it is a setting on the client's machine, but after trolling around in Chrome's content settings/certificate management pages, I am unable to figure out what might be causing this to only happen to one specific client.

(Note, all of the client's machines are affected. Maybe its some antivirus configuration, or a problem with their router?)

Mike
  • 11
  • 1
  • Hi Mike. The reason the error is occurring is simple - the browser is making an SSL connection to `xxx.foo.com` and is getting a certificate for `yyy.bar.com`. Are both sites the same - as in, serving the same content, with one configured as an alias of the other in the webserver config? – Andy Smith Nov 15 '11 at 15:59

2 Answers2

1

They're running Chrome on Windows XP, which doesn't support SSL SNI when running on XP because it uses the MS crypto library. (Update: Chrome versions 6.0 and newer on Windows XP do support SNI) It'll reproduce in that situation (or with IE on XP, as well). For a more complete list of browser support for SNI, see this Wikipedia section.

For working clients, they're accessing a resource within https://xxx.foo.com and, because they support SNI, they're getting the xxx.foo.com cert presented by the web server.

For this Windows XP client, it's requesting a resource from https://xxx.foo.com and getting the default certificate for that SSL port; the yyy.foo.com cert, which is invalid for that name.

What's your web server, and how are its SSL listeners configured?

Lekensteyn
  • 6,241
  • 6
  • 39
  • 55
Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • FYI, Chrome on XP does support SNI (from version 6 and up). We're now at version 24 and with Chromiums auto-update functionality you won't encounter any clients running Chrome 5 or lower. Did you mean IE? IE8 on WinXP does not support SNI. Tested up to Safari 5.1 (XP) and it did not work either. The [Wikipedia article on browser support](https://en.wikipedia.org/wiki/Server_Name_Indication#Browsers_with_support_for_TLS_server_name_indication.5B5.5D) is pretty accurate – Lekensteyn Jan 29 '13 at 21:53
  • @Lekensteyn You're absolutely right, just this answer showing its age. I'll update it. – Shane Madden Jan 30 '13 at 00:43
1

Use PORT or IP based virtual hosting. HOSTNAME based virtual hosting is not compatible with using SSL on both hosts.

Chris Nava
  • 1,147
  • 1
  • 7
  • 9