Simplifying Certificate Trust in Multi-Lab Environments

In my lab I have a jump box that I typically use for management. It is joined to active directory and automatically trusts my primary CA root certificate. This CA issued the Machine SSL certificate for my vCenter Server, so when I go to that system I do not get a certificate warning. However, if I go to an ESXi host, which gets its cert from the self-signed VMCA, I do get a certificate warning. There is another lab I connect to that has a different certificate authority, and I get certificate warnings for all the systems in that environment. I decided to implement a group policy to try and add these additional root CAs to the systems in my lab.

Gathering the root certificates

For the separately managed lab I connect to, the certificate authority runs on Windows. If I navigate to https://ca.other.domain/certsrv/, I can use the “Download a CA certificate, certificate chain, or CRL link” to download the Base 64 encoded CA certificate. This downloads a .cer file that I can import as a trusted root authority to start trusting this lab systems.

For the VMCA certificate, there were a few additional steps. On the landing page for https://vc1.example.com, there is a “Download trusted root CA certificates’ link.

This downloads a zip file, which in my environment contains a handful of certificate file (as well as some certificate revocation lists). I don’t want to import all these certificates, so I need to figure out which one(s) are required.

In the vCenter Server > Administration > Certificates > Certificate Management > Trusted Root tab, I can see a similar sized list of certificates. Some of these are external certificate authorities I’ve created over the years. There is an old entry for a decommissioned external PSC, and another vCenter that was once in an enhanced linked mode relationship. The certificate that I believe I need is the first one, named VMCA_ROOT_CERT. It was issued and expires on the same date as some of the other certs in that list.

If I expand the details of the VMCA_ROOT_CERT cert, I can see a serial number which appears to be unique.

I now need to cross reference the serial numbers of the certificate files I downloaded with this specific cert that I want. Since there are a handful of files, I looked to PowerShell to help me decode each of the certificate files. This block of code:

foreach ($thisCertFile in (Get-ChildItem D:\Downloads\download\certs\win\*.crt)) {
  $thisCertSN = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($thisCertFile.FullName)
  [pscustomobject][ordered]@{
    File = $thisCertFile.Name
    CertSN = $thisCertSN.serialNumber
  }
}

Creates a listing of file names & the certificate serial number:

File           CertSN
----           ------
33356f5f.0.crt 00EA8A640D6672D7FE
5150e350.0.crt 59D71C83C3F9F48B402DAAFDECF3A063
8ff1896d.0.crt 00F0B6452CFEF6D1A6
8ff1896d.1.crt 00C0320CF0A9E111C3
b9cd01bb.0.crt 5FC56597C188F1874C86504CCE7D53ED
c99d48fd.0.crt 00E6BC43B739FADB16

Unfortunately, I don’t see the desired serial number in that list. In fact, the numbers appear to be completely different, as if the UI is showing a decimal number (numbers only) while PowerShell decoded a hexadecimal value (based on the mix of numbers and letters).

To test that out, I converted the web interface value to hexadecimal and it was F0B6452CFEF6D1A6. I do have a *D1A6 serial number in file 8ff1896d.0.crt, which confirms this is the interesting file containing the proper root certificate.

Creating the Group Policy

Its been years since I’ve worked with group policy. I created a new certificate named Trusted Root CAs. In the properties of this new certificate, I checked the box to ‘Disable User Configuration settings’. This policy will only include the desired Trusted Root CAs, which is a computer based policy, so I don’t need to include anything related to users in this policy.

I then browsed to the appropriate portion of the group policy to add these certificates:

• Computer Configuration
• Policies
• Windows Settings
• Security Settings
• Public Key Policies

I then right clicked on Trusted Root Certification Authorities and selected Import. I then followed the wizard to import these as computer-based certificates in the ‘Trusted Root Certification Authorities’ store.

I did this for both the Windows based CA and the vCenter Server VMCA based certificate.

Testing the policy

I then linked the new policy to a test organizational unit, which only contained a single test machine. To ensure that the current policies were applied correctly, I ran the following as an administrator:

gpresult /force

I then opened the Microsoft Edge browser and attempted to connect to a vCenter Server in the separate / standalone lab environment and was not prompted with a certificate warning. I then attempted to connect to an ESXi host in my main lab, and again was not prompted with a certificate warning.

Applying setting to all systems

After testing to confirm that I had the correct root CA certificates in the policy, I linked the policy to the root of the domain. I then tested connecting to systems signed by these other roots on my primary admin jump box and did not see certificate warnings there either.

Conclusion

By centrally managing trusted root CAs through Group Policy, I’ve eliminated the certificate warnings that were slowing me down when connecting to vCenter Servers and ESXi hosts across multiple labs. This approach also ensures consistency for all domain-joined management systems without needing to import certificates manually on each machine.