Does Your Company Use a PKI Solution?

punkrokk asks: "I am doing an Independent study of the feasibility of a Microsoft Certificate Services PKI in a distributed company. So far, it appears from my research that MS has the best supported implementation of a X.509 based PKI solution, for the Windows environment. While there are a few major weaknesses in a X.509 Public Key Infrastructure, one of which being Certificate Revocation Lists, using one is better than nothing. You do get a tangible security benefit, in addition to doing switch port authentication, and VPN quarantines. The problem is the cost of implementation is pretty steep, from the planning side. What do you guys do for dual factor authentication? Has anyone had Verisign sign their Certificate Authority? If you have implemented a MS Certificate Service infrastructure, I would appreciate your comments."

Comments

I am doing a 802.1x authication test lab now

[notanic]

Hi, I am going through Microsoft's 'Step-by-Step Guide for Setting Up Secure Wireless Access in a Test Lab' now, and the solution does not seem very simple. To setup 802.1x you need: - Active Directory (usually, but you could use standalone IAS) - IAS service (MS's RADIUS server) - Access policy on IAS setup for 802.1x - Certificate server, with computer certificate issued to the IAS server - AP and wireless client that supports WPA Enterprise. - Patches on the client to give operating system support (e.g post sp2 patch to support WPA2). Then, when you configure the client, and connect it seems kind of clunky with popup's for entering credentials and others to verify certificates. Do third party solutions make it simpler, or just outsource the Certificate Services part?

Re:other PKI options

[KagatoLNX]

Actually, I would recommend something obliquely related to the parent post. FWIW, I have implemented a few of these before, although our consulting firm is small enough that we individually manage GPG keys (and don't run Windows for our infrastructure...well, unless you could Halflife as infrastructure).

Use the MS PKI software for the clients, but use OpenSSL to generate your certs. If you ever have to integrate with something old or ugly, MS generated certs can be a little weird (read, lots of things that only MS does). Note to bore you with the details, but see this document for the gory details of certificate interchange. It's really amazing it works at all.

About MS, the document says:

Microsoft Profile - This isn't a real profile, but the software is widespread enough and nonstandard enough that it constitutes a significant de facto profile.

"No standard or clause in a standard has a divine right of existence." -- A Microsoft PKI architect explaining Microsoft's position on standards compliance.

The document goes on to have an entire section on Microsoft bugs. Although, to be fair, I suspect a good many of them have been fixed and a good many still remain.

So...save yourself the headache...when generating your certs, use OpenSSL with the scripts that come with it. It is quite possibly the least erratic implementation of a CA. Yes, this does make it much more complex to operate. However, so does the following very important recommendation.

Like the parent post says, put it on a machine and lock it in a room (if you do a lot of business, a safe or vault would not be unwarranted). Make sure that any passwords (i.e. for encrypted root private keys) are written down in an envelope and stored in a different, highly secure location. The only thing more frustrating than bad PKI is good PKI when the person who knows the private key password was hit by a bus.

PKI? What PKI?

[Anonymous Coward]

I do security work for a Fortune 100 company, and while we've got the usual SSL certs on some of our web servers, we haven't yet had a compelling business case that would justify the huge expense to do PKI right. Coupled with the belief that PKI done wrong is worse than not doing PKI at all, we've stuck with point solutions for our encryption needs thus far.

I believe that we're moving forward with certs in the ActiveDirectory to facilitate EAP-TLS on our wireless, and that will probably go farther towards "universal" certificates for our end users, but since rolling out smart card readers to tens of thousands of users will be a significant investment, using certs for regular auth to the AD just isn't cost justified yet.

In the mean time, we've got self-signed certs for signing internal applications, and use some commercial, GPG-like software for desktop/email encryption :-) SSH works quite well for shell access, although the onesie-twosie management of the RSA keys is a major bitch.

In reality, I doubt that we'll ever go for a full-blown PKI done right. Every time we look at it, we figure out that the servers, admins, training, and physical security improvements will cost $6 million, and it won't really buy that much. For important authentication things, especially remote access, using those random-number tokens works really well, and doesn't have nearly the costs associated with them that PKI does.