Certificate Distribution Proves a Vexing Problem

Computerworld - I'm at the beginning of a project to rework my company's homegrown public-key infrastructure (PKI). Specifically, we want a system that will let us reissue keys as they expire without inflicting a lot of pain on users and administrators. We're looking at several different products. But even when we find the right certificate authority, we'll still need a way to get the right keys to the right users. This week, I'm working on coming up with a better certificate-delivery mechanism.
Just E-Mail It
Historically, we've e-mailed certificates to users in an encrypted attachment. But now, with everyone worried about e-mail-borne viruses and worms, we have to send these attachments through firewalls, and that's very difficult. We need to secure e-mail standards or use another method.
We decided to evaluate several different approaches and set up conference calls with vendors to discuss product details.
We had a useful discussion with one firm that offered a secure e-mail package. But we decided against this - or any vendor's - secure e-mail product. Why? Some of our customers use Secure Multipurpose Internet Mail Extensions, some use Pretty Good Privacy, and the rest use horrible, proprietary bolt-ons. We don't want to be the ones to synchronize it all.
As we evaluated possible distribution methods, it became clear that a Windows-based protected Web server was the right answer. With it, our users could authenticate to the Web site using a passphrase that we mail to them, and then our Secure Sockets Layer-enabled Web site would let them download their certificates safely and easily.
We bought a few applications that let us check who the users are and securely deliver the certificates to them. Unfortunately, these applications require a Windows 2000 system running Microsoft's Internet Information Server (IIS) and a SQL Server back end, and we don't normally support those in our externally facing infrastructure. We certainly don't have a Windows support team to ensure that these servers are kept up to date and monitored.
This opened up another problem: Given the sheer number of IIS Web servers out there, we knew our servers would be the target of many attacks. There are many known buffer overflow problems, and we expect a continuous stream of patches for new and old vulnerabilities.
To implement this system successfully and at a reasonable cost, we needed to find a way to protect ourselves from attacks during the time after a vulnerability is discovered and before our administrators are able to roll out patches - without leaving ourselves wide open