Apache SNI namevhosts always route to first VirtualHost entry

Question

Apache seems to route all https requests to the first <VirtualHost *:443> regardless of SNI matching on ServerName/ServerAlias fields.

Apache is built with SNI
Server version: Apache/2.2.22 (Ubuntu)
Server built: Mar 8 2013 15:53:13
OpenSSL 1.0.1 14 Mar 2012

error.log reports:

Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

Which suggests SNI is working as per http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI (How can you tell if your Apache build supports SNI?)

SSL_TLS_SNI seems to be set appropriately when requested using HTTPS (verified with phpinfo())

Configuration:

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    NameVirtualHost *:443
    Listen 443
</IfModule>

#<VirtualHost *:443>
#       <Location />
#               Order allow,deny
#               Deny from all
#       </Location>
#</VirtualHost>

<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName server.com
        ServerAlias server.com
        DocumentRoot /web/default
        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLCertificateFile /path/server.com.crt
        SSLCertificateKeyFile /path/server.com.key
</VirtualHost>
<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName alias.com
        ServerAlias alias.com
        DocumentRoot /web/default
        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLCertificateFile /path/alias.com.crt
        SSLCertificateKeyFile /path/alias.com.key
</VirtualHost>

Both https://server.com and https://alias.com try to serve the certificate (and content if you disregard the cert warning) from server.com

Similar configuration works fine using HTTP:80 (only change is SSLEngine on and the certificate/key paths)

If I uncomment the first virtual host (restricting HTTPS access to sites that are defined) then I always get a SSL error (even if it is a defined site)

Thanks

EDIT:
Additional flags

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
SSLStrictSNIVHostCheck on
SSLVerifyClient none
SSLProxyEngine off

SSLStrictSNIVHostCheck on so it should only support SNI enabled browsers anyway

apache2ctl -S output:

*:443                  is a NameVirtualHost
         default server server.com (/etc/apache2/sites-enabled/000-default:22)
         port 443 namevhost server.com (/etc/apache2/sites-enabled/000-default:22)
         port 443 namevhost alias.com (/etc/apache2/sites-enabled/000-default:39)
         port 443 namevhost other.com (/etc/apache2/sites-enabled/other:22)

possible duplicate of [Multiple SSL domains on the same IP address and same port?](http://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port) — Jenny D, May 23 '13 at 08:26
I don't think so. It looks like SNI is at least possible in this environment and so far as I can tell it's correctly configured. — Falcon Momot, May 23 '13 at 09:11

score 4 · Accepted Answer · answered May 23 '13 at 17:17

4

Update

So for some strange reason, the problem seems to have resolved itself.
Perhaps it's some sort of strange caching issue or something (though I have apache2ctl stop/start/restart and sudo service apache2 stop/start/restart/reloaded many times and have performed tests locally on the server as well as using several different machines).

Feel free to take this question down or leave it up if it serves as any sort of reference.
Thanks for all the help guys!

answered May 23 '13 at 17:17

arcyqwerty

181
1
1
9

it seems I have the same issue. Still not resolved. Waiting already for >12 hours. https://server.com and https://www.server.com works but problems with https://www.alias.com (although https://alias.com already works) ??? @arcqwerty how long did it take, till the problem had resolved on it's own? – NilsB Jan 20 '14 at 08:02
Looking back at the time between Q+A, I'd say about 10 hours? – arcyqwerty Jul 26 '14 at 07:00
I left my server in this bad state, then came back 5 days after, and all is working fine. apache server was restarted, though (root process is still the original one, but httpd forks were reset). – Mat M Sep 28 '15 at 09:29
1

Maybe this has something to do with browser cache or re-using open connections. – rudimeier Oct 18 '16 at 13:25
2

It seems that restarting does not effect changed SSL settings -- you have to stop apache and then start apache again. – Kay Hidde Dec 19 '16 at 18:15

score 1 · Answer 2 · answered May 23 '13 at 08:12

Your configuration looks OK; The directive SSLEngine On has been included; According to the log message, it looks like the issue comes from the client side.

Not all clients support SNI, however most of them do. It depends on how the SSL negociation is made, by the system (does not work on Win XP then) or by the browser (the version must be recent enough). Look at list of browsers with support of SNI. If you must ensure all clients get access to your websites, you can't use SNI because of these old versions (of the browser or of the system). You would need an IP per ServerName and use VirtualHost $IP_alias:443 for ServerName alias.com and VirtualHost $IP_server:443 for ServerName server.com instead of VirtualHost *:443 for both.

I am pretty sure my browser is correctly sending SNI since I can see it from in the SSL_TLS_SNI variable on the server. I have tried on all of the latest versions of Chrome, Firefox and IE10 and none work. Things look ok when I check my browser SNI support on https://sni.velox.ch/ — arcyqwerty, May 23 '13 at 16:59

KJ7LNW · Answer 3 · 2022-02-25T23:08:44.143

We spent all morning troubleshooting an issue related to this on Oracle Linux 8 (same as RHEL8 / Alma 8 / Rocky 8 / etc). The behavior probably exists on other distributions as well.

If your server's hostname (ie hostname) is the same as the ServerName or ServerAlias in a <VirtualHost> section then the main server sections will rendered instead of the DocumentRoot specified within the VirtualHost. Because of this the SSL and DocumentRoot settings in the <VirtualHost> section will be ignored! It will also load files from /var/www/html/* instead of the <VirtualHost> definition for the same reason.

The fix is to define ServerName www.example.com in the top config file /etc/httpd/conf/httpd.conf (or a /conf.d/foo file) so that the hostname apache thinks it is is not the same as the result of running hostname as defined by the OS at install time (ie, /etc/hostname or HOSTNAME= in your network scripts).

score 0 · Answer 4 · answered May 23 '13 at 07:59

You get an error with the first virtual host because, having not included the SSLEngine on directive, Apache sends an HTTP response without SSL. If you want this kind of functionality you would have to set up another site (possibly with another certificate, unless you reuse an existing domain) for your default vhost, even if all you want to do is return a nice error.

Perhaps check that the certificates are actually different? Your configuration appears correct.

Also, check that there are no other VirtualHost sections listening on port 443. Apache will select the best-matching one, meaning that if anything is more specific to the address that the connection came in on, that entry will take precedence. I don't think this is your problem, though.

Additionally, as a point of interest, what you are seeing from the user side is what would happen if the client didn't support SNI in most cases.

Yes, I expect that error on the first host. The only behavior I want on that is just to disable the default site (the only HTTPS sites that can be accessed are explicitly defined by virtualhosts). In any case, even with it commented, things don't seem to be working. I have verified the certs are different (displaying using `openssl x509 -in cert.crt -text -noout`) though using `openssl s_client -showcerts -connect alias.com:443` seems to give me the server.com certificate. I also have `SSLStrictSNIVHostCheck on` so it should restrict to browsers supporting SNI. See edit for site config — arcyqwerty, May 23 '13 at 17:02
Also, if I comment out the server.com virtualhost, then it passes up the correct certificate for alias.com since it's now the first vhost and set to default — arcyqwerty, May 23 '13 at 17:07

Apache SNI namevhosts always route to first VirtualHost entry

4 Answers4

Related