Benchmarks Online

Skip Navigation Links


Page One

Campus Computing News

Apple User Group?

JAWS 5.1 is now available

The Role of Blended Learning in the World of Technology

EDUCAUSE

Today's Cartoon

RSS Matters

The Network Connection

Link of the Month

WWW@UNT.EDU

Short Courses

IRC News

Staff Activities

Subscribe to Benchmarks Online
    

WWW@UNT.EDU

Running Multiple Virtual SSL Servers

By Shane Jester, Campus Web Administrator

Something I had struggled with for a long time was the ability to run multiple web servers and have them enabled on both port 80 and 443. The need to encrypt web traffic is growing all the time, especially with regards to passing login credentials, or just viewing sensitive data.  My problem is that I have about one hundred different web servers. Encrypting all of these servers is a problem on two fronts. The first is cost. It would cost about twenty-five thousand dollars a year to have a certificate for every server. Secondly, there is a technology issue with my current web server configuration. Let 's go over both of these hurdles.

Very generally, the way ssl-encryption works on web servers is the client sends a 'Hello' request to the web server. The web server must then send the client its public certificate so that all future communication can be encrypted. From this point on, the client and server can talk over secure channels. This method works fine if you have one web server per IP address. However, as I mentioned before, I have one hundred servers. That's a lot of IP addresses to be monopolizing. I really have little choice but to use name-based hosting on my server. In short, I use one IP address and the apache server differentiates the incoming server requests based on the name of the server.  Ahah! Now you see the problem. How can the server know which certificate to send to the client if it sends the certificate before seeing any relevant data other than 'Hello'? The short answer is, it can't. Since we know that the client will complain if the name of the certificate does not match the hostname that the client is browsing, we are in quite a predicament. So what do we do? We use a wildcard certificate.

A wildcard certificate?

A typical certificate signed by a Certificate Authority (CA) contains the server name that is protected, among other things. For example, a certificate for www.yoursite.com would only work for www.yoursite.com because the name is encoded with the certificate. This is an important part of why we trust certificates. As end-users, we trust that the CA will only sign a certificate that they trust, and therefore we trust. Our browsers are configured to only accept a certificate if the server name we are visiting matches the server name that the CA says it should be. Therefore, it is very hard for a third-party sight to pretend to be someone they are not. 

So what is a wildcard certificate?  It is a certificate that is configured to be used with a domain, as opposed to a specific server. For example, the wildcard *.yoursite.com would not only work for www.yoursite.com, but also www2.yoursite.com, hoopty.yoursite.com, etc. So, is this controversial? A little bit.  There are only a few CA's that even offer this service.  However, they are reputable CA's, which helps with the controversy.  The biggest hurdle is actually browser compatibility.  Most, if not all of the current browsers that support SSL will accept the wildcard certificate, but there can be issues for older browsers.  Still, I offer standard port 80 traffic for any such problems, and I think that the benefits of having all of my servers encrypted outweighs the drawbacks.

So technically how does it work? You configure all of your virtual servers to use the same ssl.key and ssl.crt files which contain the wildcard certificate information. Now when the client requests encryption, it doesn't matter what hostname the client sends. It is the same certificate for any of them.  As long as the browser accepts the validity of the certificate, the response it sends back to the server will be readable by any of the Named Virtual Hosts. At that time, the web server can identify the appropriate named host and respond to the client with the correct data. All of this, is of course transparent to the end-user, and the best-part is the cost. It was less than one-thousand dollars for the wildcard certificate. That's a lot better than twenty-five thousand dollars and hijacking 100 different IP addresses.

For example . . .

So for those of you truly interested, here is an example of an apache httpd.conf file configured for wildcard certificates with Named Virtual Hosts.  I've only included the parts relevant to the wildcard certificates.:

NameVirtualHost 192.168.0.2:80
NameVirtualHost 192.168.0.2:443

<VirtualHost 192.168.0.2:80 192.168.0.2:443>
SSLEngine on
SSLCertificateFile /home/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /home/apache/conf/ssl.key/server.key
DocumentRoot /home/apache
ServerName www.unt.edu
ServerPath /www
<Directory "/home/apache/htdocs">
</Directory>
</VirtualHost>

<VirtualHost 192.168.0.2:80 192.168.0.2:443>
SSLEngine on
SSLCertificateFile /home/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /home/apache/conf/ssl.key/server.key
DocumentRoot /home/apache
ServerName home.unt.edu
ServerPath /home
<Directory "/home/apache/home">
</Directory>
</VirtualHost>

Notice that both Virtual Servers use the same IP address and point to the same certificates.  The Virtual Host directive also specifies that the server is listening on both port 80 and 443. The order is actually important here.  I recently discovered that Macromedia DreamWeaver will not properly perform a webDAV MOVE command if you specify the 443 port first. Go figure.

Questons?

I hope this has at least been interesting.  I realize that I glossed over some of the fine details, but I could have written an entire chapter of a book on this subject and still left out some important information.  My door is always open if you want to discuss it in more detail so feel free to ask me any questions on this topic.

 

Return to top