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 mod_gnutls.c>
    NameVirtualHost *:443
    Listen 443

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?


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

| improve this answer | |
  • For using IP-based virtual hosts, you should be able to put the IP address in the virtual host declaration, e.g. <VirtualHost>. – Bruno Jan 15 '12 at 21:59
  • Thanks for the extensive explanation Bruno. One thing I dont understand with IpBased VirtualHosts, is what IP do I put in there? The ip of the domain that is pointing to this server? – Houman Jan 15 '12 at 22:13
  • This should be the (external) IP address(es) of your server. This will be provided to you by whoever provides you with the internet connectivity to this server. If you're using a hosting company, they may have an option (probably with a fee) to use a second IP address on the server. You'll also need to figure out how to set up your server with multiple IP addresses (e.g. IP aliasing on the same interface) in this case (it depends on how much admin they do for you). If your hosting company (or ISP if you're hosting yourself) doesn't provide this, the cert with multiple names is probably better. – Bruno Jan 15 '12 at 23:43

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

| improve this answer | |
  • 3
    Both SSL and TLS, as used in HTTPS, are initiated before any HTTP traffic is sent (and all HTTP traffic happens over them). What's "new" isn't the usage of TLS, it's the availability of the Server Name Indication extension (from TLS 1.0, but I don't think it was retrofitted for SSL 3.0). No need for GnuTLS (over OpenSSL). GnuTLS is just an implementation of SSL/TLS, like OpenSSL: both should support SSLv3 and TLS 1.0 (and some more recent versions), as well as the SNI extension. – Bruno Jan 15 '12 at 21:23
  • Thanks guys for clarification. So in order to make it work for everybody I need to stop using NameVirtualHost and use IP based one. I have googles for the latter and found this tutorial: tinyurl.com/3vzfmnd but it isn't explained very well. Do you guys know of any good tutorial for ip-based virtual hosts? – Houman Jan 15 '12 at 21:46
  • Thanks Bruno =), And Kave: The basics are easy: in stead of using <Virtualhost *:443> you replace the * with an actual IP address <VirtualHost> for example. If you want this to you will need access to multiple IP addresses and make your server / apache listen to them. I haven't found a good tutorial yet. – Filipe Spencer Jan 15 '12 at 21:59

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

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.

| improve this answer | |

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.


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

| improve this answer | |
  • 1
    This seems more of a review article than an answer, and arguably it's a bit of a ranty one, too. Do you have a new answer for this question, or do you just think the question's out of date? – MadHatter Mar 2 '16 at 21:19
  • With the twilight of deprecated browser usage, the matter of support for such browsers wanes. Still, some sysadmins feel the need to support such vulnerable applications so that their customer's websites are visible to those running these outdated browsers. The OP's question was one of, "How do I support name based virtual hosting over SSL for [deprecated] browsers like IE on XP, etc., and as such, the answer chosen for the actual answer does not address this issue - it leaves only IP virtual hosts as the solution, which is not what the OP had to implement at all. – tallship Mar 3 '16 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.