Setup: Listen *:443 Listen *:444 https <Virtualhost *:443> ServerName web1.example.com ServerAlias www.example.com SSLCertificateFile ssl/www.crt SSLCertificateKeyFile ssl/www.key ErrorLog logs/error_443.log ProxyPass / http://app1.example.com ProxyPassReverse / http://app1.example.com </VirtualHost> <Virtualhost *:444> ServerName web1.example.com ServerAlias www01.example.com SSLCertificateFile ssl/www01.crt SSLCertificateKeyFile ssl/www01.key ErrorLog logs/error_444.log ProxyPass / http://app2.example.com <Location /> ProxyPassReverse / </Location> </VirtualHost> www.crt CN = www.example.com www01.crt CN = www01.example.com Symptoms: At startup I find in error_444.log: "[warn] RSA server certificate CommonName (CN) `www.example.com' does NOT match server name!?" When opening https://www.example.com:444 I get the www.example.com cert Checks performed: * If I break the cert or key filename in the 444 vhost, apache won't start with an error on the filename so it is trying to open the file * If I switch the order of the vhosts, I get the www01.example.com cert for both vhosts and the CN warning is in the error_443.log file * Both the apache-2.2.4_1 port on FreeBSD 6.2 and the ssl build from apachelounge.com behave the same * When the ServerName is changed on one of the vhosts, the correct cerificate is issued for each vhost
We had the same problem and found a workaround / solution: Append the port to the ServerName directive in each virtual host so you have: ServerName web1.example.com:443 ServerName web1.example.com:444 And it will work like a champ. I think there is still a BUG here - if you specify the certificate CHAIN file different for each vhost you get the right chain file... so it is inconsistent.
Sorry I forgot to mention, Comment #1 applies to Server version: Apache/2.2.6 (Unix), so that workaround is only tested there, and the base issue still exists.
CC myself on FreeBSD related bugs
We're having the same bug with apache httpd 2.2.17 on linux and more: We don't just get a warning, the server refuses to start with this kind of configuration (which worked fine up until now). We also found the same workaround as described in comment #1. While this workaround is working we're having quite a few problems with it: When using mod_proxy with this workaround the ProxyPassReverse-directive substitutes the internal hostnames with the external hostname _and_ the port (as specified in the ServerName-Directive) which causes a lot of hazzle if the internal host isn't ssl-enabled. (We regularly end up with redirects in the form of http://ext-hostname:443/path) I know that this kind of NameBasedVirtualHosting for SSL-Hosts never was officially supported but a lot of people depend heavily on it. My question is now: Is the requirement of the port in the ServerName-directive a bug and can I expect a fix for this or is it working as intended (as part of the changes necessary for server name indication)?
This issue is a side-effect of some mod_ssl internals: mod_ssl caches the private key and certificate across restarts, so the passphrase for an encrypted privkey is not required after first startup. (Actually I don't know why it caches certs as well as privkeys, it seems unnecessary.) This dates way back in mod_ssl history and predates SNI support. Internally two hash tables "servername -> decoded cert" and "servername -> decoded key" are kept, so it is here that the ServerName uniqueness matters. It is certainly correct to be including the ports in the ServerName directive, and arguably a configuration error to not do so. If this leads to any confusion with proxy config perhaps the UseCanonical* settings also need tweaking. There is no obvious way to "fix" this situation; I think ideally it would be caught as a configuration error instead, rather than being silently accepted yet acting in a surprising fashion.
*** Bug 55407 has been marked as a duplicate of this bug. ***
I've reported the same as bug #55047, and while this report here notes that it happens on different ports (which just hit me now)... I only noted that it also happens on the same port (i.e. multiple vhosts on the same IP:port, that just differ in ServerAlias). As shown at #557047, I'd have expected that Apache then simply takes the "first" vhost when the ServerName is given as Host: header... and the corresponding vhost when any ServerAlias is given as Host: header. Of course you may say now that this is just cosmetic, and I could simply change the ServerName of the second vhost (as it won't be ever matched anyway)... it's a bit more... as ServerName is used as default in some places (canonical name and such)... and e.g. people may want to use that to get things like redirects back to the first (canonical) vhost. Anyway... that issue is 6 years old now... is anything ever going to happen?
*** Bug 49995 has been marked as a duplicate of this bug. ***
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.