Security Advisor

5 Steps to Certificate Bliss

Whether you decide to build your own PKI for security or use a third party, planning is paramount.

Today we're inundated with sermons evangelizing certificates as the universal answer to all things security. Want to get rid of the risk of password-based logon? Use certificates and/or smart cards. Want to protect communications over the Internet? Use SSL certificates or IPSec-based VPNs. And when using IPSec, you'd better use certificates for authentication, because that's more secure. And the list goes on.

To adopt these solutions you need to either purchase certificates from a public Certification Authority (CA), or build your own Public Key Infrastructure (PKI). Both options are now incredibly easy—so easy, even your boss could do it. But purchasing certificates can be rather expensive, as can hiring a consultant to assist you with an in-house PKI, or purchasing and implementing your own third-party CA products.

Microsoft Makes It Easy
Enter Microsoft certificate services. Microsoft is very good at making the incomprehensible simple by virtue of the wizard. If you're running Windows 2000 Server or Windows Server 2003 it'll take you just a couple of minutes to bring up a CA and start issuing certificates. If you have a Win2K or Windows 2003 domain, make sure that server is a domain member, and you've instantly empowered easy use of certificates throughout the domain. Before you know it you'll have more certificates crawling around in your network than there are ticks on a red-bone coon hound. So what's wrong with that? More certificates equals more security, right?

Wrong. Certificates could eventually become as maligned in the IT community as passwords. When correctly implemented, they can provide rock- solid security; done wrong, they'll be as weak as a three-character password. Given the deceptive ease of implementation, you may not think a certificate project requires major planning. That would be a mistake. Here are five planning steps to follow before implementing a certificate structure.

1. Determine if Certificates Are the Best Solution
In some cases, certificates may be the only solution to your security problem. If, for example, you want to implement 802.1x authentication using Protected Extensible Authentication Protocol (PEAP) and Microsoft's Internet Authentication Service (IAS) server, you'll need, at minimum, a certificate for IAS. Likewise, you can't outfit your Web server for SSL without a server certificate. You'll also need certificates—lots of them—in order to use the native smart card support built into Windows 2003 and Win2K.

But certificates are most definitely not the solution for every security need. Before rushing in, determine what's driving the call for certificates, so you can decide whether they are the best solution. If it's a management initiative, for example, have a talk with the manager who wants changes. I can imagine such a conversation going something like this:

C-Level Decision-Maker John: "I'm tired of hearing about how weak Windows passwords are. We need to implement smart cards."

IT Manager Sven: "That will improve security, but I have a limited IT budget. Investing in smart cards will pretty much kill other IT initiatives for the year."

John: "Well, what are our options? You know as well as I do that Microsoft products need all the help they can get. I don't want to have to notify our customers that their credit-card numbers may have been exposed."

IT Pro Diane: "The issue of customer data security can be better addressed by implementing my proposal from three months ago. Microsoft passwords and password policies can be strengthened beyond the capabilities of the password cracking schemes available today and into the near future. We just need some policy changes, user training and password auditing capabilities. This will cost far less than implementing smart cards across the board."

Sven: "Diane's right, John. We can do a better job of managing password-based authentication. But we need to start with sound security policies and practices, and we need the teeth to enforce them. Will you help us there?"

John: "Well, I'm not convinced, but I'm willing to consider your proposals. I want a report on my desk tomorrow on how to bolster password security. Send me another copy of your prior proposal on customer information security as well."

Whatever the ultimate decision, at least the reasons for the proposal are being discussed. How else can you determine the best course of action if you don't know what the goals are?

2. Buy or Build?
Several items must be considered when deciding whether to purchase or produce certificates. Make the right decision based on:

  • Budget
  • Certificate requirements
  • Current network infrastructure
  • Number of certificates required
  • Current deployments
  • Future plans

If you need only one certificate, you may be tempted to buy one. But if you've already invested in PKI, shouldn't you just issue one of your own? Not necessarily. A public Web site, for example, should have a commercial CA as its signer, while an intranet site usually works better with one from your in-house CA.

If you need multiple certificates, you may decide it's time to deploy your own PKI. It's certainly easy and cheap enough to do with Microsoft products, but are you ready to devote the time and energy into learning how to do it securely? What if you have an immediate need to secure wireless access? Properly implementing a PKI will take time. In this case you may want to purchase the certificate(s) in the near-term, while at the same time developing and hardening your PKI plan for the future.

3. Planning
Whatever you decide, you'll need to do some serious planning.

Purchased Certificates
Should you go the commercial route, there's a host of procedures you'll need to implement, including assigning responsibility for:

  • A comprehensive certificate management plan that includes the reasons certificates are purchased, how they're actually used and who has responsibility for their management.
  • Certificate purchase and hand-off for implementation.
  • Certificate distribution and installation, using automated methods where possible and keeping accurate records.
  • Tracking certificate expiration dates, renewing certificates, or expiring them and recording changes.
  • Certificate revocation.

In-House Rollout
The development of in-house certificates services using your own PKI should be 80 percent planning and 20 percent implementation. The steps you'll need to take include:

  • A detailed analysis of certificate use within your organization. Determine the use that provides the most benefit and implement that first.
  • An analysis of available PKI skills among your personnel.
  • Create a committee—representing IT, general management and employees—to develop policies and procedures for design, implementation and maintenance.
  • Review committee work to make sure it covers areas including protecting root and subordinate CAs, how certificates will be issued, revoked and renewed, and whether a CA hierarchy will be used.
  • Specify an audit methodology and practice before deploying.
  • Research best practices for hardening both CA computers, processes and certificate usages—then build them into the architecture of your PKI.

4. Select the CA Vendor
If you decide to buy third-party certificates, return to the analysis and planning stage. Yes, this step is in the correct order. You should thoroughly study your needs and requirements concerning certificates before selecting a vendor. Whether you're purchasing a single certificate, third-party CA or implementing Microsoft's CA, you should be looking for the vendor that suits you—not for the solution that a specific vendor supplies. Then determine the securest path possible for deployment and maintenance.

5. Deploy and Maintain
Once you've planned your work, work your plan. You've got a number of steps to do, all of which must be done in the correct order—and don't forget that security is iterative. Maintenance is the most important phase of the process, after planning.

More Information

Purchased Certificate Considerations
I hope by now you're ensuring that your wireless LAN is secured and isolated from your internal network. You should treat wireless connections to your network as if they're coming from a hostile network (as indeed they may be). One way to do this is to implement 802.1x authentication. Microsoft's Internet Authentication Service (IAS) can become your 802.1x authentication server. If you choose PEAP-MS-CHAP v2 as the EAP authentication protocol, clients don't need certificates—the IAS server does.

If you've already implemented a Microsoft Public Key Infrastructure (PKI), providing that certificate is easy. But what if you haven't? Should you invest in installing a Microsoft Certification Authority (CA)? Installation is easy, but doing so correctly isn't. It's not something you should blithely do without careful consideration and consultation with your organization's policy makers and others impacted by your decision. The path to PKI protection is fraught with risks. PKI does, however, have huge benefits that make it well worth spending the time to do it right.

Whether or not your ultimate decision is to develop your own PKI, it's not going to happen overnight. To protect your wireless LAN in the meantime, a quick alternative is to purchase a certificate from VeriSign or another third-party CA. This may become your permanent solution or eventually be replaced by your in-house PKI solution; the advantage is that it's available now.

Remember a couple of things if you take this route. First, the recommended process is to use IAS to make the request to the CA vendor and, when your request has been approved, return to the site using IAS to obtain and automatically install the certificate. You may want to consider requesting and obtaining the certificate from an administrative station and then manually installing the certificate on IAS. This will avoid the security risk of allowing script processing from IE on the server.

Second, the CA vendor certificate will point to one of its own servers for certificate revocation information. When WLAN clients attempt to connect to the protected WLAN access point, the IAS server will present the certificate and the clients will check with the CA vendor's server to ensure the certificate hasn't been revoked. This is good, since it prevents possible rogue servers from impersonating your IAS server. The certificate is used to authenticate the IAS server to the client; a secure channel is then established so that the entire contents of the client-to-server authentication is encrypted. This is important when using MS-CHAP v2, which is susceptible to offline password cracking attacks. If the authentication conversation is encrypted, any captured packets can't be attacked without a huge investment in first attempting a crack of the packet encryption.

IAS also checks the revocation status of the certificate and must therefore also have Internet access. If you're using a proxy server for Internet access, you'll need to configure IAS to use the proxy server. You can't do it by using the options pages of the IAS's IE. When you configure proxy settings in IE, you do so for the currently logged-on user. Instead, you must configure proxy settings for the local computer, since IAS runs within the security context of the server. You can do this using the "at" command to open a command prompt in the security context of the local system and then setting the configuration. Here's the process:

  1. Check to see that the Scheduled Task service is enabled and started.
  2. Use a command prompt on the IAS server to enter the "time" command.
  3. The current time is displayed. At the Enter the new time: prompt, press Enter. (This command is only used to determine the time; you'll add one minute to that time and use it in the next command.)
  4. At the command prompt type
    at [current time plus 1 minute] /interactive "cmd.exe"
    and then press Enter. (An example command line might be "at 13:32/interactive "cmd.exe"")
  5. Wait a minute, and then, when the new command prompt opens, open IE using the command "%programfiles%\Internet Explorer\iexplore.exe"; press Enter.
  6. In IE Open Tools\Internet Options; select the Connections tab, then LAN Settings.
  7. In the Proxy server, select Use a proxy server for your LAN, then enter the name or IP address of your proxy server and the Web port number in Port.(Typical port numbers may be 80 or 8080; consult your proxy server documentation).
  8. Click OK to save the settings, then click OK to close Internet Options.
  9. Close IE and close the command prompt opened by the "at"command.
  10. If your policy is to disallow the Scheduled Task service to run scheduled processes, disable the service.
    Roberta Bragg

More PKI Resources
Below are links to additional Microsoft resources on this topic along with a number of MCP Magazine articles that address PKI.

Microsoft PKI Resources:

  • A Webcast on planning a PKI infrastructure for Windows 2003.
  • An overview of the PKI Design Process.

MCP Magazine articles:

About the Author

Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.


comments powered by Disqus

Subscribe on YouTube