vSphere 7 – VMCA as Subordinate / Intermediate CA

Per default, the VMware Certificate Authority (VMCA) comes with its own root certificate and is acting as CA within your vSphere environment. Though VMCA does a great job of automating all the certificate management, it’s both annoying and alarming to see the certificate warning from time to time. Additionally, you might wanna use certificates with actual information in them.
So what you can do, is to make your VMCA a Subordinate CA (or Intermediate CA) of your root CA. Achieving this is actually pretty simple.

Generate Certificate Signing Request (CSR)

SSH into your vCenter and run “/usr/lib/vmware-vmca/bin/certificate-manager

  • Select option 2 “Replace VMCA Root certificate with Custom Signing Certificate and replace all Certificates”
  • Do you wish to generate all certificates using configuration file : Option[Y/N] ?” –> Select Y
  • “Please provide valid SSO and VC privileged user credential to perform certificate operations” –> Enter credentials of a Domain Admin user
  • certool.cfg file exists, Do you wish to reconfigure : Option[Y/N] ?” –> Select Y
    (if its the first time you run this wizard, this message might not appear)

Now it’s straight forward filling in the requested information. Just two notes:
1. Only one Hostname is supported (even though the Wizard implies multiple are possible)
2. VMCA Name is the FQDN of the vCenter

Next, select 1 for “Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate” and provide a directory to save the Certificate Signing Request (CSR).

The wizard has now created the CSR and a private key. In my case:
/tmp/vmca_issued_csr.csr
/tmp/vmca_issued_csr.key

Next step in the wizard is to upload the new certificate, which I need to create first. I’ll leave this session as it is to return here later.
In the background, I’ll download the CSR file with WinSCP.

Request the Certificate

Now as I have the Certificate Signing Request, I can request the actual certificate. The way this works strongly depends on your environment. For a Lab, I could use openssl to first create a proper Root Certificate and use it to sign a Subordinate / Intermediate Certificate for our VMCA.
In my case, I have a Windows CA Server, which I’m going to use.

Navigate to http://<ca-fqdn>/certsrv

Click Request a certificate

Saved Request: Insert the content of our CSR
Certificate Template: Subordinate Certification Authority
The template, I’m using is a default Templates. Of course, you can create your own Template, but make sure that fulfills the requirements like:
basicConstraints = critical,CA:true
keyUsage = critical,digitalSignature,keyCertSign


For more details check the full list of requirements

Click Submit >

Check “Base 64 encoded” and “Download certificate

Get the CA root Certificate

We need to get the Root Certificate of our CA, because vSphere requires a full certificate chain as input. Otherwise, you will get the error
Error Message : Certificate Chain is not complete

RDP into my CA Server –> Run –> certsrv.msc (1) –> Rightclick my CA (2) –> Properties (3) –> General (4) –> View Certificate (5) –> Details (6) –> Copy to File … (7)
If you copy your cert, make sure you choose Base-64 encoded X.509 (.CER)

Upload the Certificate

Before we can upload the new certificate, we first have to create the full certificate chain. So copy both, the vmca.cer and the ca-root.cer into one single file in the following format:

—–BEGIN CERTIFICATE—–
vmca.cert
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
root-ca.cer
—–END CERTIFICATE—–

Transfer the newly created file to your vCenter Server.

Now, return to the vSphere certificate-manager wizard from the beginning. In case you closed it in the meanwhile, you can just rush through the CSR generation again. Just pay attention to not accidentally override the previously created key.

If its still open, choose 1 “Continue to importing Custom certificate(s) and key(s) for VMCA Root Signing certificate”

Provide the path for the certificate chain and the private key.

You are going to replace Root Certificate with custom certificate and regenerate all other certificates” –> Select Y

It will now start to replace / regenerate all certificates. That’ll take a few minutes.
Eventually you will see “Status : 100% Completed [All tasks completed successfully]”

Validate

Navigate to the vSphere WebClient and check the certificate by clicking on the little lock (1) and hover over Certificate (Valid) (2) –> you’ll see that the cert was issued by our VMCA (3).

If you actually click on Certificate (Valid) (2), it will open the certificate –> click the tab “Certification Path“. You can now see the full certificate chain for this certificate with my real Certificate authority at its root.
So we can assume, it worked 🙂

Another way to verify is to log in to your vCenter –> Menu –> Certificates –> Certificate Management
Here, you will find the Machine_Cert (which is actually the one, we just looked at) and in addition, all trusted root certs, which include the VMCA and our Root CA.

Final Words

As you see, from vSphere perspective its really no big deal to change the certifiates. Simply because VMware did a great job in automating most of this under the hood.
Probably the biggest challenge is to convince the security department to issue a intermediate CA certificate to a 3rd Party solution (vmware in this case), that they have no control of.
But (!) – even though, you enable your VMCA to sign certificates, this can only be done internally. This means, the VMCA can only sign the internal services. You can not send any CSR to the VMCA!

2 Replies to “vSphere 7 – VMCA as Subordinate / Intermediate CA”

  1. Hi, thanks for the post.

    I tried the same on VCSA 8, and I get the following error:

    ERROR certificate-manager Error: The same certificate cannot be used by multiple services

    Have you ever faced anything similar?

  2. Last version, I’ve tested it was on vCenter 8U1 and it still worked the same way.
    Haven’t tested in on 8U2 though.

Leave a Reply

Your email address will not be published. Required fields are marked *