config/8365: SSL VirtualHosts serve the wrong CERTs.

[John Lange <jo...@darkcore.net>]

>Number:         8365
>Category:       config
>Synopsis:       SSL VirtualHosts serve the wrong CERTs.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Sep 19 09:50:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     john.lange@darkcore.net
>Release:        1.3.20 and earlier
>Organization:
apache
>Environment:
Linux bravo 2.4.9 #3 Tue Sep 4 17:29:20 CDT 2001 i686 unknown
>Description:
Yes, I know that SSL doesn't work with VirtualHosts on the same IP (they all require their own IP). This is an issue that I think should be addressed, but aside from that, there is a bit of a bug in its behaviour.

Before I discovered that they needed seperate IPs, I tried to setup two virtual SSL hosts as follows:

--- snip ---
# Virtual host "a"
<VirtualHost 10.1.1.1:443>
  DocumentRoot /var/www/htdocs/a
  ServerName www.a.com
  ...
  SSLEngine on
  SSLCertificateFile /etc/ssl/a.crt
  ...
</VirtualHost>


# Virtual host "b"
<VirtualHost 10.1.1.1:443>
  DocumentRoot /var/www/htdocs/b
  ServerName www.b.com
  ...
  SSLEngine on
  SSLCertificateFile /etc/ssl/b.crt
  ...
</VirtualHost>
--- end snip ---

If you then surf to https://www.b.com, you will indeed get the DocumentRoot /var/www/htdocs/b , but you will get the CERT from /etc/ssl/a.crt .

While I fully understand that it should never be configured in this way, what Apache should NEVER do, is combine the contents of multiple VirtualHost directives in the same client session.

I should also like to mention that not being able to use VirtualHosts with SSL isn't mentioned anyplace in the Apache documentation that I could find and it is totaly non-obvious to someone who doesn't understand the complexities of the SSL protocol (like me) why you can't do this.
>How-To-Repeat:

>Fix:
Making SSL work with VirtualHosts would be the best, but I assume there is some technical reason why this isn't possible or it would have been done before.

Alternatively "apachectl configtest" should test for SSL VirtualHosts on the same IP and report it. "apachectl startssl" should refuse to start if more than one cert is bound to the same IP.

and,

I feel it warrents a mention in the core Apache docs in the <VirtualHost> section so people don't fall into the same trap I did.

Keep up the excellent work :)
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]