6.5 vSphere Certificate Management
Key Takeaways
The VMware Certificate Authority (VMCA) issues vCenter's machine SSL certificate, solution user certificates, and ESXi host certificates by default.
Hybrid mode replaces only the machine SSL certificate with one signed by an enterprise CA and leaves VMCA to manage solution user and ESXi certificates.
If policy requires every certificate to be signed by the enterprise CA with no intermediate CA, replace the machine SSL and solution user certificates with custom enterprise-CA certificates.
The vCenter advanced setting vpxd.certmgmt.mode sets the ESXi certificate mode: vmca (default), custom, or thumbprint (a legacy troubleshooting mode).
vSphere 8.0 rejects certificates signed with SHA-1 or other weak algorithms, and upgrade prechecks block the upgrade if such certificates are in use.
6.5 vSphere Certificate Management
Where vSphere Uses Certificates
| Certificate | Used For |
|---|---|
| Machine SSL certificate | vCenter's HTTPS endpoint (the reverse proxy on port 443, which serves the vSphere Client and APIs). This is the certificate browsers see |
| Solution user certificates | Service identities (such as machine, vpxd, vpxd-extension, and vsphere-webclient) that authenticate vCenter services to Single Sign-On |
| ESXi host certificates | Each host's HTTPS identity (rui.crt), used when vCenter connects to the host |
| VMCA root (signing) certificate | The CA that signs VMCA-issued certificates |
| STS signing certificate | Signs SSO tokens (Section 6.1; vSphere 8 renews a VMCA-generated STS certificate automatically) |
| Trusted root certificates | CA chains that vCenter trusts, such as your enterprise root |
vCenter stores certificates in the VMware Endpoint Certificate Store (VECS). You manage them in the vSphere Client under Administration > Certificates > Certificate Management, or with the certificate-manager utility (/usr/lib/vmware-vmca/bin/certificate-manager). The vecs-cli and dir-cli tools cover advanced tasks.
The Four Approaches
| Approach | Who Signs What | Trade-off |
|---|---|---|
| VMCA default | VMCA's self-signed root signs everything | Least effort. Browsers warn until you trust the VMCA root, which you can download from vCenter's landing page |
| Hybrid | An enterprise CA signs the machine SSL certificate; VMCA keeps signing solution user and ESXi certificates | The common, low-overhead choice: users see a trusted certificate and internal certificates stay automated |
| VMCA as intermediate (subordinate) CA | You replace VMCA's signing certificate with one issued by your enterprise CA; VMCA then issues all certificates under your chain | Everything chains to your PKI, but VMCA becomes an intermediate CA you must protect |
| Custom (full external) | Your enterprise CA signs every certificate: machine SSL, solution users, and ESXi | The most control and the most work. You renew everything yourself |
Reading the Official Sample Question
If policy says every solution must use certificates signed by the enterprise CA and no intermediate CAs are allowed in the chain, then:
- VMCA as a subordinate CA is ruled out, because it adds an intermediate.
- VMCA self-signed certificates are ruled out.
- So you replace the solution user certificates and the machine SSL certificates with custom certificates from the enterprise CA.
The Role of the Enterprise PKI (4.13.1)
An enterprise public key infrastructure (PKI) such as Microsoft AD Certificate Services:
- Signs certificates that clients already trust. Its root is in every domain-joined browser, so there are no warnings.
- Provides the trusted root and intermediate chain, which you add to vCenter's trusted root store and upload when you import a signed certificate.
- Publishes revocation information (CRL or OCSP) and enforces certificate templates, such as key usage and validity.
- Can act as the parent CA for VMCA in subordinate mode.
Replacing the Machine SSL Certificate (Hybrid Mode)
- In Certificate Management, open the Machine SSL Certificate and choose Generate Certificate Signing Request (CSR).
- Submit the CSR to the enterprise CA with the appropriate template.
- Choose Import and Replace Certificate and upload the signed certificate together with the CA chain.
- vCenter restarts its services. Browsers now trust vCenter through the enterprise root.
Before replacing certificates in an Enhanced Linked Mode group, take the offline snapshots and file-based backups described in Section 1.5.
ESXi Certificate Modes
The vCenter advanced setting vpxd.certmgmt.mode controls how vCenter handles host certificates:
| Mode | Behavior |
|---|---|
| vmca (default) | vCenter provisions and renews ESXi certificates from VMCA. In the vSphere Client, use Renew or Refresh CA Certificates on a host |
| custom | You install CA-signed certificates on hosts yourself, and vCenter does not overwrite them. Set this before adding hosts that already have custom certificates |
| thumbprint | A legacy mode that checks only the certificate hash. Use it only temporarily for troubleshooting; vCenter 8.x raises an alarm that it is deprecated |
Monitoring and Hygiene
- vCenter's certificate status alarm warns before certificates expire (30 days ahead by default), and Certificate Management shows expiration dates.
- vSphere 8.0 no longer supports certificates signed with SHA-1 or other weak signature algorithms, and upgrade prechecks block the upgrade until they are replaced.
- Keep the enterprise root and intermediates in vCenter's trusted root store. A missing intermediate is a classic cause of identity-source and replacement failures (Section 6.1).
certificate-manager Menu Options
The certificate-manager utility on the vCenter appliance offers numbered operations that map directly onto the approaches above:
| Option | What It Does | Approach |
|---|---|---|
| 1 | Replace the machine SSL certificate with a custom certificate | Hybrid or full custom |
| 2 | Replace the VMCA root certificate with a custom signing certificate and replace all certificates | VMCA as intermediate CA |
| 3 | Replace the machine SSL certificate with a VMCA certificate | Back to VMCA-signed |
| 4 | Regenerate a new VMCA root certificate and replace all certificates | VMCA default (new root) |
| 5 | Replace solution user certificates with custom certificates | Full custom |
| 6 | Replace solution user certificates with VMCA certificates | VMCA-signed |
Troubleshooting Certificate Problems
| Symptom | Likely Cause | Fix |
|---|---|---|
| Browser warns about vCenter's certificate | Machine SSL still signed by VMCA, whose root the browser does not trust | Trust the VMCA root, or move to hybrid mode |
| Import of a signed certificate fails | Missing intermediate or root in the uploaded chain | Upload the full CA chain, and add the roots to the trusted root store |
| Hosts disconnect after a CA change | Hosts don't trust the new chain, or the host certificates need renewal | Refresh CA Certificates and Renew the host certificates (vmca mode), or install new custom host certificates (custom mode) |
| vSphere Client logins fail with token errors | STS signing certificate expired (custom STS, or auto-renewal failed) | Refresh or replace the STS certificate (Section 6.1) |
| Upgrade precheck blocks vSphere 8 | A certificate uses SHA-1 or another weak signature | Reissue it with SHA-256 or stronger |
A corporate security policy states that all vSphere solutions must use only certificates signed by the enterprise certificate authority, and that no intermediate CAs are allowed in the certificate chain. Which approach meets the policy?
Keep VMCA default certificates and add the VMCA root to the browsers' trusted store
Replace the VMCA signing certificate so VMCA acts as a subordinate CA of the enterprise CA
Replace only the machine SSL certificate with an enterprise-CA certificate (hybrid mode)
Replace both the machine SSL certificates and the solution user certificates with custom certificates from the enterprise CA
Users see browser warnings when opening the vSphere Client. The security team wants a trusted certificate for users but wants VMCA to keep automating internal and ESXi certificates. Which approach should be used?
Hybrid mode: replace only the machine SSL certificate with an enterprise-CA-signed certificate
Set vpxd.certmgmt.mode to thumbprint
Full custom mode for all solution user and ESXi certificates
Regenerate a new VMCA root certificate and replace all certificates
An administrator plans to install certificates signed by the corporate CA directly on new ESXi hosts before adding them to vCenter. Which vCenter setting should be configured first so vCenter does not replace them with VMCA certificates?
Set vpxd.certmgmt.mode to custom
Set vpxd.certmgmt.mode to thumbprint
Enable Lockdown Mode on the hosts
Set Config.HostAgent.plugins.solo.enableMob to true
Sections you finish are checked off in the contents.