The scenario is as follows:
An existing issuing Subordinate Enterprise CA running on Windows 2019 in Australia Southeast
Domain joined and Active Directory Integrated, domain name: capi.allthingscloud.net
Running on Windows 2019, also supported on Windows 2016
TL;DR
Backup the exisiting issuing CA
Create a storage account in Azure to be used as the cluster witness
Add an additional VM in the same Azure region, add it to the same availability of Node1
Domain join the second VM
Create an SSD disk and attach it to both VMs
Move the Certificate Database to the Shared Disk
Install the Windows Cluster features in Node1 and Node2
Create a Windows cluster from Node1
Install the Certificate Services in Node2
Create a Certificate cluster of two nodes, Node1 & Node2
Assign an IP to the cluster, and reserve it on the DHCP in case necessary
Change the required registry settings
Update DNS with the cluster IP
Notes:
Ideally the existing VM belongs to an availability set, if it doesn't the recommendation is to re-create the VM into one, not within the scope of this article.
Clustering is supported only for the Active Directory Certificate Services service. Other Certificate Service role services, such as Web Enrollment, Online Responder, and Network Device Enrollment Service (NDES) are not supported.
The clustered nodes must store the CA database and the CA log file database on shared storage using iSCSI or Shared Bus. The storage must be available to both nodes in the cluster.
The As-Is 🥵
Step by Step 🔢
Backup the existing Enterprise Certificate Authority
[caption id="" align="aligncenter" width="1014"]
Select as shown in the picture, full backup. I will request a password to protect it[/caption]
Create a storage account in Azure to be used as the cluster witness
[caption id="" align="aligncenter" width="2852"]
Attaching the account will happen further, for now is just creation[/caption]
Add an additional VM:
Domain join the second VM
Create an SSD disk and attach it to both VMs
[caption id="" align="aligncenter" width="2812"]
2 Max Shares at the very least[/caption]
Move the Certificate Database to the Shared Disk
I assigned the letter E to the disk but your standards may vary.
First, stop the CA, again, stop the CA. Once the CA is not running then go and change the registry keys in the existing CA to point it to the new shared storage
You will need to use the registry editor to do this
The path for the registry key is located at:
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
- Modify values as per the table below:
Registry Key | Old Value | New Value |
DBDirectory | C:\Windows\System32\Certlog | E:\Certlog |
DBLogDirectory | C:\Windows\System32\Certlog | E:\CertLog |
DBSystemDirectory | C:\Windows\System32\Certlog | E:\CertLog |
DBTempDirectory | C:\Windows\System32\Certlog | E:\CertLog |
Node1
Verify the Certificate Authority's database and logs point to the new database on the share disk, as in the image below:
Install the Certificate Services in Node2
Install Cert Services on the second server- only the certificate authority,
Select enterprise subordinate and restore a backup from Node1 . Do not point the new cert authority to the new storage folder or you will rewrite the CA and you do not want that.
Bring the shared disk online
Stop the newly installed CA
Modify the registry settings and move the CA database toe the newly attached disk, just like in you did in Node 1. They settings are in:
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
Registry Key | Old Value | New Value |
DBDirectory | C:\Windows\System32\Certlog | E:\Certlog |
DBLogDirectory | C:\Windows\System32\Certlog | E:\CertLog |
DBSystemDirectory | C:\Windows\System32\Certlog | E:\CertLog |
DBTempDirectory | C:\Windows\System32\Certlog | E:\CertLog |
Start the Certificate Authority in Node2 check that all the certificates are in place, the settings are normal and so on, this will show that mounting from the shared disk was succesful
Stop the Certificate Authority
Unmount the disk and put it offline
Setup the Cluster 🚀
- Install the Windows Cluster features in the existing CA, Node1. Features-> Failover Clustering, make sure to include the command line
Install the Windows Cluster features in Node2
Create the Cluster from Node1
Once in the Cluster Manager select Create Cluster
Select the nodes that will make the cluster, Node1 and Node2
[caption id="" align="aligncenter" width="1366"]
This will create the cluster but it's pending to assign a service to the cluster[/caption]
Create the witness for the Cluster
- Note: Create the storage account in the same region where the VMs for the cluster are
As a local administrator (of Node 1) Run the following two commands:
Set-ClusterQuorum -NoWitness
Set-ClusterQuorum -CloudWitness -AccountName <name> -accessKey<key>
The cloud witness will be visible in the cluster management console:
Add the shared disk to the Cluster
On Node1, Create a cluster
Mount the shared disk
Enter the cluster name
Select the computers making the cluster, Node1, Node2
Run the cluster testing
Dismiss the 1 NIC only warning
Add the certificate services to the Cluster
Configure Role-> Select Generic Service-> Click Next
Once there, Select Certificate Services
If the shared disk doesn't appear on the select storage, click Next, it will be added later. Also, make sure the disk can be mounted in at least 2 VMs.
To configure a share registry hive, click Add and type, SYSTEM\CurrentControlSet\Services\CertSvc and then click OK, Click Next twice
Review the IP for the cluster
Review the Cluster DNS Name
How the cluster looks like
[caption id="" align="aligncenter" width="1538"]
I tested running one instance of the cluster and works well[/caption]
Modify the Web enrolment
Because a node in this cluster already had the web enrolment this must be fixed by modifying the %systemroot%\system32\certsrv\certdat.inc file change the value of sServerConfig to "<Service Name>\ CA name>"
Note: dnsHostName MUST match the sServerConfig field in the certdat.inc file for the Web Enrolment to work, see image below:
After the cluster is setup
Enable both cluster nodes to update the CA certificate when required
Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.
In the console tree, select the top node. On the View menu, click Show services node.
In the console tree, double-click Services, double-click Public Key Services, and then click AIA.
In the details pane, select the CA name as it appears in the Certification Authority snap-in.
- Add the Cert Publishers group, prior verify it contains both cluster members
Give both nodes permissions on the Enrolment container
Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.
In the console tree, select the top node. On the View menu, click Show services node.
In the console tree, double-click Services, double-click Public Key Services, and then click AIA.
In the console tree, click Enrolment Services. In the details pane, select the CA name.
On the Action menu, click Properties. Click the Security tab, and then click Add.
- Add the Cert Publishers group, prior verify it contains both cluster members
Give both nodes permissions on the KRA container
Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.
In the console tree, select the top node. On the View menu, click Show services node.
In the console tree, double-click Services, double-click Public Key Services, and then click KRA.
In the details pane, select the CA name.
On the Action menu, click Properties. Click the Security tab, and then click Add.
Click Object Types, select Computers, and then click OK.
- Add the Cert Publishers group, prior verify it contais both cluster members
Adjust the certification authority’s DNS Name in Active Directory Domain Services (ADDS)
Log on to a domain controller as a member of the Enterprise Admins group, and open the ADSI Edit snap-in.
In the console tree, click ADSI Edit. On the Action menu, click Connect to.
In the list of well-known naming contexts, select Configuration, and click OK.
In the console tree, double-click Configuration, Services, and Public Key Services, and then click Enrolment Services.
In the details pane, select the name of the cluster CA. On the Action menu, click Properties.
Select the attribute dNSHostName, and click Edit.
- Enter the service name of the CA as shown in the Failover Cluster Manager under Failover Cluster Management, and click OK twice. Close ADSI Edit.
How does it look
Finally, after a long setup because it does take time between setup and testing, the clustered CA works
Proximity Placement Groups
A proximity placement group is a logical grouping used to make sure that Azure compute resources are physically located close to each other. Proximity placement groups are useful for workloads where low latency is a requirement.
I used some references when I was doing research and these post were very useful:
