Renewing, Revoking, and Auditing Certificates

---

After you decide how you will distribute certificates, you will need to manage and track the certificates. Certificates are only issued for a period of time; then they will expire, so you will need to come up with a strategy for renewing them. Renewing the certificate and associated key pair can help prevent the key from becoming compromised, but sometimes that key is compromised, so you will need to come up with a strategy for revoking certificates. Revoking a certificate will let clients know that the certificate is no longer trustworthy. Finally, you will need to track what users and administrators are doing with the CAs and certificates by using auditing on the servers.

Renewing Certificates

Certificates are issued for a finite lifetime, which means that they will expire. The lifetime of the certificate will depend on the type of certificate and the policy that the CA has set for the certificates. Certificates will need to be renewed when the lifetime ends. When you renew a certificate, you can choose to keep the same public/private key or generate a new key pair. The longer a key is active, the more vulnerable it is to being compromised. You can reduce the risk of key compromise by renewing the public/private key combination each time you renew a certificate instead of at the maximum lifetime of the key pair. At least, you should never renew the certificate past the lifetime of the key pair. You can also increase the length of the key when you renew a certificate. This means you can use the renewal process to strengthen the key if you determine that it no longer meets your security policy. It is recommended that the key length be somewhere between 1024 and 4096 bits.

CAs also have certificates that are issued from their parent CA or, in the case of the root CA, issued to itself. When these certificates expire, the CA can no longer issue certificates and all certificates that the CA issued will expire. You should remember that when a CA’s certificate expires, all subordinate CAs’ certificates expire. When you renew a CA’s certificate, all subordinate CAs’ certificates will need to be renewed. You will need to come up with a strategy to renew the CA certificates or any certificate before they expire. When renewing CA certificates, you should always generate a new key pair.

The following questions will need to be answered before you can determine a renewal strategy for your certificates:

• Which certificates are you allowed to renew?

• How often can a certificate be renewed before its key is retired?

You can justify longer lifetimes for certificates if they are infrequently used and have strong keys, because a potential cracker won’t have many opportunities to capture them. If the certificate is captured it will be nearly impossible to crack the strong key. You can continue to renew the signature for the certificate up to the issuing CA certificate’s lifetime. On the other hand, if the certificate has a weaker key or is used more frequently, you will want a shorter lifetime. You should renew these certificates more frequently but never beyond the lifetime of the CA certificate.

The following steps will allow you to renew a certificate on a CA:

1. Navigate to Start Program Files Administrative Tools Certificate Authority to open the Certificate Authority console.

2. Right-click on the certificate authority on which you would like to renew the certificate to open the context menu.

3. Choose All Tasks Renew CA Certificate to renew the CA’s certificate.

4. You will then be prompted about changing the length of the key pair used in this certificate. Choose Yes to generate a new key pair or No to keep the existing key pair.

You need to plan on the renewal of the CA certificates before they expire to guarantee uninterrupted certificate services. This has to be done manually for certificates that were requested through a web enrollment page or the Certificate Request And Enrollment Wizard. Clients will not be able to renew or acquire certificates if the CA certificate has expired. You can use the same mechanisms that client computers use to obtain certificates to renew a CA certificate. CA certificates are important and you should use a manual process to renew them. You should pay attention to the length of your public/private key pair. If the key length is inadequate, during the renewal of the certificate you can lengthen it. The key pair has a lifetime that should be set based on the length of the key. Longer key pairs can have a longer life because they are less likely to be cracked. You should generate a new key pair when renewing a CA certificate if the key has expired. This will mean that all certificates based on these keys will need to be renewed, so this will require a great deal of planning for the root CA certificate.

Autoenrollment is the only option that supports automatic renewal of the certificates before they become invalid. It will also support the issuance of pending certificates.

Revoking a Certificate

Sometimes you may have a problem with a certificate; for example, the private key might be compromised or an employee might quit and you no longer want the certificate to be valid. You can invalidate a certificate on the CA and then publish the CRL to the root CA and subordinate CAs. This will allow clients to download the revocation list and verify that the certificate is still valid if it is not on the list. There are many situations that can cause you to revoke a certificate, but the following is a list of possible reasons:

• The CA has been compromised.

• The private key has been compromised.

• A new certificate that replaces the previous certificate has been issued. Perhaps you have a need to update information in the certificate.

• You have decommissioned or replaced the CA.

If you find yourself revoking certificates based on a CA or private keys being compromised, you would be wasting energy revoking and renewing certificates. You should strongly protect the CAs and private keys.

You can configure clients to check the CRL before they accept a certificate. The client can then be configured to either reject the connection or just show a warning box that will state that the certificate has been revoked and ask if the user would like to proceed.

You can publish the revocation list to either the Active Directory or a website. You will need to revoke the certificate(s) before publishing the CRL. The location will be stored in the certificate. Applications must be configured to check the CRL at the publishing point chosen, so this means that the application will need to support the chosen publication point.

The following steps will take you through the process of revoking certificates:

1. Open up the Certification Authority console by navigating to Start Administrative Tools Certification Authority.

2. Expand the CA that contains the certificate that you want revoked.

3. Click on the Issued Certificates container to show the certificates issued by the server.

4. Right-click on the certificate that you wish to revoke and choose All Tasks Revoke Certificate from the context menu.

   

5. Publish the certificate revocation list to the CA hierarchy by right-clicking on the Revoked Certificates container and choosing All Tasks Publish.

If a CA or the private key store is compromised, it can mean that all your certificates are invalid or the policies used to enroll for certificates have been compromised. This means that you need to protect your CAs. The root CA is the most important, and as we discussed earlier, it should be kept offline and only used when it is necessary to add a CA to the network. You will need to assume that someone can bypass your security measures—after all, even trusted administrators may have reason to compromise security—and track access to the CAs.

Auditing Certificate Authorities

You can track access to the files, Registry settings, and CA settings through auditing, so you can track a compromise or attempted compromise of the CA server. You will need to decide what event categories you will need to audit in your organization. This should be based on the security requirements of the organization. You will need to balance the amount of information that you choose to audit. If you audit too little information, you will have great difficulty in determining what happened during a security incident. If you choose to audit too much information, you will either fill up the audit logs with too much useless information that will be difficult to sift through or fill them up to the point that there is no more room and you won’t be to collect data at the time of a security incident. Once you decide how much to audit, you can use a product like Microsoft Operations Manager or performance alerts to set up alerts on the varying event IDs generated by the audit settings to automate the discovery of security incidents.

Your audit policy will contain event categories for the Registry, the file system, and the CA servers. These will be logged to the local security log on the server and can be viewed through the Event Viewer tool.

You can get to the specific auditing settings of a CA by following these steps:

1. Open up the Certification Authority console by navigating to Start Administrative Tools Certification Authority.

2. Right-click on the CA server for which you want to configure the auditing settings and choose Properties from the context menu.

3. Click the Auditing tab to reveal the auditing options.

It is recommended that you enable all of the settings for auditing on a CA.

You should also audit Registry access because, if someone gains access to the Registry, they will have access to the configuration and control over the application. The follow settings are recommended for auditing the Registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration You should audit any failed access for the Everyone account for all permissions.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration You should audit any successful access for the Everyone account for all of the permissions.

The following is a list of the different audit settings you would want to consider when auditing a CA infrastructure:

Note

For more information on securing Windows in general, see “Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP,” available at www.microsoft.com/technet/security/topics/hardsys/tcg/tcgch00.mspx.

Audit Account Logon Events You would use the Audit Account Logon Events setting to log each instance of a user logging on to or off of a computer. The event will be logged into the security log of the computer that validates the account. For example, a domain controller would log the appropriate event for domain accounts, whereas logging on to a computer with a local account will log the appropriate event to the local security log. A local login will not log an account logoff event to the security log. You can set it to Success, Fail, or No Audit to log successful authentications and failed authentications or to not track them at all. You should set Audit Account Logon Events to Success for the domain. That way, if someone accesses the network through an existing user’s account, you can track when it happened. You can also track failed logon attempts to determine if someone is trying to log on to your network. This is not usually recommended, though, because it can lead to a denial of service (DoS) attack, where the attacker just attempts to fill up your security logs with failed logon attempts. Most attackers will not keep trying to log on to the system but will use another means to get passwords.

Audit Account Management Events The Audit Account Management Events setting will allow you to track when someone makes a change to an account. You can track when a user account or group is created, changed, or deleted; when a user account is renamed, disabled, or enabled; or when a password is set or changed. You can use this setting to verify that administrators are following company account policies, to detect if an administrator is trying to elevate permissions, or to detect if someone is trying to attack you by injecting a new account. You would want to set this to audit both successes and failures to log the changes made and attempts to make changes to accounts.

Audit Directory Service Access The Audit Directory Service Access setting will allow you to track changes and access of directory service objects. You would then configure the directory service object’s system access control list (SACL) to specify the auditing condition. You would need to change the setting on this to Success and Failure to be able to audit access to directory service objects.

Audit Object Access The Audit Object Access setting will enable you to specify the audit settings for objects like files, folders, printers, CAs, and Registry settings. The Audit Object Access setting does not enable auditing of objects itself, but it must be set to Success and Failure to audit successful and failed events on each individual object. You need to specify the SACL for each object that you wish to audit to generate events specifically for access to this object. You should choose the specific settings that you want to track on each object. Specifically, for a CA, you will need to audit the following file paths to audit failed attempts to read or modify or successful modifications from any user:

Folder	When to Audit	User	Type of Access
C:\CertSrv	Success	Everyone	Modify
C:\CertLog	Success	Everyone	Modify
C:\Windows\system32\CertSrv	Success	Everyone	Modify
C:\Windows\system32\CertLog	Fail	Everyone	Full Control

You can also turn on auditing for the CA server after you have turned on object auditing.

Audit Policy Change The Audit Policy Change setting will let you log changes to the user rights assignment policies, audit policies, or trust policies. This means that you will be able to track changes to the audit policy or track whether a user account is given a right like Login Locally. You should set this setting to Success only because the Failure setting does not provide useful information. You would want to specifically look at the user rights assignments around the management and operations of a certificate server. The following user rights could impact the security of the CA: Backup Files And Directories and Restore Files And Directories, which allows back up and restore of certificate stores; and Manage Auditing And Security Log, which allows you to configure and view security-related events.

Audit System Events The Audit System Events setting controls the auditing of restart, shut-down, system time change, and other events that affect the system security log. You should set this to Success on the system to audit changes to the system. You would not need to enable Audit Process Tracking and Audit Privilege Use unless a business need justified it. The audit policy is only part of the overall security that you should plan for your CAs.

In the “Designing a Renewing and Revocation Strategy” Design Scenario, you will decide on an audit policy for an organization.

---