9.5 Implementing a Public PKI

     

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 :

1. Set up a secure communication channel between your network and the vendor's. This is normally handled by the vendor.

2. 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.

3. 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.

4. 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.

5. 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.

6. Maintain the CRL by promptly informing your PKI vendor whenever a certificate is no longer valid. This is an ongoing collaborative maintenance task.

7. 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.

Numerous software-based solutions are available to accomplish the implementation tasks discussed here. These software solutions are often provided by the vendor as part of a negotiated solution package. It is possible that the described tasks will be entirely completed by the vendor and no effort will be required on your part. However, many of the available solutions do not provide this service and will require you to complete these tasks manually. You should scrutinize the vendor agreement to determine which, if any, tasks you must complete yourself.

9.5.1 Deploy Root CA Certificate to All Clients as Trusted Root

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:

1. Open Active Directory Users and Computers.

2. Right-click on woodgrovebank.com and click Properties.

3. Click the Group Policy tab and choose New to create a new GPO. Name this new GPO Root Certificates .

4. Click Edit to edit the new policy.

5. Navigate to Root Certificates Computer Configuration Windows Settings Security Settings Public Key Policies, then right-click on Trusted Root Certification Authorities and select Import.

6. Import the root certificate from the floppy disk into the policy.

7. Verify that the correct certificate is listed in the Trust Root Certification Authorities Group Policy setting. See Figure 9-3.

8. Close all open windows.

9. 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.

Figure 9-3. The new root certificate for Woodgrove Bank has been imported into the Group Policy settings

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.

9.5.2 Obtain and Deploy Client Certificates

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.

9.5.2.1 Considerations for client certificate deployment

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.

I do not offer any specific legal advice in this book for two very important reasons. First, every state and country are different and any legal opinions offered here would not be appropriate for all areas. Second, I'm not a lawyer and do not claim to be an expert on privacy or discrimination law. In my experience, the best course of action is to offer a well-written deployment plan to both HR and legal advisers and have them tell us that there are no problems. I'm not entirely sure what they're looking for, but having their seal of approval means that I don't need to know.

• 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.

9.5.2.2 Common ways to deploy certificates

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.

It's important to realize that any automated method for certificate deployment to end entities negates the manual human-to-human authentication that was discussed as a very important consideration. These automated solutions provide a great benefit in that they can make certificate deployment simple. However, they remove one of the best security processes available: face-to-face authentication. You should use these automated deployment solutions only after considering this risk.

Installation of an enrollment application

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.

Logon scripts

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.

Email web hyperlinks

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.

Use autoenrollment

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.