Bug 41537 - name-based virtual hosts using SSL
Summary: name-based virtual hosts using SSL
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P4 minor (vote)
Target Milestone: ---
Assignee: HTTP Server Documentation List
URL: http://httpd.apache.org/docs/2.0/en/v...
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2007-02-04 17:42 UTC by Johannes L
Modified: 2010-03-01 10:21 UTC (History)
4 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes L 2007-02-04 17:42:08 UTC
It's possible to use name-based virtual hosts wit SSL, with so called
multi-domain certificates.

The documentation, found at
http://httpd.apache.org/docs/2.0/en/vhosts/name-based.html, contains:
"Name-based virtual hosting cannot be used with SSL secure servers because of
the nature of the SSL protocol."

It should be corrected to:
"Name-based virtual hosting over SSL can only be used with so called
multi-domain certificates. More information can be found at
http://wiki.cacert.org/wiki/VhostTaskForce or
http://wiki.cacert.org/wiki/VhostsApache or
http://www.positivessl.com/ssl-certificate-products/ssl/multi-domain-ssl-certificate.html
"
Comment 1 Joshua Slive 2007-02-06 07:24:20 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.
Comment 2 Johannes L 2007-02-14 19:45:05 UTC
(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.
Comment 3 Joe Orton 2007-02-15 08:02:05 UTC
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.
Comment 4 Chuck McIntyre 2007-02-20 19:20:43 UTC
(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.
Comment 5 Chuck McIntyre 2007-02-20 19:28:42 UTC
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).
Comment 6 Chuck McIntyre 2007-02-20 19:35:45 UTC
(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.
Comment 7 William A. Rowe Jr. 2007-02-26 01:14:23 UTC
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.
Comment 8 David Miller 2009-05-19 13:41:11 UTC
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!!
Comment 9 Igor Galić 2010-03-01 10:21:29 UTC
This was implemented in version 2.2.12