Slashdot Mirror
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."
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?
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.
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:
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.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
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.
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.
PKI and other names for encryption like encryption, lock etc. are stupid names. What should be done to advance its adoption is to have a put in envelope button and an open envelope button. This way it hammers the point that email is a post card and if you have something you don't want the world to see, you put it in an envelope. It is a paradigm that translates well from the real world and makes much more sense than lock and unlock or encrypt and decrypt.
just my 2 cents.
The war with islam is a war on the beast
The war on terror is a war for peace
Microsoft has a utility in their Resource Kit for Windows servers named MSCEP. It adds support for the protocol that the Cisco routers use. I have setup a Microsoft Small Business Server 2003 with a Cisco 831 router at the perimeter. After installing (and configuring) Certificate Services, IAS, and MSCEP I am now able to authenticate the Cisco VPN Clients (both Mac and Windows btw) using digital certificates and radius. The setup is working flawlessly for me now. Cisco has upgraded the 830 series of routers with the new 850 and 870 series that have wireless capability integrated into the router. It will be interesting to configure the wireless clients for 802.1x using EAP-TLS along with the Cisco VPN Client for remote access, as well as the Mac OS X clients :) So, basically you can easily configure Cisco routers to work with Microsoft's Certificate Services. I work for neither Microsoft or Cisco. Enjoy!
Edd
Actually we just switched AWAY from MS cert services to an outsourced CA. I did this because we primarily used the MS CA for smartcard logins, and I was able to get one of the FREE online CA's to support the required configurations.
Because they have passed their webtrust compativle security audit, they will soon have major browser inclusion. Thus we will soon have a single cert that can be used for email encryption, IM encryption using certs using Simp ( http://www.secway.com/ ), and SmartCard logon to the network.
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.
With the first link, the chain is forged.