9.3 VMware Certificate Authority (VMCA) & TLS Configuration

9.3 VMware Certificate Authority (VMCA) & TLS Configuration

Enterprise virtualization environments process sensitive corporate data, host multi-tenant database clusters, and execute critical control-plane directives. Protecting data in transit across management networks requires an enterprise Public Key Infrastructure (PKI). In VMware vSphere Foundation 9.0, transport security and service-to-service mutual authentication are orchestrated by the VMware Certificate Authority (VMCA) and governed by modern Transport Layer Security (TLS) cryptographic profiles.

---

vSphere 9.0 Certificate Architecture

Every endpoint in a vSphere infrastructure—from the vSphere Client web session to communication channels between vCenter Server and the ESXi hostd agent—relies on X.509 v3 digital certificates to provide identity validation and cryptographic confidentiality.

Certificate Types in vSphere 9.0

Administrators manage several distinct classes of certificates within the environment:

1. Machine SSL Certificate: The external-facing certificate bound to the vCenter Server reverse proxy (Envoy) on TCP port 443. It secures HTTPS sessions established by administrative web browsers, the vSphere Client, command-line interfaces, REST APIs, and external integration points (such as backup appliances and monitoring tools).
2. Solution User Certificates: Used for mutual authentication between internal vCenter services (such as vpxd, the vSphere Client backend vsphere-ui, Content Libraries, and the image transfer service). Monitor their validity and use the supported renewal/replacement procedure. Internal certificates and STS signing certificates have distinct roles; replacing Machine SSL alone does not repair every certificate failure.
3. ESXi Host Certificates: Each ESXi hypervisor maintains its own machine certificate (located on the host at /etc/vmware/ssl/rui.crt). This certificate secures HTTPS host management via the VMware Host Client and the vital TLS control-plane tunnel established between the vCenter Server vpxa agent and the host's hostd daemon.
4. VMware Endpoint Certificate Store (VECS): The local repository inside the vCenter Server Appliance where all service certificates, private keys, and trusted root authority chains (TRUSTED_ROOTS) are securely housed and managed.

---

Certificate Deployment Modes: Architectural Comparison

vSphere supports three distinct architectural deployment models for managing digital certificates, each presenting specific operational advantages and maintenance considerations.

Mode 1: VMCA as Default Root CA

In this default installation mode, the VMCA generates its own self-signed root certificate during initial appliance deployment. When ESXi hosts are subsequently added to vCenter inventory, VMCA automatically generates and pushes unique certificates to each host.

• Advantage: Completely hands-off; requires zero external infrastructure or manual certificate generation.
• Disadvantage: Because VMCA is not part of commercial or enterprise trust chains, web browsers display "Untrusted Certificate Authority" security warnings when accessing the vSphere Client until an administrator exports the VMCA root certificate (https://<vcenter-fqdn>/certs/download.zip) and installs it into corporate client trust stores.

Mode 2: VMCA as a Subordinate (Intermediate) CA

To achieve enterprise compliance without incurring administrative overhead, administrators configure VMCA as an intermediate issuing CA signed by the organization's existing internal enterprise PKI (such as Microsoft Active Directory Certificate Services or HashiCorp Vault).

1. The administrator generates a Certificate Signing Request (CSR) for VMCA.
2. The enterprise root CA signs the CSR, generating a subordinate CA certificate with the BasicConstraints: CA:TRUE extension.
3. The subordinate certificate and the enterprise root chain are imported into VMCA.
4. Moving forward, VMCA continues to automatically issue and rotate certificates for all ESXi hosts and vCenter services, but every issued certificate seamlessly chains up to the enterprise root CA already trusted by all domain workstations.

Mode 3: Custom External Certificates

Under this model, VMCA is entirely bypassed for public-facing endpoints. The administrator manually generates CSRs for vCenter Server and each individual ESXi host, submits them to a public or internal enterprise CA, and manually imports the signed certificates and private keys. While satisfying strict corporate mandates that forbid intermediate CAs, this mode introduces substantial operational burden, as certificate renewals must be tracked and executed manually before expiration across dozens or hundreds of nodes.

---

Certificate Management Tools & Replacement Workflows

vSphere 9.0 provides two primary interfaces for administering certificates: the graphical vSphere Client and the command-line certificate-manager utility.

1. vSphere Client Certificate Management Interface

Located in the vSphere Client under Administration > Certificate Management, this interface provides centralized visibility across the appliance:

• Expiration Monitoring: Displays the validity start date, expiration date, issuing authority, and cryptographic thumbprint for the Machine SSL certificate and all trusted root certificates in the VECS store.
• Replacing Machine SSL: Administrators can import a custom certificate and private key directly through the browser.
• Renewing ESXi Host Certificates: Administrators can renew host certificates directly from the inventory tree without host reboots. Navigate to Host > Configure > System > Certificates, review the active certificate, and click Renew to instruct VMCA to issue and bind a fresh certificate.

2. The certificate-manager CLI Utility

For comprehensive maintenance, root replacement, or disaster recovery, administrators connect to the VCSA via SSH and launch the dedicated command-line tool located at /usr/lib/vmware-vmca/bin/certificate-manager.

The utility provides an interactive eight-option operational menu:

• Option 1 (Replace Machine SSL certificate with Custom Certificate): Imports a third-party or enterprise-signed Machine SSL certificate while leaving internal solution certificates under VMCA management.
• Option 2 (Replace VMCA Root certificate with Custom CA Certificate and replace all certificates): Implements the Subordinate CA architecture by importing an enterprise-signed intermediate CA certificate and automatically reprovisioning all system certificates.
• Option 3 (Replace Machine SSL certificate with VMCA Certificate): Regenerates a new Machine SSL certificate signed by the internal VMCA.
• Option 4 (Regenerate a new VMCA Root Certificate and replace all certificates): Performs a full system rotation, generating a new VMCA root certificate and rolling out new certificates to all local services.
• Option 8 (Reset all Certificates): A broad local-certificate reset workflow whose scope and prerequisites must be verified. It is not the first response to every certificate error and does not reset every managed host certificate.

Follow the selected tool and certificate procedure for reloads or service restarts. Do not restart every appliance service unconditionally after each certificate action.

---

TLS Profiles, Trust and Expiration

Use supported modern TLS profiles and verify every connected client and appliance. ESX 9.0 enables TLS 1.3 on its port-443 reverse-proxy endpoint; other components and ports have their own protocol support. Do not infer that all vMotion, storage and SSH traffic uses the same TLS stack. SSH uses its own host-key trust model.

A trusted connection requires the expected hostname in the certificate, a valid time window and a trusted issuer chain. A not-yet-valid certificate can reflect bad time; a name mismatch can reflect an incorrect endpoint. Check the specific fault rather than replacing every certificate as a first response. Disabling verification is not a trust repair.

Track leaf certificates, roots, solution-user certificates and STS signing validity under their applicable workflow. Alert thresholds are configurable; there is no universal 90/60/30/7-day sequence for every object. Before replacement, save the required backups, validate the certificate/private-key pair and complete chain, identify dependent integrations, and plan supported service restarts. Confirm browser, API and adapter connectivity after the change.

A commonly useful hybrid certificate model replaces the public-facing vCenter Machine SSL certificate with an enterprise-issued certificate while leaving VMCA to manage internal and host certificates. Making VMCA a subordinate enterprise CA is another architecture, but it delegates issuing authority and must satisfy corporate PKI policy. These choices differ in trust scope and operational work; enterprise browser trust does not always require replacing every host certificate.

For failed renewals, preserve error details and use the official procedure for the actual certificate type and release. A full certificate reset has a much wider effect than renewing one host certificate; it is not a universal recovery shortcut.

Source Notes

Broadcom KB 312033 describes ESX port-443 TLS 1.3 support; do not generalize it to every protocol or endpoint. Checked October 18, 2026.

Review Takeaways

• Machine SSL, solution-user, host and STS certificates have different roles and maintenance procedures.
• Validate hostname, dates and issuer chain before accepting or replacing a certificate.
• A hybrid model can use an enterprise Machine SSL certificate while leaving internal issuance with VMCA.
• Use the supported renewal workflow for the affected certificate; broad resets have wider consequences.