I’m often asked questions about using certificates with SSL-enabled web servers, mostly centered around hosting multiple sites on the same server. Many times my reply starts out as a series of questions to find out what the person is trying to do, who will be using the various servers, and how much the person is willing to spend.

The simplest answer is that each IP address can be associated with only one SSL certificate. There are, however, subtleties depending on the kind of certificate and the intended audience. Before I give an overview of how browsers, web servers, and SSL certificates interact, let me first define how I use various terms, and give a few examples of how we have various servers set up and what the ramifications are.

Update 25-Nov-2008: I’ve written a follow-up post about using TLS Upgrading which would allow multiple SSL certificates on one IP address, but browsers do not support it.

Update 3-Mar-2009: Another follow-up post about using multiple port numbers.

The terminology used in web hosting can be vague, but I tend to use these terms (examples are for Apache responding to http://www.a.com/ on a host named web1.a.com):

• client – The application connecting to the web server, most often a web browser.
• system/server – Host running the web server application (web1.a.com).
• web server/Apache/httpd – The software running on the server which handles web requests.
• server name – Name of the system (web1.a.com).
• service name – Name that people type into the browser to reach the web servers (http://www.a.com).
• virtual server – Definition block in Apache which declares how to respond to a particular service name on a particular IP address and port. Normally one service name has two virtual servers – one for non-SSL, the other for SSL.
• cert – SSL certificate used to assert to the client that the server really is who they claim to be.
• CA – Certificate Authority who signs a cert, asserting they vouch for the identity associated with the cert. The UWCA is the CA associated with the University of Washington.
• CN – Service name associated with an SSL certificate (http://www.a.com). CN stands for Common Name.

One system, two service names, two IP addresses

The simplest case is to have one system running one web server which answers to two different service names. Let’s call them http://www.a.com and http://www.b.com. The web server needs to be able to respond to requests on two different IP addresses, one for each service name. For Apache, that would mean four different virtual servers, arranged as such:

You can actually put the non-SSL virtual servers on any IP address (or have them answer on multiple addresses) but it’s easiest to make the non-SSL and SSL virtual servers be identically configured as much as possible.

We use well-known CAs for these certs, ones which the clients already trust.

One system, two service names, one IP address, normal cert

There are times when we go ahead and configure multiple SSL services on the same IP address, mostly for development boxes:

Users connecting to the last address will get the warning that the name on the certificate doesn’t match the service name, but are given the opportunity to accept the cert. As mentioned, this type of configuration is mostly used for only development systems, and the developers are expected to recognize the error and verify that it’s really OK for wwwdev.b.com to be using the SSL certificate for wwwdev.a.com. In addition, we normally use UWCA-signed certs, even though not all browsers will have the UWCA cert installed.

One system, two service names, one IP address, wildcard cert

There are times when we really do want to have multiple, valid service names on one IP address. The most visible example is for Webpine, where each of the servers answers as welcome.webpine.washington.edu as well as a system-specific name (such as wp11.webpine.washington.edu). For this service, we use a wildcard cert with the CN being *.webpine.washington.edu, and both service names match. We can also use the same cert on all the Webpine servers. WIldcard certificates are more expensive than normal SSL certs, which is taken into account when choosing to use one.

Anatomy of an SSL connection

The reason why you must have separate IP addresses for each SSL certificate is because of the way SSL is negotiated, combined with how web server processes decide which virtual server a user is requesting. To explain the second part let’s first take a look at a non-SSL request (not complete HTTP request and responses, just the parts relevant to this example):

Client		Server
Send request GET /url HTTP/1.1 Host: www.a.com
		Look for http://www.a.com, send response HTTP/1.1 200 OK content
Display results

When you add SSL into the mix, that negotiation happens first. While this doesn’t include all the parts of the SSL transaction, it does include the server certificate exchange which is the relevant part to this discussion:

Client		Server
Initiate SSL handshake
		Send server’s SSL certificate
Verify SSL certificate, send request GET /url HTTP/1.1 Host: www.a.com
		Look for http://www.a.com, send response HTTP/1.1 200 OK content
Display results

As you can see, the first thing the server does is send the server SSL certificate to the client, which happens before any application data is transmitted, including the HTTP request. This is why you can have only one SSL certificate associated with any particular IP address, because of the SSL connection being negotiated before the web server has any opportunity to ask if a different cert should be used.

Other protocols have methods to request encryption during a connection, such as with the STARTTLS command for SMTP. Such actions are not defined for HTTP however, and I’m guessing they won’t be. Unlike SMTP, HTTP is based on single request/response interchange, rather than a dialog between the client and server. In other words, HTTP would have to be changed to allow multiple requests and responses to give information about the requested service name, enable SSL, then proceed with the full request. An even unlikelier possibility would be to add an HTTP header to request enabling SSL, which would causing the complete request to be unencrypted, including data entered into forms and passwords.