The implementation of a private PKI is far more complex than that of a public PKI. The hierarchy must be planned in detail before any deployment can be considered. You may even want to consult legal experts to help create a certificate practice statement. Each CA deployed must be configured for proper security before exposing it to any users or attackers. The description provided on implementing the PKI is sequential and should be followed in the correct order to ensure proper deployment.
This isn't to say that deploying a PKI is hard. The individual tasks associated with the deployment are actually very straightforward and take little time to complete. The planning itself isn't difficult either. But ensuring you've completely thought through all aspects of the PKI and created a solid plan will help avoid missing steps or key elements of the deployment. And recovering from these missed elements or steps is something that's not always possible in the PKI environment.
Before you begin to implement your certification hierarchy, you must have your planning completed. You already know how the PKI will work?what templates will be used, who will get certificates, how many tiers will be in the tree, and so forth. That plan tells you what to deploy but not how to deploy it. To get to the next stage, you must determine the exact method and order you will use to properly deploy the technology. This information makes up your deployment plan, which is similar to your plans to deploy any broad-reaching technology across the enterprise.
At its minimum, your PKI deployment plan should include the following information:
This will include the computer names and CA names to be used, their specific configurations and equipment locations. This makes the map useful as both a checklist and to show hierarchical relationships at a glance.
A timeline is important information for any deployment plan, but especially so for the PKI hierarchy. Because child CAs cannot be installed before their parents are available to sign CA certificate requests, the hierarchy must be deployed in a top-down fashion beginning with the root CA. Remember that equipment and people rarely show up on time, so allow flexibility in your plan for late equipment arrival and human interruptions such as vacation or illness.
The installation should be followed without deviation to ensure the correct configuration of all components. This book will provide most of the information necessary to create these procedures.
Each CA should be installed by a minimum of two individuals, a technical person and an auditor or member of upper management. This ensures that no single person has the ability to compromise important private keys or configure the CA with intentionally weak security or backdoors.
For example, your domain administrators may have restricted the ability to join computers to the domain. You may also be planning to add customized certificate templates to Active Directory, which requires specific permissions that you may not have. It is necessary to have a user with the appropriate privileges perform these configuration changes. The tasks that require specific privileges will be included in your detailed procedures.
Testing a PKI deployment is a critical step that must be done before actual deployment. Do not try to save time by deploying your hierarchy within a test environment and then moving it into production?this rarely works because of differences between the test and production environments. Fully deploy the PKI in your test environment before any CA is set up in production.
A secure deployment must be maintained to ensure it does not become either insecure or useless. The procedures used to keep the PKI up and running should be documented before the environment is deployed to avoid these unwanted situations.
In our example Woodgrove Bank implementation, we can assume that the PKI infrastructure shown in Figure 9-4 has been approved by senior management. This diagram can be extended to include the details determined from the deployment planning. A more complete figure including some of these details is shown in Figure 9-5. For the sake of brevity, only the details for the root CA and one intermediate CA are provided.
Once you've got a timeline in place, together with your certification hierarchy and plan, you have exactly what you need to begin your deployment. However, there's a little more documentation that should be completed before you start.
Security isn't just about the technology. It's also about the practices and policies that are used to provide assurance of security. The most secure software in the world doesn't remain secure for long if sloppy computer management allows compromise of the computer or its underlying infrastructure. Within a PKI, there are guidelines for proper management and policy. These guidelines are documented during the planning process as I've already discussed. However, it may be useful to document them in a standardized way that can be integrated with the PKI itself.
The certificate policy and certificate practice statement are two documents that can be created by the PKI administrator. They are used to fully document the intentions and limitations of the PKI as well as the policies and procedures involved in PKI management. Although many administrators consider their procedures and policies internal information and are loath to provide them to end users and external companies, there is often a need for this. I'll describe each type of document briefly and show why it could be beneficial to provide this information.
Certificate policy (CP) is a broad description of the acceptable use of a certificate issued by the relevant PKI. To be more precise, the CP tells users what the intention of each certificate type is and where it can and cannot be used. This is important for all users and certificate consumers to understand, as the intended use of a certificate may not match the actual use. An email encryption certificate, for example, could be used to protect proprietary information on a laptop, which may be an inappropriate use of the certificate. Without a CP, the user has no way to understand how the certificate should be used. The CP also has some legal benefit in that it can provide documentation in case of misuse resulting in loss or liability. When used in this way, a lawyer should be consulted to review and coauthor the CP before deployment.
Certificate practice statement (CPS) is a complementary subset of the CP. It picks up where the CP leaves off and describes the security processes in detail. The CPS can apply to one CA or a portion of the hierarchy. The details normally include, at a minimum, the practices used for issuance such as identity validation and key management. Often a CPS includes details for all CA operation including renewal, revocation, and CA maintenance and may vary in scope from a single CA to all CAs in a certification hierarchy.
The benefit of publishing a CPS is twofold. First, it establishes a well-known and reviewed set of policies. Changes in certificate administration, management, and so on do not affect the CPS unless they specifically undertake to do so. This helps avoid the ball-dropping that often occurs during responsibility handoffs and helps ensure that no gaps in security form. The CPS also provides critical information for partners or vendors when PKI integration is desired. If you already have a detailed document establishing your policies and procedures, it's a simple matter for the other company to review the documents and determine whether your policies match well enough with theirs to establish the trust.
For either the CP or CPS, you are the sole judge of what it should contain. There are several guides and suggested topic lists, and several are included in the RFC mentioned in the following note. However, any information you deem necessary should be included in one or both of these documents. For example, you can add helpful information for holders of certificates such as security contacts within the organization and suggested practices (e.g., safely backing up the private key of valuable certificates).
The CP and CPS can be very large or very small. A quick search on the Internet at the time of this writing yields readily available statements ranging in size from 1 to 105 pages. Your documents will probably be on the lower end of that range. They are placed in a location that is accessible to holders of certificates and is pointed to by the appropriate fields within each certificate. The CP and CPS are similar to a CRL in that they can reside at any uniform resource locator (URL) that the client can reach. Because the contents are considered open to public scrutiny, the documents can be placed outside your firewall if you have external subjects that must access the statement. Consider mirroring your publication locations when deciding where to place them, and ensure that client computers can reach those locations.
Discussing the order used to deploy a PKI is somewhat irrelevant. A PKI hierarchy can be installed only top-down, with the root CA installed first. While technically some other work could come first, none of it will work properly until the root CA is completely configured and is able to issue certificates to its subordinate CAs. Therefore, I'll discuss deployment in a top-down fashion starting with the root CA.
If there is one thing you need to know about installing a root CA, it is that the private key of the root CA is the most important piece of information in your certification hierarchy. For this reason, it must be safeguarded from the very beginning. Lackluster key management cannot be reversed or mitigated at a later time. This is the reason I've recommended having at least three parties be present when the root CA is installed. You might also consider videotaping the installation for later audit and proof of security.
The hardware assembly and configuration should also be done as part of the root CA installation. A server assembled and configured outside the close scrutiny of a multiparty audit is unacceptable, as many covert security vulnerabilities could be introduced during that window of opportunity. If an HSM will be used on the root CA, it must also be installed and configured during this process prior to the CA software being installed. This ensures that the private key is created as securely and reliably as possible and remains secure throughout the entire process.
I created a diagram for Woodgrove Bank's PKI deployment in Figure 9-5. It's time to examine a portion of the hierarchy and discuss its deployment. Let's assume that you will deploy the hierarchy beginning with the portion inside the box. You're doing this after your testing has succeeded and you're certain that the hierarchy is planned correctly. You want to limit the initial production deployment to as small a group as possible to limit damage should something go wrong.
Your first job, as I discussed, is setting up the root CA. You should follow this plan to accomplish your task:
Click Start Control Panel.
Double-click Add or Remove Programs.
Click Add/Remove Windows Components.
Check the checkbox for Certificate Services. You will be warned that you cannot change the computer name or domain membership once Certificate Services is installed. Click Yes to proceed, then click Next to begin the installation.
Click Stand-alone root CA to select the correct type of CA to install, select "Use custom settings to generate the key pair and CA certificate," then click Next. This is an important setting, as it will determine the role of the CA in the hierarchy and allow you to use the desired cryptographic service provider (CSP). The configuration is shown in Figure 9-6.
On the Public and Private Key Pair page, select the desired CSP, algorithm, and key size. You have wisely installed and configured an nCipher HSM, so you choose that CDP and the appropriate key size and algorithm, as shown in Figure 9-7. If you configured the HSM to require authorization to create and use private keys, you'll be prompted to perform that authorization now.
Under Common Name for This CA, type the CA name. In this case, you're installing WoodgroveRoot.
Provide the validity period for the root CA certificate. This setting is critical, as all certificates within this PKI must have a lifetime shorter than this one. The correct configuration for these options is shown in Figure 9-8. Then click Next.
Accept the default certificate database settings and click Next.
If the computer is running Internet Information Services (IIS), a prompt will appear asking to stop the service temporarily. If you plan to use web enrollment or this computer is not providing web services (as it shouldn't be), click Yes.
The wizard will now copy files from the product CD and announce when it is finished. Now you have a functioning standalone root CA!
The first thing you will do is configure the root CA's CDP list to match your plan. To do so, you take the following actions:
Click Start All Programs Administrative Tools Certification Authority.
Under Certification Authority (Local), right-click WoodgroveRoot and click Properties.
Click the Extensions tab to display the default configuration for CRL distribution points.
Click Add to add a new path to the list. Provide the path that clients will use to access the root CA's CDP. Note that this setting is CA-specific, so only the root CA's CDP must be provided here. This is shown in Figure 9-9.
Select the new path provided and click "Include in the CDP extension of issued certificates." No other options need to be selected as the root CA will neither publish delta CRLs nor use Active Directory to publish its CRL.
Remove all paths that do not publish the CRL to the local computer. These paths will be unreachable by client computers and may confuse poorly written client applications. The CDP configuration should now match the configuration shown in Figure 9-10.
Click OK. The CA must be restarted to change the CDP configuration. Click Yes to allow this restart.
If you are not using a HSM, you can use another method to protect the private key of the root CA. Although this method is not the best solution available, it provides far more security than simply leaving the private key on the root CA. This method relies on distributing different pieces of information about the root CA to several different parties. Only when the parties combine their information can they reconstruct the private key.
Note that this method works for the private key of any appropriately configured CA. Portions of the method can also be used to protect any arbitrary private key, not just a CA's private key.
You may need one or more floppy disks (or CD-R media if your CA is equipped with a CD writer) depending on the number of parties you want to require when reconstituting the private key. You may also need splitf.exe and joinf.exe to manually split and rejoin the private key's storage container. These files have been around as freeware for many years and are readily available on the Internet.
Essentially, we're making it so that you cannot use the private key alone. To begin, we export the certificate and private key using the Certificate Export Wizard as shown earlier in the chapter in the "Archiving a certificate and private key" section. We select the Remove Private Key checkbox on the wizard to delete the private key from the CA, and we provide a password during the export. The export generates a file that we write to the floppy disk or CD-R. This immediately removes the private key and begins to provide some additional key security. Only the party who has both the password and the floppy disk has access to the private key.
To increase that to two parties, you do the obvious: ensure that the person with the floppy isn't the same person who has the password. Only when these two people act together can the private key be reconstituted and used. For parties of three or more, we use splitf.exe to split the private key file into two or more parts. Then we put each of these parts on a separate floppy and distribute them to multiple trusted individuals. In this configuration, only the combination of all floppies plus the password can retrieve the key.
In addition to the root CA's private key, other valuable private keys may be exported and secured in this fashion. Key archival and recovery, a major benefit of a Windows Server 2003 family CA, requires someone to have a private key for recovering other users' private keys. Obviously this key is extremely valuable. As such, it should be exported from the private key store of whatever user obtained it and stored in the method I've described. Because access to the CA's database is required to obtain the encrypted key to recover, an additional factor can be the restriction of the CA officer so that the CA officer must request and provide the encrypted private key for all key recovery operations. This factor requires role separation to be enforced on the CA, which is documented in Windows Server 2003 family Help.
The key protection procedure has two potential security flaws that you must mitigate. First, during the export and key-splitting operation, temporary files will probably be written to the computer's hard disk. Although a long shot, an attacker could potentially scan the hard drive and reconstruct the file. Cipher.exe /W will eliminate that threat by wiping the data from the hard drive. For more information, see Chapter 4. The other flaw is that floppy disks are notorious for going bad over time. Storing unique and critical data on a floppy is idiotic. Multiple copies of each fragment or file should be made and provided to trusted parties for redundancy. Numerous other removable media solutions are far more reliable over time, are affordable, and can store any arbitrary data, including our private key. These can include magneto-optical drives, recordable DVDs, or even technology not commonly used for this purpose such as CompactFlash or Memory Stick media. Any technology that reliably stores data as a file will work.
Before you finish with the root CA, you must publish its CRL to an accessible location. As I've discussed, you should take the root CA offline and both physically and logically isolate it once its installation is complete. This means that it will not be able to publish its CRL to any CDP not on the computer itself. However, any client that checks the revocation of the root CA's certificate must be able to locate a valid CRL. You configured the root CA's certificate to point to an accessible CDP during installation. Now you need to get that CRL there manually.
To manually publish the offline root CA's CRL, take the following steps:
In the same Certification Authority (Local) console that was used earlier to configure the CDP, double-click WoodgroveRoot to expand the CA containers.
Right-click Revoked Certificates, click All Tasks, then click Publish.
Click OK to publish the new CRL to the configured CDPs. This dialog box is shown in Figure 9-11.
Copy the CRL to a floppy disk (yes, they still exist, but you can use any portable data storage you like) and go to a computer that has access to the client-accessible CDP. Manually copy the CRL to the correct CDP.
This procedure must be done even though the CRL is empty. Clients that validate a chain must be able to retrieve and verify a CRL, even an empty one. Once you're done exporting the CRL, you can secure the root CA. You'll need this CA again once you begin installing the other CAs in the hierarchy, so don't take it completely down yet. You must ensure that only authorized physical access and no network access can occur until the deployment is complete. This is done simply by locking it in an area of the data center that only you or other authorized personnel can access. You could take other steps like locking the hard drive itself in a vault, but that would certainly sacrifice convenience.
As I mentioned in the earlier sidebar discussion of whether to dedicate hardware to the root CA, once the deployment is complete, the decision can be made to keep it continuously running or not. In any event, any hardware that comprises the root CA must be physically secured to ensure only authorized access occurs in the future. In most enterprises, the only authorized access will be periodic CRL creation and, rarely, the renewal of the root CA certificate or the issuance of a new CA certificate.
Installing an intermediate or issuing CA is the same as installing a root CA. The process must be documented and secure throughout. There are two major differences between the installation of a root and subordinate (or any CA that is not the root CA and issues certificates based on the trust of a CA higher in the hierarchy). The first is that the CA certificate must be issued by another CA, which slightly complicates our installation process and requires some manual steps. The second is the potential desire to integrate one or more enterprise CAs in the certification hierarchy. This is a simple and important option during installation.
You want to deploy the WoodFinIssue1 CA. This is an enterprise subordinate CA that will issue certificates to the finance department. You can jump right in and start configuring the machine as follows:
Ensure the computer is joined to the Woodgrove domain. This is required when the CA is installed as an enterprise subordinate CA.
Follow steps 1-4 listed in the steps to install the root CA.
Click Enterprise Subordinate CA to select the correct type of CA to install. Also, select "Use custom settings to generate the key pair and CA certificate." Click Next.
Select the desired CSP, algorithm, and key length?in this case, the Microsoft Strong Cryptographic Provider using the SHA-1 hash algorithm with a 2048-bit key length is appropriate. Click Next.
Under Common Name for This CA, type the CA name. In this case, we're installing WoodFinIssue1.
Accept the default settings for certificate database storage and click Next.
Select "Save the request to a file" to allow the CA certificate request to be saved to a specific file, as shown in Figure 9-12.
The rest of the installation will be the same as the offline root CA installation.
At the end of the installation process, the file specified in step 7 will be created. This is the certificate request for the WoodFinIssue1 CA certificate. This request must be submitted to and issued by the CA's parent, which in this case is WoodgroveRoot. The file can be transported by any desired means. You will copy the REQ file created on WoodFinIssue1 to the floppy disk and bring it (properly accompanied and audited) to WoodgroveRoot. Once there, you'll follow these steps to request and issue the certificate:
Open the Certification Authority MMC snap-in.
Right-click WoodgroveRoot, click All Tasks, then click Submit New Request.
Specify the REQ on the floppy drive from WoodFinIssue1.
Because WoodgroveRoot uses an HSM, the appropriate safeguards must be completed to load the signing key from the HSM onto WoodgroveRoot.
Double-click the Pending Requests container to display the submitted request.
Right-click the request, click All Tasks, then click Issue.
After the certificate has been issued, it must be exported from the issuing CA and brought back to the requester. Use the same floppy disk to bring the certificate from WoodgroveRoot to WoodFinIssue1, then follow these steps:
Double-click the Issued Certificates container to display the newly issued certificate.
Double-click the certificate.
Click the Details tab, then click Copy to File.
Use the Certificate Export Wizard to export the necessary information to a file. The file should be a P7B file that includes all certificates in the chain as shown in Figure 9-13.
All certificates in the chain are exported, as WoodFinIssue1 does not yet have WoodgroveRoot's certificate.
You then return the file to WoodFinIssue1 on floppy disk. To load the newly issued certificate and bring WoodFinIssue1 online, follow this final procedure:
Open the Certification Authority MMC snap-in.
Right-click WoodFinIssue1, click All Tasks, then click Install CA Certificate.
Specify the P7B file on the floppy disk.
This allows WoodFinIssue1 to build and validate the certificate chain. At this point it's a short chain, only itself and WoodgroveRoot. Once the chain is validated and an appropriate CRL is retrieved, the CA will come online and provide its services.
Now that the root and issuing CAs are both installed, you will create the new certificate templates that the WoodFinIssue1 CA will issue. This CA issues two certificates to users: one for digitally signing contracts and one for encrypting data. You want to archive the private key of the data encryption certificates in the event any valuable private keys are lost.
You create two new certificate templates corresponding to the need for two certificate types. For our example, I'll show you how to configure the encryption certificate, because I provided an example of a digital signature certificate template earlier in this chapter. You configure this new certificate template using the following steps at WoodFinIssue1:
Click Start Run, type mmc, and press Enter.
Click File Add/Remove Snap-in, click Add, then double-click Certificate Templates. Click Close, then click OK.
Double-click the Certificate Templates node to display all certificate templates currently maintained in Active Directory.
Right-click the Basic EFS template, then click Duplicate Template. I chose this template to duplicate because its use most closely matches the intended use of our new certificate template. This helps us reduce the number of configuration steps for the new template.
For Template display name, enter Woodgrove Finance Encryption Only.
Click the Purpose tab to verify that the Purpose is listed as encryption. You should also ensure that the Archive Subject's Encryption Private Key box is checked to allow the user to back up his private key in the future.
Click the Security tab and verify Certificate Administrators (or whatever group you have configured to contain the PKI administrators) Full Control; Finance Users Read, Enroll, and Autoenroll. Remove all other entries from this ACL, as shown in Figure 9-14.
Issuance Requirements: select CA Certificate Manager Approval. Because WoodFinIssue1 is a narrowly focused CA, the administrator is the appropriate entity to authorize and issue certificates.
Click OK to create the new certificate template. Note that Active Directory will take a short time to replicate the new certificate template information to all domain controllers. During that time, clients should not attempt to enroll for certificates and administrators should not modify the templates. Strange things can happen if the template is used before it's fully replicated.
Once the certificate template is created and replicated in Active Directory, we can "turn it on" by adding it to the CA. Because Active Directory stores numerous certificate templates, do not assume that every CA will issue certificates based on every template. Each CA must be individually configured with the information about which certificate templates will be issued. To configure WoodFinIssue1 to issue certificates based on the desired templates, configure WoodFinIssue1 as follows:
Click Start All Programs Administrative Tools Certification Authority.
Right-click the Certificate Templates container, click New, then click Certificate Template to Issue.
Click the Woodgrove Finance Encryption Only certificate template, then click OK.
Repeat the process to add the Woodgrove Finance Signature Only certificate template.
Once the issuing CA is installed, it can be configured with the necessary settings. In the case of WoodFinIssue1, Don must customize the CDP list to place our CRL in the same location as the root CA's CRL. This can be done using the same steps described earlier. You will also be archiving private keys issued from this CA. This is easily done in two parts.
First, obtain a certificate based on the Key Recovery certificate template and secure its private key. Then enable and configure the key archival settings on the desired CA. This is done with the following procedure:
Click Start All Programs Administrative Tools Certification Authority.
Right-click the name of the CA, then click Properties.
Click the Recovery Agents tab. Then click Archive the Key to enable key archival.
Click Add to add the existing key recovery agent (KRA) certificates to the CA.
Type a number in the "Number of recovery agents to use" box. You can choose a number up to the number of KRA certificates loaded.
Click OK. When prompted to restart the CA, click Yes.
Once the CA is restarted, the key archival settings will be enforced. Remember that only clients that support key archival will work with this option. In addition, certificates with a purpose of Signature will not archive the private key to ensure nonrepudiation of digitally signed data.
I assume in this example that the clients that will obtain certificates from WoodFinIssue1 are all running Windows XP. This is because Windows XP has the autoenrollment client built into the operating system and allows for simple deployment of appropriately configured certificates. When Windows XP computers are members of a Windows Server 2003 family Active Directory domain, they periodically query the domain for appropriate certificates and obtain them automatically. This is the easiest way to deploy certificates to clients. Several other methods?including web enrollment and Automatic Certificate Request Settings (ACRS)?are available for certificate distribution if the desired clients are running other operating systems.
To deploy these certificates to clients using certificate autoenrollment, you simply ensure the clients are members of the domain that WoodFinIssue1 is in. A limited autoenrollment configuration is turned on automatically in Active Directory. Additionally, if you want to provide additional functionality such as certificate management through autoenrollment, you can do so by configuring Group Policy as follows:
Open a Group Policy Object as described in Chapter 5. The group policy should be applied to the OU containing the desired users. In your case, you'll apply the policy to the Finance Users OU.
Because Finance has no existing Group Policy Object, you will create one called Default Finance GPO.
Edit the GPO.
Go to User Configuration Windows Settings Public Key Policies. Then double-click Autoenrollment Settings.
Verify that the default Enroll Certificates Automatically setting is selected. Then check the "Update certificates that use certificate templates" and "Renew expired certificates, update pending certificates, and remove revoked certificates" options.
Click OK to save the settings.
Because the newly configured settings will probably not be needed for some time, Group Policy replication and client application should not be a concern.
We've assumed that the subjects for all certificate requests so far are computers running Windows XP. Obviously, not all subjects that can use a certificate run this operating system. For Windows 2000 clients, you can configure Automatic Certificate Request Settings (ACRS) to enroll for a limited set of certificate types. ACRS is configured through Group Policy and is fairly straightforward to use.
Numerous other clients will also want certificates. In particular, intermediate devices such as Cisco routers use certificates to provide network-based security through such mechanisms as IP Security (IPSec). These clients obviously don't run Windows, so we need a means for our Windows Server 2003 family CA to receive a request from and provide a certificate to these clients.
The Simple Certification Enrollment Protocol (SCEP) is a generic and device-independent way to request and provide certificates. It's so simple that most networking devices can use SCEP even though they may have little else in the way of client functionality. Many Cisco network products support SCEP and provide IPSec functionality at the router based on the certificates they obtain. Microsoft Windows Server 2003 family's CA supports SCEP enrollment using a tool called MSCEP.dll, which is included in the Microsoft Windows Server 2003 Resource Kit. The tool is provided with extensive documentation and is simple to install and configure.
Clients can obtain certificates from a Microsoft CA in a number of ways. To ensure you understand that there are many avenues here, I'll list them with a brief description of each. They include:
Client autoenrollment is a Group Policy-based method for a client to request and retrieve certificates from a CA. It has been described several times throughout this chapter, including detailed steps on how to complete an autoenrollment-based deployment.
Another popular enrollment option is web-based enrollment. In this scenario, clients use their web browser to connect to a CA-aware web site. They can then request, retrieve, and install certificates based on preconfigured settings. This method is generally the most manual and slowest, but is often used because of its simplicity and the universal adoption of web browsers. The web pages are also customizable to allow corporations to control and enhance the user's experience. Plus you can install the web pages on a non-CA to help isolate your PKI from enrollment requests.
For detailed instructions on how to set up and configure web enrollment, see http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CS_CertWebEnroll.asp.
A little-known option for domain-joined clients to obtain certificates is through the Certificates MMC snap-in. In this snap-in, the user can browse to the \Personal\Certificates node, click Action, click All Tasks, then click Request New Certificate. This is a very limited solution though, because any certificate that cannot be automatically approved and installed must be manually retrieved and installed through another mechanism. For this reason, I don't suggest you enroll for certificates in this manner.
ACRS is a holdover from the Windows 2000 PKI architecture. It is a simplistic version of client autoenrollment. You should not use ACRS if you're running Windows Server 2003.
Microsoft provides several API opportunities for you to write your own custom PKI-aware software. This software can request, retrieve, install, and manage certificates for you. Most applications leverage the Microsoft Cryptographic API (CAPI) and the CAPI Component Object Model (CAPICOM). Detailed information on CAPICOM can be found at http://msdn.microsoft.com/library/en-us/security/security/capicom_reference.asp.
Once your certification hierarchy is configured to match your deployment and architectural plans, there's one objective left. You must test the deployment. Client applications should be run repeatedly to ensure the newly issued certificates provide the desired functionality. All possible certificate subjects should attempt to enroll (and reenroll) for certificates to make sure this process is functioning. Clients should also attempt to enroll for certificates that they should not have access to, such as CA certificates or Key Recovery Agent certificates. Finally, the root CA's security should be double-checked. An innocent mistake such as plugging a network cable into the root CA by an uneducated system administrator could bring an offline CA online and subject it to compromise.