Clustered Certification Authority maintenance tasks
Hi all Rob Greene here again. I thought I would share with you how to do some common tasks with a Windows Server 2008 clustered Certification Authority (CA). When the CA is clustered there are definitely different steps that need to be taken when you:
- Make a change to the behavior of the CA by using certutil.exe with –setreg or –delreg switches.
- Modify the registry values in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc hive.
- Renew the CA’s certificate.
In the past before the Certification Authority service (CertSvc) was supported in a cluster, you could make these changes and then stop and start the CertSvc service without a problem. This is still the case when the Certification Authority has not been clustered.
However, when you have the Certification Authority configured as a cluster you must avoid starting and stopping the service outside of the Cluster Administrator snap-in (Cluadmin.msc). The reason is that the Cluster Service not only keeps track of the service state for CertSvc, it is also responsible for making sure that the registry key location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc is saved to the quorum disk when it notices a change to the registry location. This is noted in the CA Cluster whitepaper also, which is required reading for anyone clustering CA’s.
Changing the behavior of the Certification Authority
If you need to make a change to the behavior of the Certification Authority with CertUtil.exe or direct registry modification, you must always follow the steps below:
1. Logon to the active clustered Certification Authority node. If you are unsure which node currently owns the resource do the following:
a. Launch the failover Cluster Management MMC.
b. Select the Certification Authority resource, and in the right hand pane you will see the “Current Owner” (See figure 1).
Figure 1 - Current Owner of the Certification Authority resource
2. Use certutil.exe –setreg (recommended) command, or modify the registry directly.
3. Launch the Failover Cluster Management snap-in.
4. Take the Certification Authority resource (Service) offline and then bring it back online. We have to take the resource offline and back online since the CertSvc service will not read any registry key changes without being restarted, and as I stated above when the CA is clustered you should refrain from stopping and starting the CertSvc service directly.
a. Right click on the Certification Authority resource in the tree view pane.
b. Select either “Bring this service or application online” or “Take this service or application offline” (See figure 2).
Figure 2 - Taking the resource offline / online
Renewing the subordinate Certification Authority certificate
This section discusses the steps that need to be done when renewing a subordinate CA certificate. A Root certification authority shouldn’t be clustered and instead should be configured as an offline root.
Verify the request file location
When the CA certificate is renewed it will stop the CertSvc service to generate the certificate request file. The request file location and name is dictated by the following registry key:
HKEY_Local_Machine\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\RequestFileName
Before renewing the CA you will want to make sure that the registry key points to a valid file system path. If it is not, either the renewal will fail silently, or you might get the error “The system cannot find the file specified” when you attempt to renew the CA. If you have to change this value do the following on the active CA node:
1. certutil –setreg CA\RequestFileName “<File path and name>”. For example:
certutil –setreg CA\RequestFileName "c:\contoso_subCA1.req”
2. Take the resource offline and back online (See Figure 2 above).
Renewing the Certification Authority certificate
As noted earlier, if the CertSvc service is stopped or started outside of the Failover Cluster Management snap-in the cluster system is not aware of any changes that are done to the registry. Here is a high level process of what happens when a CA is renewed so that you can understand why the below steps are necessary on a clustered CA:
1. CertSvc service is stopped to generate the certificate request file. It reads the RequestFileName registry value to determine where and what the file name should be for the request file.
2. CertSvc service is started once the request file has been generated.
3. CertSvc service is stopped again to install the issued certificate from the CA.
4. The CACertHash registry value is updated to include the new CA certificate hash.
NOTE : NEVER DELETE OR MODIFY this registry value unless directed by Microsoft support. Modifying this registry key can cause the CA not to function properly or in some cases to not even start!
Here are the actual steps to renew the CA on a cluster.
1. Open the Failover Cluster Management snap-in.
2. “Pause” the inactive Certification Authority node. If you are unsure about which server is the active node see Figure 1.
a. Select the computer node in the Failover Cluster Management snap-in.
b. Right click on it select “Pause”.
Figure 3 - Pausing the inactive node
3. Once the inactive node is paused you can renew the CA’s certificate. Please review the following TechNet article to help with the process of actually getting the subordinate CA certificate renewed.
4. Once you have gotten the CA’s certificate renewed by the root CA, and installed the new certificate to the subordinate CA you will need to take the Certification Authority resource offline and then back online within the Failover Cluster Management snapin.
a. Right click on the Certification Authority resource in the tree view pane.
b. Select either “Bring this service or application online” or “Take this service or application offline” (See figure 2 above).
5. Open the Certification Authority snapin, and target the Clustered Network resource name.
6. Right click on the Certification Authority name and select properties.
7. If you renewed with a new key pair you should see several certificates listed as show in figure 4.
Figure 4 - Certification Authority properties.
8. Once you have verified that the Certification Authority is using the renewed CA certificate you can “Resume” the node that was paused in step 2.
Since the Certification Authority service is configured as a generic service the above processes must be adhered to when managing a clustered CA. If changes are made outside of the Cluster service’s knowledge then the nodes will never be in sync and clustering will fail
- Rob “Raaaahhb” Greene