Cluster an Existing Windows Certificate Authority in Azure

The scenario is as a 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

It took me about a couple of days to streamline these steps, there’s very little documentation for this specific case, which I will point at the end of this post.

 

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 🥵

1 Single point of failure in the form of a single Virtual Machine for the Enterprise Issuing Certificate Authority

Step by Step 🔢

Backup the existing Enterprise Certificate Authority

Select Backup

Select as shown in the picture, full backup. I will request a password to protect it

Create a storage account in Azure to be used as the cluster witness

These are the properties for the storage account I setup:

  • Performance/Access Tier: Standard/hot
  • Replication: LRS
  • Account kind: Storage V2 (general purpose)

When configured the cluster will simply create a folder with an empty file:

Attaching the account will happen further, for now is just creation

 

Add an additional VM:

Domain join the second VM

This is a mandatory step for an Enterprise CA which will integrated with the Active Directory

Create an SSD disk and attach it to both VMs

Make absolutely sure the disk’s max shares is at least two, obviously for the 2 Virtual Machines running the Certificate Services

2 Max Shares at the very least

Move the Certificate Database to the Shared Disk

Because the CA is running on Node1 the first thing to do is to move the existing database to the new Shared disk, this is how the cluster will operate by having shared storage.

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

To make sure the registry change goes as planned, start the Certificate Services in 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

Once confirmed:

  • 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

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

  • 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

Create the cluster form the Management console

Once in the Cluster Manager select Create Cluster

Create the cluster

 

Select the nodes that will make the cluster, Node1 and Node2

This will create the cluster but it’s pending to assign a service to the cluster

Create the witness for the Cluster

The cluster needs a witness it could use a whole disk but that’d be too expensive and it’s possible to use a storage account which it’s much better in terms of availability and price.

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


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

Select the cluster, right click and select 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

If the cluster has no IP, it won’t work and it won’t start, it’d be a good idea to reserve the cluster IP in the corporate DHCP. In this setup there was not DCHP on the network hence the IP was set manually.

Review the Cluster DNS Name

Verify the DNS Name and make sure it’s added and solvable on the network

How the cluster looks like

The Certificate Service is considered ‘Generic’

I tested running one instance of the cluster and works well

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.
    2. In the console tree, select the top node. On the View menu, click Show services node.
    3. In the console tree, double-click Services, double-click Public Key Services, and then click AIA.
    4. 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.
    2. In the console tree, select the top node. On the View menu, click Show services node.
    3. In the console tree, double-click Services, double-click Public Key Services, and then click AIA.
    4. In the console tree, click Enrolment Services. In the details pane, select the CA name.
    5. 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.
    2. In the console tree, select the top node. On the View menu, click Show services node.
    3. In the console tree, double-click Services, double-click Public Key Services, and then click KRA.
    4. In the details pane, select the CA name.
    5. On the Action menu, click Properties. Click the Security tab, and then click Add.
    6. 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.

It’s advisable this set of servers placed in a placement group because it will guarantee a low latency.

 

I used some references when I was doing research and these post were very useful:

  • https://social.technet.microsoft.com/wiki/contents/articles/15067.step-by-step-guide-clustering-an-existing-certification-authority.aspx#Verify_and_Document_the_Active_Directory_Certificate_Services_ADCS_DNS_Name
  • https://www.vkernel.ro/blog/clustering-active-directory-certificate-services-ad-cs