| Summary: | name-based virtual hosts using SSL | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Johannes L <johannes> |
| Component: | Documentation | Assignee: | HTTP Server Documentation List <docs> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | chuck.mcintyre, johannes, justdave, yehuda+apache |
| Priority: | P4 | Keywords: | PatchAvailable |
| Version: | 2.5-HEAD | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://httpd.apache.org/docs/2.0/en/vhosts/name-based.html | ||
|
Description
Johannes L
2007-02-04 17:42:08 UTC
I, personally, would not make that change until I saw evidence that this works correctly for all major browsers without creating any certificate warnings. Even then, this is not a good place to through in a bunch of details that would confuse an already very confusing issue. It should go in the SSL FAQ. (In reply to comment #1) > I, personally, would not make that change until I saw evidence that this works > correctly for all major browsers without creating any certificate warnings. OK - let's have a look at http://wiki.cacert.org/wiki/VhostTaskForce#head- 7236c4e2c9932ef42056b3ff6d367053081887de Aditionally i've set up one of my boxes with ssl virtual-hosts: you can test them with every major browser, just install the cacert.org root certificate. https://ssltest1.hardenberg-gymnasium.de https://ssltest2.hardenberg-gymnasium.de Anyway it's a good idea, to put it in the SSL FAQ and just link to the FAQ. IMO it would be vaguely irresponsible to present subjectAltName-based certs as a "solution" to NBVH for SSL. This is a nice hack but it's better as an undocumented hack. It only "works" insofar as the SSL configuration used for the configured vhosts must be identical. Users may be duped into thinking they can have different SSL-level security requirements in the various vhosts: they will silently be ignored. (In reply to comment #1) > I, personally, would not make that change until I saw evidence that this works > correctly for all major browsers without creating any certificate warnings. But it does. We use this in production today, I'm surprised this warning suddenly started coming up, it's very obnoxious. Although slightly better than the previous "cn does not match" error messsage. Actually, this is not just a documentation bug, httpd-2.2.4 has now broken functionality that worked perfectly in httpd-2.2.3 - that is name based virtualhosting with wildcard certificates used to work, but now completely does not, should I file a separate certificate for this? This is running under Centos 4.4 (x86_64). (In reply to comment #5) > Actually, this is not just a documentation bug, httpd-2.2.4 has now broken > functionality that worked perfectly in httpd-2.2.3 - that is name based > virtualhosting with wildcard certificates used to work, but now completely does > not, should I file a separate certificate for this? Nevermind - sorry for the spam here, but this is not true, just a documentation thing. While pointing out that name-based virtual hosts can potentially work with alt-subject common names, or wild card certificates, it should also be pointed out that they work with SSL Upgrade (although this is not used in practice with any browser I'm aware of). Mostly a coding thing. This SHOULD be documented. But it should also be stressed that these are all complex solutions and are frequently misconfigured, and the explanation of WHY a 'vanilla' named virtualhost with a 'vanilla' certificate just isn't possible. At least to the level of detail that lets us kick users out of users@ into the documentation at a reasonable starting point for them to solve their own issue. How about a configuration option to disable the warning? Due to the complexities of how it's set up, as you noted, it frequently gets misconfigured. As such, it makes sense to warn by default, to at least get you to look it over. But when you *do* have it configured correctly, it's pretty annoying to continually get error messages in your logs complaining that your setup is broken, when it really isn't. This type of situation is increasingly common in modern setups, and there are almost no browsers left in common usage that *don't* support both wildcard certs and subjectAltName.
On a server with an OV SSL wildcard cert:
>[Tue May 19 13:30:49 2009] [warn] RSA server certificate CommonName (CN) `*.mozilla.org' does NOT match server name!?
>[Tue May 19 13:30:49 2009] [warn] Init: SSL server IP/port conflict: foo.mozilla.org:443 (/etc/httpd/conf/domains/foo.conf:17) vs. bar.mozilla.org:443 (/etc/httpd/conf/domains/bar.conf:11)
>[Tue May 19 13:30:49 2009] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
This was implemented in version 2.2.12 |