HTTPS Virtual Hosts in Apache

11 June 2012

Running multiple web sites that allow HTTPS connections on the same Apache httpd server is problematic. Typically, HTTP virtual servers (the individual web sites) use named virtual hosting, where the virtual host which serves the site is chosen based on the host name specified in the HTTP Host header. Named virtual hosting does not work for HTTPS because the server cannot interpret the Host header until the connection has been made, and making the connection requires the completion of the SSL encryption handshake used by HTTPS; SSL certificates (without extensions) can only have a single server host name as their subject, and thus the certificate and connection will only work for a single host name. As a result, the named virtual hosting mechanism never has a chance to operate on the incoming connection and the only remaining way to host multiple sites is to add multiple IP addresses to the host and use IP-based virtual servers.

One option for dealing with HTTPS virtual hosting is a modification to the SSL protocol known as Server Name Indication. This modification includes the host name the client is attempting to connect to in the SSL connection request, allowing the server to know which SSL certificate to use for the connection. The Apache wiki has a page on SSL with Virtual Hosts using SNI. Unfortunately, the protocol update necessary must be made on both the client and server sides and support for this change still appears to be sketchy; Wikipedia says, "As of 2012 there are still many users of browsers that do not support SNI[citation needed].".

There are other options, however, which require only special SSL certificates and server configuration.

The keys to supporting multiple sites using HTTPS and name-based virtual hosting are to use either wildcard names (specified in RFC2818) or the x509 version 3 certificate (specified in RFC3280) subject alternative names extension. I have not used wildcard names, although they allow one certificate to work for any number of hostnames below a given domain: *.example.com would allow any of a.example.com, foo.example.com, or elbow.example.com, but would not work for right.elbow.example.com or www.google.com. Wildcard certificates are much more expensive than standard certificates and are not administratively available in my particular work domain.

Subject alternative names, a.k.a. SubjectAltNames, allow a certificate to list a number of host names for which it is valid. For example, a single certificate with www.example.com as its (single) subject could list www.example.com, www.example.org, and webapp.example.com as alternate names; the certificate would be recognized as valid for any of those host names.

Generating subjectAltName certificates

Convincing openssl to generate a certificate or certificate signing request requires changes to the openssl.conf file:

  1. Enable extensions:

    [req]
    req_extensions = v3_req
    
  2. Add a v3_req section including the subjectAltName field:

    [ v3_req ]
    subjectAltName = @alt_names
    
  3. List the host names in the proper format in the v3_req section:

    [alt_names]
    DNS.1 = web.example.com
    DNS.2 = dspl.example.com
    DNS.3 = nprop.example.com
    DNS.4 = webdir.example.com
    DNS.5 = hpps.example.com
    DNS.6 = remoteuser.example.com
    DNS.7 = esm.example.com
    DNS.8 = etsapprover.example.com
    DNS.9 = ep.example.com
    DNS.10 = cas.example.com
    DNS.11 = wat.example.com
    DNS.12 = ned.example.com
    

For more information, see Creating a Certificate With Multiple Hostnames and a discussion from the OpenLDAP list.

Configuring virtual hosts

There are at least two ways of configuring httpd to handle multiple web sites with a single certificate. One resembles the normal name-based virtual hosting (with the VirtualHost directive and everything); the other is the one I have used.

The key to both of these is that the certificate you present when opening the connection must match all of the possible host names, either by being a wildcard certificate or containing the appropriate SubjectAltNames.

Name-based virtual hosts

In the first, set up httpd to listen on port 443 and to present the certificate with the SubjectAltNames:

NameVirtualHost *:443
Listen 443
SSLEngine On
SSLCertificateFile /etc/....
SSLCertificateKeyFile /etc/.....

Then, add all of the necessary named virtual hosts normally, making sure that they are listening on port 443:

<VirtualHost *:443>
  ServerName foo.example.com
  # Configuration for web site foo.example.com
</VirtualHost>

<VirtualHost *:443>
  ServerName bar.example.com
  # Configuration for web site bar.example.com
</VirtualHost>

Now, I have not actually done this, but it looks like it should work. It is described on the Apache wiki.

Mod_rewrite virtual hosts

What I have done is used subjectAltName certificates with a reverse proxy httpd configuration, where each of several applications in an application server appears to have its own server name:

Listen 443
SSLEngine On
SSLCertificateFile /etc/....
SSLCertificateKeyFile /etc/.....

RewriteEngine On

RewriteCond %{HTTP_HOST} ^foo\..*$
RewriteRule ^(.*) http://127.0.0.1:8090/foo-2.2$1 [P,L]

RewriteCond %{HTTP_HOST} ^bar\..*$
RewriteRule ^(.*) http://127.0.0.1:8090/bar-2.2$1 [P,L]

The virtual hosting is handled by the combination of the RewriteCond and RewriteRule directives; the Cond ensures that the request is for the appropriate virtual host and the rule packs the request off to the appropriate location on the back-end server.

So far, this has not presented any problems at all.

Issues

There are a couple of caveats: when present, the subject alt names list may or may not replace the actual subject of the certificate; if a host name is present only in the certificate subject field and is absent from the subjectAltName field then the browsers I have tried will not recognize the certificate as valid for the host name. Not all clients support SubjectAltNames; see SAN Certificates: Subject Alternative Name. Further, there are possibly some security issues with multi-host certificates. Check Phishing for Confirmations for details.

gloria i ad inferni
faciamus opus

Return to Top | About this site...
Last edited Mon Jun 11 18:57:41 2012.
Copyright © 2005-2016 Tommy M. McGuire