How to setup Apache NameVirtualHost on SSL?

Question

I would like to set the A record of two DNS to point to my Ubuntu intance. Apache should then read the domain name accordingly and point the incoming request to the right physical path.

I have set everything up This is the content of /etc/apache2/ports.conf

It worries me that WinXP users can't access my SSL site according to the comment below, so how should I do it differently?

NameVirtualHost *:80
Listen 80

<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>

<IfModule mod_gnutls.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>

Majority of people have WinXP and Internet Explorer, so thats a bit concerning. How can I set the SSL up differently so that its working for everybody?

Answer 1

Using multiple host names on the same Apache Httpd server (and any HTTPS server for that matter) poses two problems:

• For the connection to be secure, the client must first verify the server certificate.
• If there are multiple certificates available to the server, the server must be able to get which certificate to pick from the client request.

HTTPS is HTTP over SSL/TLS: the SSL/TLS handshake, which establishes the secure tunnel, is started by the client just after creating the TCP connection, before any HTTP exchange is made. All the subsequent HTTP traffic of the HTTPS exchange is done over this SSL/TLS connection.

The server certificate is sent by the server as part of the SSL/TLS handshake. The verification process relies on (a) verifying the certificate is trusted and (b) verifying it was issued for the server the client intended to contact. There are more details in this answer on StackOverflow.

In HTTP, the requested host name is sent in the HTTP Host header. This is how name-based virtual hosts work: the dispatch is done based on the Host header internally within Apache Httpd.

However, the HTTP Host header isn't available to Apache Httpd before the SSL/TLS has completed successfully. Thus, it's not available before the server certificate has been sent.

There are two ways to help Apache Httpd choose which certificate to use during the handshake, without relying on any HTTP traffic:

• Using a certificate per IP address/port combination. This is the traditional way.
• Using the Server Name Indication extension of SSL/TLS, send during the SSL/TLS handshake, which establishes the secure tunnel. The problem with this option is that not all browsers support it. In particular, it's not supported on any version of IE on XP (and some mobile browsers, I think).

If you cannot use SNI or have multiple IP addresses on your server, you could use a certificate that is valid for all the host names that you want to serve. This can be done by using:

• a certificate issued to a wildcard name (but their usage is discouraged), or
• a certificate with multiple Subject Alternative Name DNS entries. This should be your preferred option.

If you really want to try SNI, it should work with a recent-enough version of Apache Httpd 2, using a recent-enough version of OpenSSL (if using mod_ssl as provided with the main code base). This is documented here: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Answer 2

The SSL warning is about name-based SSL sites. Traditional SSL encrypts the connection before HTTP traffic is sent, it encrypts the TCP connection rather then the HTTP session, if I'm not mistaken. Since virtual hosts are selected within the HTTP protocol, and the server needs to set up a secure connection before http is utilized, you are able to choose only one certificate per IP/port combination. By default, the defualt ssl site.

This changed because you now can use TLS (gnutls) for encryption, which is in fact 'new version' of SSL and allows name-based encryption. This is however not supported on older operating systems and browsers, like Windows XP.

It is possible if you use firefox or chrome on XP instead of IE it works just fine.

If you want it to work anytime, configure multiple IP's and/or ports for SSL versions of websites. If you have only one website that needs SSL no further configuration is neccesary

Edit: question changed as well

Answer 3

Another possibility if you have only one IP for multiple SSL domain names is to configure just the one <VirtualHost _default_:443> for a default document root and inside it use a RewriteRule for each domain name that needs to be served from a different document root. For example:

<VirtualHost _default_:443>

    DocumentRoot /var/www/https_one

    ... 

    RewriteEngine On

    RewriteCond %{HTTP_HOST} ^https_two\.example\.com$
    RewriteRule (.*) /var/www/https_two/$1

    RewriteCond %{HTTP_HOST} ^https_three\.example\.com$
    RewriteRule (.*) /var/www/https_three/$1
</VirtualHost>

Since mod_rewrite runs when the headers are already sent this pretty much circumvents the problem of identifying the HTTP Host in the SSL handshake phase. You'd still need a certificate that is valid for all domain names though, assuming that you don't want your visitors prompted to accept a security exception by their browser.

Answer 4

Although the answer provided by @Bruno above indeed addresses the hows and whys, it leaves the question as to how to setup up SSL/TLS enabled name based virtualhosts with a less than workable solution - deferring instead to someone binding (or purchasing from their hosting provider) additional IP addresses for their machine and depending, also altering the listen on parameters for httpd.conf

IOW, there isn't a solution in @Bruno's answer - you must use IP based virtualhosts.

@ocsarjd, on the other hand, does address how to provide support for name based virtual SSL hosts, in addition to a work around for people who are insistent upon running say, IE on XP.

Using:

<VirtualHost _default_:443>

and then mod_rewrite provides support for browsers unable to take advantage of SNI, and therefore, no one has to purchase and/or bind additional IP addresses to the server for Apache to listen on for connections in an IP based virtual host method.

Ironically, @Bruno's answer does cover all of the reasons how and why these negotiations take place and how the obsolete browsers are unable to negotiate the proper incorporation of name based SSL virtual hosting on an Apache server.

As it has been some time since the OP posed this question, I would recommend NOT accommodating these obsolete browsers, because this is a choice that the person at the client end has made to operate insecure software, which in my opinion, is simply someone to be ignored....

That having been said, a default SSL virtual host with information akin to a custom 404 page telling the visitor that they are operating an insecure browser client would actually be in order here for a few more years, because there will surely be people who refuse to stop using a version of IE that has received no patches since XP was EOL'd, and all (so-called) 'modern' browsers (IE/Edge, Firefox, Chrome/Chromium, Opera, Safari) will accommodate the features of name based virtual hosting over HTTPS via SNI.