Now that you've decided to use a public certification authority and outsource your PKI, you must determine how to incorporate it into your current environment. The vendor you've selected will undoubtedly provide a great deal of consultation and advice on how best to configure your environment to interact with its hierarchy. Because the public certification authority could be running any CA server and client software to create and maintain its certification hierarchy, at some points I cannot provide detailed steps. I will not assume that you've chosen any particular public authority or software, as there is no single best vendor among the numerous options. Therefore, our procedures will focus on Windows Server 2003 family servers and Windows XP client computers. I can summarize the elements of this type of deployment as follows:
Set up a secure communication channel between your network and the vendor's. This is normally handled by the vendor.
Configure the certificate revocation list (CRL) to be published to a location accessible to your network's subjects and verify its publication. This is normally established with agreement between you and the vendor, as you may want the CRL published to a specific point within your network to reduce bandwidth usage.
Verify exactly who needs a certificate and what its intended use will be. This should have already been completed in your planning process based on a risk and needs analysis and incorporated into your vendor contract.
Securely enroll your organization's users by verifying their identities and issuing them their certificates. This is normally done by you with guidance from the vendor and the collaboration of appropriate internal management. This step is crucial to the security of your new PKI deployment, as the receipt of a certificate by an unauthorized individual could compromise the entire deployment.
Securely enroll any network services or intermediate devices (e.g., routers) and configure them to use their new certificates. This is similar to issuing users their certificates but will require more policy-based guidance and auditing, as multiple individuals may have access to these valuable credentials during the process.
Maintain the CRL by promptly informing your PKI vendor whenever a certificate is no longer valid. This is an ongoing collaborative maintenance task.
Regularly audit the interaction between your company and the vendor to verify that only authorized transactions are taking place. Again, this is an ongoing task to ensure that no security compromises have quietly occurred. Auditing is frequently the only way to avoid misappropriated but as yet unexploited credentials from compromising security.
As you can see, a number of these tasks are accomplished by the vendor as they are very vendor-specific. Other tasks can be handled by the operating system of both internal servers and clients. The Windows Server 2003 family and Windows XP make many of these tasks simple.
The vendor will provide you with a root certificate that all deployed certificates will chain to. This certificate must be trusted by all clients and servers within your enterprise. With Windows Server 2003 family Active Directory, this is accomplished very simply. Group Policy can be used to distribute the desired certificate.
Let's set up a fictitious example. For our example, let's assume that your organization, Woodgrove Bank, has contracted with the Internet security firm Contoso, Inc., to provide certificates for data encryption and digital signatures. As part of the process, Contoso provides you with a root certificate on a floppy disk. You can easily deploy this certificate to all clients by following these steps:
Open Active Directory Users and Computers.
Right-click on woodgrovebank.com and click Properties.
Click the Group Policy tab and choose New to create a new GPO. Name this new GPO Root Certificates.
Click Edit to edit the new policy.
Navigate to Root Certificates Computer Configuration Windows Settings Security Settings Public Key Policies, then right-click on Trusted Root Certification Authorities and select Import.
Import the root certificate from the floppy disk into the policy.
Verify that the correct certificate is listed in the Trust Root Certification Authorities Group Policy setting. See Figure 9-3.
Close all open windows.
Wait for Active Directory replication to complete policy replication, then wait for all clients to retrieve the new policy. This can be accelerated by using the GPUpdate utility, but in normal deployments there is no need to rush the process.
Note that you deployed the root certificate to the root of your domain. This is because all clients within the domain should trust this certificate. If the environment were more restrictive and required only a subset of users to trust the certificate, that could be accomplished by restricting the policy to those desired users, groups, or organizational units.
You have now successfully configured all network clients to trust the new root certificate. But you still need to deploy the client certificates in a trusted manner. This is the most variable aspect of this type of deployment. The method by which you securely authenticate the intended recipients and distribute the certificates is the step most likely to provide unauthorized access to intruders.
There are as many methods for client certificate deployment as there are environments that will deploy certification hierarchies. Before considering specific mechanisms used to perform the client deployment, you should be aware of some common rules. Which of these rules you will follow, and how strictly, will help you determine which deployment mechanism is best for your environment.
You must require that users prove their identity to a disinterested third-party (such as a professional auditor or external security company) before being presented with their new certificate. You should not, however, assign this task to nonsecurity personnel such as a manager or group assistant, because such a method is doomed to be compromised. Nor should you use an automated mechanism that would allow an existing intruder to extend the intrusion. Also, these proofs of identity should be audited in some nonintrusive way, such as a video recording device.
Involve the human resources and legal portions of your company during the planning of your deployment. This will help ensure that you do not violate any privacy laws or policies during your deployment. This step may seem unnecessary and difficult, but it is far better to incorporate these groups during planning than face a lawsuit for an ill-conceived deployment plan. While this is often a time-consuming and expensive task and many companies bypass it, you should consider it a required element in your process.
Deploying certificates to intermediate network devices (e.g., routers) and service accounts should be a task assigned to a group of administrators, not just one. These tasks must be audited by a third party to ensure no collusion occurs during the deployment. This auditing party could be senior management or a vendor contracted specifically to audit security-related tasks.
Do not attempt to deploy the entire certificate base at once. Phase in your approach so as to not overwhelm the security authentication and auditing people. One popular approach is to deploy certificates to intermediate devices first to catch any errors in policy or technology before users are involved. Next, a small cross-section of the user base is selected and certificates are deployed to them. Once these phases have been completed and any problems that have arisen are addressed, the main deployment has a more reasonable chance of success.
Once you've reviewed the considerations for client certificate deployment, you can examine the various ways certificates can be deployed to clients. There are numerous ways to accomplish this task. This section will discuss the most common and their benefits. This is not a complete list, as each certificate vendor has at least one preferred method and many employ several. Also, keep in mind that most of these solutions do not work for entities other than users. Routers, web servers, and the like will still most likely obtain their certificates through manual enrollment.
Many vendors have software-based solutions that run on client computers. This software can often make certificate enrollment transparent to the user and reduce costs resulting from user errors such as enrolling for multiple costly certificates. The deployment of these applications to client computers can often be automated through software publishing.
Windows Server 2003 and most Windows operating systems support logon scripts. A logon script can easily be created to execute code that enrolls for and installs a certificate on the client computer or on behalf of the user. The level of functionality for these scripts varies depending on the operating system being used. This option is somewhat more costly, as custom scripts must be developed and tested. This solution may be inappropriate for environments in which users remain logged on for extended periods, as logon scripts execute only when the user logs on.
For more information on creating scripts that enroll for certificates, including sample scripts, see "Using Certificate Enrollment Control" at http://msdn.microsoft.com/library/en-us/security/security/using_certificate_enrollment_control.asp.
A simple email can be sent to groups of users asking them to click a link. This link can point to a web page that contains script code similar to the logon script, enrolling the client for a certificate and installing it. There are several limitations to this type of deployment. The largest isn't technical; it's behavioral. Any solution that requires users to interact or perform specific actions will be less effective than a solution that runs without interaction. Expecting users to click a link may be overly optimistic, and if the certificates are required for job functions, you do not want to rely on this behavior.
Autoenrollment is available to clients running Windows XP or Windows Server 2003 computers and automatically enrolls for and retrieves certificates from Windows Server 2003 enterprise certification authorities. If the certificate vendor is using this type of technology and integrates with autoenrollment, the certificate distribution is greatly simplified. Detailed information on autoenrollment is provided later in this chapter.
This sampling of automated enrollment methods is intended to give you some idea of the wide variety of certificate distribution solutions available. If you're integrating a public PKI vendor with your organization, you should determine which solution works best for both your clients and the vendor.