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?

Piloted

[kjs3]

I did a fairly extensive pilot of this at my previous company, with the assistance of Microsoft. We demonstrated everything you mentioned successfully and did scalability tests that indicated that with careful planning, we could scale it to serve our needs (~100,000 users). We used the Active Directory integration, which made issuing and revoking certs seemless for the Windows users (most of the desktops). The primary application was WLAN security, but we demonstrated everything from SSL certs to application signing. We also used the Safenet CA3 hardware root key device as well. There is a *lot* of planning required to make this work well, but it does work.

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.

Federal Govt. Use

[Anonymous Coward]

US DOD is probably the single largest user of PKI in the world.

We (Navy via NMCI) use multi-factor identification. Most commands have CAC cards (basically just smart cards) that store multiple keys (one for email, one for web pages, one for digital sigs). To access any data on the cards (including certs) you also need a PIN. Furthermore, most systems have an additional (strong) login uname/pass after your cert is accepted. The result is password overload but fairly decent security.

You minimally have dual authentication factors (physical card access and PIN) and is most cases triple authentication.

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.

Try PHPki

[LanMan04]

1. I installed PHPki and used it as a CA,
2. Generated oodles of certificates for our entire staff (SMIME certs, so they work with Outlook 2K and 2K3)
3. Published each of their certificates to the Global Address List
4. Had everyone set the option in Outlook to include their public cert as an attachment to signed/encrypted emails
5. Had everyone install the CA's root cert on their machine

Now they can send eachother signed and encrypted emails, all WITHOUT any kind of Microsoft CA or server. It's important in our environment that the private certs NOT be stored where the email/Exchange admins have access to them, so while it takes a little manual labor, it's FREE and works very very well.