Bug 42923 - vhost certificate NOT overriding cert from the _default:443_ vhost
Summary: vhost certificate NOT overriding cert from the _default:443_ vhost
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.52
Hardware: Other Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2007-07-17 20:15 UTC by UQ Business School IT Team
Modified: 2018-11-07 21:08 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description UQ Business School IT Team 2007-07-17 20:15:24 UTC
Hi

I run into a problem which to do with the handling of SSL certificates which I
believe is a bug.  In a nutshell, the certificate info from the _default:443_
vhost is "leaking" onto the vhost bound to the machine's primary IP address (ie.
eth0). This is not happening on secondary IP addresses, including IP aliases
attached to eth0.

Now for specifics:

I'm using RedHat 4 which uses Apache 2.0.52, running under VMWare ESX 3.
The server has 2 NICs, and eth0 has a couple of IP aliases (ie. eth0:1, eth0:2)

The default RH config file (/etc/httpd/conf/httpd.conf) has the "Listen 80"
option, and uses the "Include" directive to include all the files matching
/etc/httpd/conf.d/*.conf.

One of these files is /etc/httpd/conf.d/ssl.conf,  which defines a virtual host
"_default_:443".  This vhost references the files
/etc/httpd/conf/ssl.key/{server.key and server.crt}  (which are supplied by
default and identify the host name as "localhost.localdomain").  The ssl.conf
file also has a "Listen 443" directive. 

If I access any of the https sites on any of the machines IP addresses, I get
the _default:443_ certificate and the pages which are referenced under the
_default:443_ vhost's DocumentRoot.  This is what is to be expected.


I've edited /etc/httpd/conf/httpd.conf and the last lines are now:
    Include /etc/local/httpd/conf.d/*.conf
    Include /etc/local/httpd/conf.d/vhosts/*.conf

The /etc/local/httpd/conf.d files are generic settings for the whole server, the
"vhosts" sub-directory contains a separate config file for each vhost.  The
vhost files are pretty standard, along the lines of:

<VirtualHost    a.b.c.d:443>
        ServerName      myserver.domain.org
        CustomLog       /var/log/httpd/servername-ssl/access_log  combined
        ErrorLog        /var/log/httpd/servername-ssl/error_log

        DocumentRoot    /data/vhosts/servername-ssl/html

        SSLEngine               On
        SSLCertificateKeyFile
"/data/vhosts/servername-ssl/conf/myserver.domain.org.key"
        SSLCertificateFile
"/data/vhosts/servername-ssl/conf/myserver.domain.org.crt"

        Include                 /data/vhosts/servername-ssl/conf.d/*.conf
</VirtualHost> 

Ok.  Here's where it gets weird.  

If the IP address in the above vhost is the machine's primary address (ie.
eth0), then when I access it, I get the "localhost.localdomain" certificate.
This seems to have leaked from _default:443_ vhost.  
However the data served is from the above vhost's DocumentRoot, (not from
_default:443_'s). And the request is logged to the log file specified in the
above vhost.   So Apache is definitely finding this vhost, and using it, except
for the certificate data.

Now if I change the IP address in vhost to any of the host's other IP addresses,
then everything works as it should - it returns the vhost's certificate, uses
the vhost's document data and logs to the vhost's log file.

I initially had "NameVirtualHost a.b.c.d:443" options in the vhost config files,
but I commented them out.  
I've tried specifying multiple vhosts, listening on eth0 and other addresses, or
only on other addresses.  I've tried changing the load order and so on, but it
hasn't affected this. The results are consistent. The only problem I can find is
when the address specified is eth0.  

I apologise for the length of this report, but this is kind of hard to summarise
concisely.

cheers
/\ndy
Comment 1 Eric Covener 2007-07-18 04:44:21 UTC
you can't provide different certificates on two vhosts using the same ip:port
combination.

Without taking some extraordinary measures, forget about using SSL on name-based
vhosts.

http://wiki.cacert.org/wiki/VhostTaskForce
Comment 2 UQ Business School IT Team 2007-07-18 17:45:11 UTC
Hi Eric

Thank you for your response.

However I am not using the same IP:port combo for different vhosts.  
Each vhost is on a unique IP addresses.  Perhaps this was not entirely clear in
my original message.


Let me attempt to spell this out further, with an Example.

If the machine has
 * eth0 configured as  a.b.c.1 
 * eth0:1 configured as a.b.c.100
 * eth0:2 configured as a.b.c.101

If Apache is running with the default RedHat default config - ie. with only the
_default_:443 Vhost (and a Listen 443) -  then here's what I see

https://a.b.c.1/  -> _default_:443 certificate, document root and logs.
https://a.b.c.100/  -> _default_:443 certificate, document root and logs
https://a.b.c.101/  -> _default_:443 certificate, document root and logs

This is correct behaviour in my opinion.  There is no specific match, so Apache
uses _default_:443.


Ok.  I then make my own vhost, which is listening on a.b.c.1:443. 
Let's call this vhost "V1", to keep this next section readable.

Note that this address is the address of the interface "eth0".

I then try and access the web sites, and here's what I see this time:

https://a.b.c.1/  -> _default_:443 certificate, but V1's document root and logs
https://a.b.c.100/  -> _default_:443 certificate, document root and logs
https://a.b.c.101/  -> _default_:443 certificate, document root and logs

The behaviour for  https://a.b.c.1/ is, IMHO, a bug.  I am getting the cert for
_default_:443, not for the vhost I'm referring to as V1.


Okay. Now lets CHANGE the IP address in the vhost config.   This means that
there are still only 2 vhosts, the _default_:443 one, and my locally added one.  
Except this time instead of a.b.c.1:443, my local vhost is on a.b.c.100:443.
For readability, let's call this version of my local Vhost "V100".  

Note again, that this IP address corresponds to an IP alias, not eth0.

https://a.b.c.1/  -> _default_:443 certificate, document root and logs.
https://a.b.c.100/  -> V100's certificate, document root and logs
https://a.b.c.101/  -> _default_:443 certificate, document root and logs

Everything is fine.  This is what we should expect. 


Okay, so now I change the vhost over to IP address a.b.c.101, and try again. 
Call this vhost V101, for the sake of readability.

https://a.b.c.1/  -> _default_:443 certificate, document root and logs.
https://a.b.c.100/  -> _default_:443 certificate, document root and logs
https://a.b.c.101/  -> V101's certificate, document root and logs

Again. This all seems fine.


If instead of one local vhost, I make 2; the ones I referred to as V100 and
V101, then they both work fine.  The only one which does not work correctly, is
"V1".

I can change the order in which the vhosts are defined.  It makes no difference.

Although Apache is serving the content from V1's DocumentRoot, and writing to
V1's access log and error log, it does not present V1's Certificate. It only
ever presents the cert from _default_:443.

Perhaps I am mistaken, but I this to me is a bug.  

I've tested this on multiple machines all running the same OS and httpd.  They
have different IP addresses.  The only thing which is common, is that cert for
_default_:443 always leaks onto the vhost on eth0.  The other ethernet
interfaces (including IP aliases) are always fine.

I hope that this helps clarify the situation.

cheers
/\ndy
Comment 3 Y K 2010-05-05 17:06:17 UTC
I see this bug is over 2 years old.
I am having the same problem on Apache/2.2.15 (Win32).
Comment 4 Eric Covener 2010-05-05 17:48:39 UTC
(In reply to comment #3)
> I see this bug is over 2 years old.
> I am having the same problem on Apache/2.2.15 (Win32).

If you think you're suffering from a bug, include your verbatim httpd -S output, a snippet of your config, and describe which cert and content you see.
Comment 5 Y K 2010-05-06 00:11:07 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I see this bug is over 2 years old.
> > I am having the same problem on Apache/2.2.15 (Win32).
> 
> If you think you're suffering from a bug, include your verbatim httpd -S
> output, a snippet of your config, and describe which cert and content you see.

I am having a lot of trouble replicating this right now.
Someone decided to re-image the server we were having that problem with. I will need to go back and figure out what the buggy settings were.

In my initial comment, I thought I might save space by not describing the problem almost word for word from comment 2.
(The only difference from that comment is the IPs, even though this is a Windows server, I will use the linux notation:)
eth0 -> 192.168.118.50
eth0:1 -> 192.168.118.52
eth0:2 -> 192.168.118.53

I defined all of my SSL vhosts in C:\Webserv\Apache2.2\conf\extra\httpd-vhosts.conf

DNS:
myserver.domain -> 192.168.118.50
site1.domain -> 192.168.118.50
site2.domain -> 192.168.118.52
site3.domain -> 192.168.118.53

https://*.domain (with no vhosts) -> cert and content of __default__:443
vhosts for site2 and site3 work fine
https://site1.domain -> cert of vhost __default__:443 and content of vhost site1.domain:443

I will supply the rest as soon as I can get it.
Comment 6 William A. Rowe Jr. 2018-11-07 21:08:20 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.