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
