Certificate Limitations 

Although certificates lend assistance in providing secure communications over untrusted networks, they're far from perfect. As mentioned in the previous section, the integrity of a certificate depends on keeping the private key completely secure. The compromise of a server's private key equates to communications which may no longer be considered secure.

If loosing a single server's private key is distressing, then the loss of a certificate authority's private key is certainly catastrophic. Recall that certificates, as well as the public key infrastructure (PKI) that supports them, all work on a general system of trust. If a customer trusts a given certificate authority such as Verisign, and Verisign trusts or “vouches” for the authenticity of your server, then the client will inherently trust your server. Just as in the single server scenario, the mechanics behind this system of “vouched trust” hinge on keeping the CA's private key highly secure. If a hacker was to compromise the CA's private key, she may use the private key to engage in various menacing activities, including signing certificates for illegitimate sites, or even decrypting previously recorded encrypted communications. Once a CA's private key is compromised, all clients of that CA must have a new public key re-issued. As you can imagine, having to immediately re-issue public keys to several hundred thousand or more clients is no simple task.

One of the biggest gotchas related to certificates lies not within the X.509 certificate standard itself, but rather one of the most prominent certificate applications-- the Secure Socket Layer protocol. As any web server administrator will explain, one of the woes associated with hosting SSL-enabled web sites is the requirement for each site to have its own unique IP address. Unlike standard (non SSL) virtual hosts which may reside on one server and ultimately share a single IP address, SSL sites do in fact require dedicated IP addresses. In short, SSL establishes a secure communications channel using what is known as a “handshake” prior to exchanging any HTTP-based data. Unfortunately, web browsers connect to the server's IP address, then ask for a specific web site using an HTTP-specific header known as a “host header name.” The key point here is that the web site is selected through HTTP-specific request. Somewhat like the chicken-or-the-egg dilemma, SSL forces the client to build a secure channel prior to transmitting any HTTP data. Yet, name-based virtual hosts force the client to use HTTP headers to select the specific web site to communicate with. Currently, the only viable solution to this quandary is to allocate a dedicated IP to each SSL-enabled web site. Such requirements may lead to added administrative overhead, and possibly exhaustion of IP address space allocation.

As if managing SSL-enabled web sites and securing private keys wasn't hard enough, one of the most challenging tasks for any network administrator has got to be deploying a proxy server in a certificate-enabled environment. The very essence of public key cryptography is to provide secure communications over untrusted networks. Preventing “man-in-the-middle” and other various eavesdropping attacks was one of the primary design goals behind public key cryptography. Conversely, the goal of a proxy server is to sit in between two communicating parties and inspect (and possibly alter) the traffic for various reasons. So how does one build a network which implements certificates to prevent eavesdropping, yet mandates the use of an application proxy? The simple answer is, you can't. If a client is using SSL to communicate with a server, it is impossible for a third-party to decrypt the traffic. As only the server has a copy of the highly secretive private key, the proxy would never be able to decrypt the communications. Attempting to alter the encrypted traffic would result it in invalid checksums on the server end, and communications would come to a grinding halt.

While deploying a proxy between an external SSL-enabled parties is impossible, several viable alternative designs do exist. For reverse proxies, one may place a copy of the private key on the proxy itself, thus enabling the proxy to decrypt and inspect inbound traffic. As for traditional proxies, you may opt to deploy a type of “double-tiered” communications model. Rather than having only one communications channel between client and server, you have one communications channel between client and proxy, then another channel between proxy and server. Although such a system may introduce performance ramifications (not to mention immense cost and complexity), it does provide end-to-end security with the ability to inspect application data.

Finally, it's important to note that certificates do not last forever. Your CA will assign a period of validity to your certificate which typically ranges between one and five years. Once your certificate has reached its predefined end-of-life date, it will be considered “expired” and no longer valid. Unless renewed, customers connecting to your server will receive certificate errors.