VMware Horizon authentication using AzureAD (with multifactor) – Part 1: Setup sub-CA(s)

This is part of a series of post for setting up VMware Horizon authentication using AzureAD.


Sub-CA(s)

First, we are going to set up a subordinate certification authority on our 2 servers. I’m using Windows server 2022, but 2019 or 2016 also works fine. By using a sub-CA, all trueSSO certificate requests are handled by those sub-CAs, reducing the load your the root-CA and we are not dependent on a running root-CA, in case you are running an offline root-CA. Also, we will change some settings so those certificates are not stored in the CA database because that would fill up the database very quickly with new certificates for each user every time they log in. You might not want that on your root-CA.

If you don’t yet have a root-CA in your domain, check out this page to set up your root-CA: Install the Certification Authority | Microsoft Docs.

If you don’t want to set up a sub-CA but just want to use your root-CA for TrueSSO, skip the installation of the sub-CA part and go directly to the Certification template section.

To install a sub-CA, start Server Manager and choose “Add roles and features”. Click next on the welcome page, choose “Role-based or feature-based installation” and choose your local server.

Next, check “Active Directory Certificates” and click “Add features” on the popup screen

Click Next

Click next on the “Features” page, we don’t need anything here

Click next on the “AD CS” page

Check “Certification Authority” and click next

Review the summary and click install to start the installation

Once the installation is completed, click the configure link to start the configuration of the certification authority

In the configuration wizard, be sure to select a user that is an Enterprise Administrator in the domain!

Select the “Certification Authority” and click next

Choose “Enterprise CA” and click next

Select “Subordinate CA” and click next

Select “Create a new key pair” and click next

Leave the default cryptographic options and click next

You can adjust the common name for the CA, but I suggest you just leave the defaults, based on your server name.

Leave the default “Save a certificate request…”. It will save the request file on the root of the C-drive, which we will need later on

Leave the default locations and click next

Review the configuration settings and click “Configure” to complete the configuration

The results page reminds us that we need to manually complete the certificate request

On your root-CA server go to the folder c:\windows\system32\certsrv\CertEnroll\.
We need to copy the .crl and .crt files to the same folder on our sub-CA server we have just installed

On the sub-CA server, right-click your Root-CA certificate file and choose “Install Certificate”

Choose “Local Machine” and click next

Choose “Place all certificates in the following store” and click browse. In the popup window, select “Trusted Root Certification Authorities” and click next until the certificate is imported.

Now copy the certificate request file on the root of the C-drive from your sub-CA to any location on the root-CA server

On the root-CA server, start the Certification Authority console. Right-click the CA and click “All Tasks > Submit new request…”

Choose the .req file you copied from your sub-CA and click open

Next, you need to specify where you want to save the certificate file. Depending on your configuration, You might not get the “save” window. Don’t worry, just continue with the next step.

Go to the “Issued Certificates” and the requested certificate should be the last one on the list. If you can’t find it there, check the “Pending Requests” to see if the request is there and first issue the certificate manually (right-click – issue).
Right-click the certificate and click “Open”.

Go to the Details tab and click “copy to file…”

In the export wizard, choose “Cryptographic Message Syntax Standard” and check “Include all certificates…”

Specify the location where the exported certificate will be saved and complete the wizard

In the end, you will have 3 files for each sub-CA: a certificate request file (.req), a certificate file (.cer), and a PKCS#7 file (.p7b).
In the screenshot below, you see the files for both my sub-CA servers.
You need to copy the .p7b certificate file to the sub-CA server

On your sub-CA server, open the Certification Authority console. You will notice the server is not started yet, as we have no CA certificate installed yet. Right-click the server and select “Install CA Certificate…”

Select the certificate we just copied

Once the CA certificate is installed, right-click the server and start the service

If all went well, you should now see a running sub-CA

As a final step, we need to run the following commands on the sub-CA to allow that the certificates are not stored in the CA database and to ignore offline CRL errors. Open PowerShell and run

certutil -setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS
certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
Restart-Service certsvc

That concludes the sub-CA installation. Remember to repeat this process for the second sub-CA server if you want a high-availability solution.

Now continue with the next part: Certificate Template


This is part of a series of post for setting up VMware Horizon authentication using AzureAD.


2 thoughts on “VMware Horizon authentication using AzureAD (with multifactor) – Part 1: Setup sub-CA(s)”

  1. Pingback: VMware Horizon authentication using AzureAD (with multifactor) – MickeyByte IT Pro Blog

  2. Pingback: VMware Horizon authentication using AzureAD (with multifactor) – Part 5: TrueSSO Setup – MickeyByte IT Pro Blog

Leave a Reply

Your email address will not be published.