Certificate Services Best practices
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Certificate Services Best practices
Plan your public key infrastructure (PKI) before deploying certification authorities (CAs)
- For information that will assist you with planning a PKI, see Certificate Services Concepts in Certificate Services and Certificates Resources in Public Key Infrastructure.
Place database and transaction log files on separate hard drives
As in many databases, the certification authority's database is a file on the hard drive. In addition to this file, other files serve as the transaction logs and receive all modifications to the database before the changes are made. Because these files may be accessed frequently and simultaneously, it is best to keep the database and transaction logs on separate hard drives or high-performance disk configurations, such as striped volumes.
For more information, see Disk Management.
Keep the root certification authority offline and secure its signing key by hardware and keep it in a vault to minimize potential for key compromise
- For more information, see Checklist: Creating a certification hierarchy with an offline root certification authority.
If you are going to use a custom policy module for a Microsoft CA, install Certificate Services using stand-alone policy and then replace stand-alone policy with your custom policy
- Replacing enterprise policy on a certification authority with a custom policy is not supported and will have unpredictable results.
When changing security permissions for the certification authority (CA), always use the Certification Authority snap-in
Setting permissions using other tools (such as the Active Directory Sites and Services snap-in) may create problems for users who attempt to access and request certificates from the certification authority.
For more information, see Set security permissions and delegate control of a certification authority.
Do not issue certificates to users or computers directly from the root certification authority
Instead, deploy at least a two-level CA hierarchy comprised of Root-Issuer CAs to provide flexibility and insulate the root certification authority from attempts to compromise its private key by malicious individuals.
For more information, see Certification authority hierarchies and Establishing a certification hierarchy.
Back up the CA database, the CA certificate, and the CA keys
This is essential to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly), based on the number of certificates issued over the same interval. The more certificates issued, the more frequently you should back up the CA. Full backups should be used to provide the fastest recovery and most reliable data redundancy possible.
For more information, see Backing up and restoring a certification authority.
Ensure that key lifetimes are long enough to avoid renewal issues
A certification authority can issue a certificate with a lifetime equal to or less than the remaining lifetime on its own CA certificate. When the CA certificate has less valid time remaining than the renewal overlap period on issued certificates, the issued certificates are very short lived. In this case, it is possible that clients will be unable to renew their certificates. To avoid this, ensure the CA certificate is renewed long enough before the certificates it issues become short lived.
For more information, see Renew a root certification authority and Renew a subordinate certification authority.
Review the concepts of security permissions and access control, since enterprise certification authorities issue certificates based on the security permissions of the certificate requester
For general information about access control and security permissions in the Windows Server 2003 family, see Access control overview. For the procedure to set access control on a CA, see Set security permissions and delegate control of a certification authority.
For the procedure to set access control on certificate templates, see Controlling enrollment access to certificate templates.
Use Secure Sockets Layer (SSL) when using Web-based certificate enrollment
Web enrollment pages provide a simple but insecure method for users to obtain certificates from the CA. The communication between the client and the Web server could be forged or altered in route, compromising security. To mitigate the risk of this occurring, you can use Secure Sockets Layer (SSL) communications between the client and the Web server. This will provide both confidentiality and integrity of the certificate request and response.
For more information, see Configuring SSL on your server and Set up certification authority Web enrollment support.