Cluster an Existing Windows Certificate Authority in Azure

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

  • Performance/Access Tier: Standard/hot

  • Replication: LRS

  • Account kind: Storage V2 (general purpose)

[caption id="" align="aligncenter" width="2852"]

Attaching the account will happen further, for now is just creation[/caption]

Add an additional VM:

  • In the same Azure region

  • In the same availability set

  • In the same Vnet

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

The registry keys

  • 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:

Right click on the CA properties and select Storage

  • Stop the CA

  • Bring the shared disk offline

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

  • I decided to make Node1 the manager of the cluster and install it here first, simply logic: it's the original node.

  • Reboot Node1

Install the Windows Cluster features in Node2

  • Install the Windows Cluster features in Node2. Features-> Failover Clustering, make sure to include the command line

  • Reboot Node2

Create the Cluster from Node1

  • Mount the shared disk first

  • Open the Cluster Manager console

Once in the Cluster Manager select Create Cluster

Create the 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

Take note of the access key and name for the storage account

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:

The Cloud Witness

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

Select Generic Service

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>"

sServerConfig be = to the FQDN of the clustername

Note: dnsHostName MUST match the sServerConfig field in the certdat.inc file for the Web Enrolment to work, see image below:

dnsHostName MUST match the certdat.inc name for the Web enrollment to work

After the cluster is setup

Enable both cluster nodes to update the CA certificate when required

    1. Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.

      1. In the console tree, select the top node. On the View menu, click Show services node.

      2. In the console tree, double-click Services, double-click Public Key Services, and then click AIA.

      3. In the details pane, select the CA name as it appears in the Certification Authority snap-in.

        1. Add the Cert Publishers group, prior verify it contains both cluster members

Enable both cluster nodes to update the CA certificate when required

Give both nodes permissions on the Enrolment container

    1. Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.

      1. In the console tree, select the top node. On the View menu, click Show services node.

      2. In the console tree, double-click Services, double-click Public Key Services, and then click AIA.

      3. In the console tree, click Enrolment Services. In the details pane, select the CA name.

      4. On the Action menu, click Properties. Click the Security tab, and then click Add.

        1. Add the Cert Publishers group, prior verify it contains both cluster members

Give both nodes permissions on the Enrolment container

Give both nodes permissions on the KRA container

    1. Log on to a domain controller as a member of the Enterprise Admins group, and open the Active Directory Sites and Services snap-in.

      1. In the console tree, select the top node. On the View menu, click Show services node.

      2. In the console tree, double-click Services, double-click Public Key Services, and then click KRA.

      3. In the details pane, select the CA name.

      4. On the Action menu, click Properties. Click the Security tab, and then click Add.

      5. Click Object Types, select Computers, and then click OK.

        1. Add the Cert Publishers group, prior verify it contais both cluster members

Give both nodes permissions on the KRA container

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: