Configuring and Managing Certificate Services

Now that you are a PKI expert, there are only a few more things to do to complete your design and maintain your infrastructure. After installing your CAs and KMS, you still might need to delegate authority for CA management, and you ll need to set up CRL publication, build a CTL, and do a few other housekeeping tasks .

Delegation and Segregation

For starters, you need to delegate permissions to the appropriate people within the organization. Using the Certification Authority MMC snap-in, right-click the specific CA you want to work with and click the Security tab. From this screen, you can add additional nonadministrator accounts to manage the PKI environment. Unless you have other specific administrative requirements, the default settings are probably appropriate for your CA configuration. In particular, you should be very, very careful not to grant permissions to anyone who doesn t absolutely require them.

Caution  

If you delegate administrative authority for your CA, the administrators of your enterprise CAs hold a very powerful role: they can issue certificates for any person in Active Directory. Beware!

The next layer of control is at the template level. Open the Active Directory Sites And Services snap-in and choose View, then click Show Services Node to see the Public Key Services node within the Services object. Choose the Certification Templates object to adjust the permissions on the templates or delegate the templates folder to others. You will probably want to remove Authenticated Users access from templates that are not used. It is important not to adjust the permissions or try to modify other Public Key Services objects from this tool. Only delegate and modify permissions on the Certification Template objects.

Building Trusts and Trust Lists

If you are planning to establish cross-certification trusts with partners or external CAs, you can now begin working with those organizations to establish a relationship. First, you need to provide copies of your root CA certificates, as well as any certificate superior to it in the CA chain. For example, if your root CA s certificate is signed by an external CA, anyone who wants to trust your CA needs copies of the external CA s certificate, its parent, and so on ”all the way to the self-signed root. Likewise, you ll need the CA certificates for any third parties that you plan to trust; before you can use them, though, you ll have to set up templates appropriate for your requirements.

Publishing the CTL

Using the Active Directory Sites And Services tool or the Active Directory Users And Computers tool, create a new Group Policy Object (GPO) for publishing the CTL. Launch the Group Policy snap-in, then either open an existing object (my favorite is the Default Domain Policy) or create a new one. You can target this policy at any domain, site, or OU, but it s most useful to publish CTLs at the domain level.

Once you ve found the appropriate object, open the User Configuration Windows Settings Security Settings Public Key Policies object and find the Enterprise Trust node. Right-click it and choose the New Certificate Trust List command. Assign a name and validity duration to the new CTL, then select the types of certificates you will allow from the trusted CA. This is helpful not only in allowing access from trusted sources, but for disallowing them as well. If you don t want your clients to automatically trust the CAs distributed by Microsoft, you can override the default trust settings by specifying settings within the CTL.

You can also use GPOs to set up auto-enrollment for machine certificates and machine accounts. Expand the Computer Configuration object, then choose the Windows Settings Security Settings Public Key Policies object. Right-click the Automatic Certificate Request Settings node, then select New to create an automatic certificate request policy. By configuring these options, you can better control the manner in which the PKI is deployed and managed within your environment.

Note  

The KMS also publishes the CRL in the format used by pre-Exchange 5.5 clients.

Certificate Revocation

There will be instances when revoking a certificate is required. To revoke an individual certificate, select it in the Issued Certificates folder of the Certification Authority snap-in, right-click it, and use the All Tasks Revoke Certificate command. You are then prompted to select a reason for the revocation. Click OK when complete. If you are using KMS and wish to revoke a large group, or even all of the e-mail certificates, you can use Exchange System Manager and the Key Manager object to revoke groups of certificates at a time.

Once the certificates have been revoked, you should elect to publish a new CRL. From the Certification Authority console, right-click the Revoked Certificates folder and select All Tasks Publish. After a warning screen, you can click Yes to update the CRL. Remember that clients with a cached copy of the CRL do not get a new copy of the CRL until their cached copy expires .

By default, the CRL is published weekly, but you might decide that a more frequent publishing schedule is appropriate. To change the publishing schedule or disable automatic publishing of the CRL, use the Certification Authority console to right- click the Revoked Certificates folder and select Properties. To view the current CRL, click the button with same name on this screen.

Backing Up and Restoring the CA

Because of the relationship between the server and the CA, the complete backup and restoration of a server is the preferred method of disaster recovery for Microsoft Certificate Services. Having said that, there are additional steps you can take to provide additional recovery options and failsafes in the event of a hardware or server failure. Using the Certification Authority console, right-click the CA in the left pane and choose All Tasks Backup CA, as shown in Figure 12-11.

Figure 12-11: Specify where to back up the CA data.

You need to identify an empty target directory and a new password for the protected keys that you re backing up; these are used for the restore. The result of the export is a set of database, log, import, and system files that can be used to restore a CA.

Note  

Backing up the CA is useful. However, you can t easily restore a CA backup to a newly built machine. Your best bet for a successful restore is to use ntbackup (or a third-party equivalent) to perform a system state backup.

Restoring the CA is somewhat more difficult. The target machine must be running Certificate Services with the same credentials, accounts, name, and overall settings as the source server. In fact, a system state restore and IIS metabase restore might be required, and the file locations and directories must match for the restore and restart of the CA to occur correctly.

The restore process requires only that you right-click the CA again, choose the Restore CA option from the All Tasks menu, and run the Certification Authority Restore Wizard. You need to identify the backup file location and the password. The wizard also requires that the service be stopped and a successful restart depends on the other factors mentioned earlier.

Fine-Tuning CA Security

There are several additional best practices to further secure your environment. For starters, you need to turn off or disconnect the root server from the network. It is good practice to return this server to online status once a month to publish new CRLs and to perform normal change control operations.

In addition, you should enforce stricter security on the Web enrollment pages and the directory in which log files and perhaps database files are located. Using the Internet Services Manager, you should change the permissions on the Certsrv application so that the anonymous account does not have permissions to the application. Moreover, the Integrated Windows Authentication option should be the only one enabled for this object.

For further protection, you should limit the exposure to the database and log files. In fact, there are three specific folders you need to modify with respect to folder access:

• %Systemroot%\ System32 \ Certsrv For this folder, make sure that the Administrators group and the System object are set to Full Control and Authenticated Users is set for Read & Execute, List Folder Contents, and Read.

• %Systemroot%\ System32 \ Certlog For this folder, make sure that the Administrators group, System, and the identified PKI security group objects are set to Full Control. All other permissions should be removed.

• Shared Folder (optional folder share for file access to certificates) For this folder, make sure that the Administrators group, System, and Enterprise Administrators objects are set to Full Control. All other permissions should be removed.