VCF 9 Certificate Management: Custom CA and Auto-Renewal

Short answer: In VCF 9, the certificate authority you choose decides who renews each certificate. Certificates signed by a CA configured in VCF Operations (VMCA, Microsoft CA or OpenSSL CA) can be renewed manually or automatically from Fleet Management, 60 days before expiry. Certificates signed by an external CA that you import are yours to renew. And once ESX hosts get CA-signed certificates through Fleet Management, vCenter switches to custom certificate mode, so every new host needs a CA-signed certificate before you commission it.

Part of the series “vCenter and VCF Certificate Management: Diagnosis, Renewal, and Operations”: vCenter Certificate Auto-Renewal: When You Still Need vCert (start here) · STS_INTERNAL_SSL_CERT Explained: What vCert’s LEGACY Result Means · vCenter Certificate Alarm After Renewal? Check the Backup Stores

Table of Contents

Where certificate management lives in VCF 9

Fleet-wide certificate work is done in the VCF Operations console. The menu path depends on the version of the documentation you follow:

VCF 9.0: Fleet Management > Certificates, then VCF Management (fleet components) or VCF Instances and pick an instance or domain.
VCF 9.1: Manage in the top navigation bar, then Fleet management > Certificates in the left pane. The same VCF Management / VCF Instances split applies.

The scope split matters. The CA and the auto-renewal setting are configured separately for VCF management components (VCF Operations, VCF Automation, identity broker, logs, networks, fleet management services) and for each VCF Instance (vCenter, ESX, NSX Manager, SDDC Manager). Three instances means three instance-level CA configurations to keep consistent. The same screens show certificates and Certificate Alerts, and let you generate CSRs, import and replace; 9.1 adds bulk operations.

Configured CA versus imported certificate

This is the distinction that drives the whole operating model. The VCF 9.1 documentation lists three configured CA types:

VMCA: the default signing CA, embedded in vCenter.
Microsoft CA (AD CS): integrated through the /certsrv web enrollment URL, a least-privileged service account and a certificate template you create on the CA.
OpenSSL CA: the CA embedded in SDDC Manager.

Scope is version-specific. The VCF 9.0 “Configure a Certificate Authority” page says that VCF management components support only Microsoft CA, while VCF Instance components support Microsoft CA and OpenSSL. The VCF 9.0 blog adds that the Fleet Management appliance acts as the CA for the management components when you leave them at their defaults. In 9.1, check the supported combinations for your build before you standardise.

Anything else counts as an external CA: a public CA, or an enterprise PKI that is not wired into VCF Operations. The 9.1 documentation is explicit about what that means in practice:

Operation in VCF Operations	Configured CA	External CA	Self-signed
Generate CSR / import	Yes	Yes	No
Manual renew	Yes	No	No
Auto-renew	Yes	No	No
Replace with VMCA-signed (9.1.1+)	Yes	Yes	Yes
Auto-replace with VMCA before expiry (9.1.1+)	n/a	Yes	No
Monitor for expiry	Yes	Yes	Yes

Summarised from the VCF 9.1 “Managing Certificates in VMware Cloud Foundation” page.

So an imported certificate is monitored but not renewed. For an external CA the cycle is manual: generate a CSR, have it signed outside VCF, import it (base64 .crt, .cer, .pem, .p7b or .p7c), then use Replace with imported certificate. Expired certificates cannot be replaced, so this must happen before expiry. The 9.1.1 auto-replace with VMCA is a fallback that changes the issuer, which your security team may not accept.

What auto-renewal actually covers

When you use Activate Auto-renewal at the management or instance level, VCF renews TLS certificates that meet two conditions: they were signed by a configured CA, and the component supports non-disruptive certificate (NDC) updates. Renewal starts 60 days before expiry. The 9.0 documentation lists the NDC-managed certificates: ESX SSL, vCenter machine SSL, NSX Manager (local manager and VIP), SDDC Manager, VCF Identity Broker, VCF Operations, VCF Automation, VCF Operations for logs, VCF Operations for networks, and Fleet Management.

Limits to plan around:

Microsoft CA and OpenSSL auto-renewal needs the CA configured first. A Microsoft CA must be reachable from VCF Operations and time-synchronised with SDDC Manager.
Root and intermediate certificates are never renewed.
In 9.1, if a certificate is already inside the 60-day window, renew it manually before you turn auto-renewal on.
System-managed certificates, such as internal certificates without a customer-facing API, are renewed by their own component. VCF Operations only monitors them and raises an alert if that renewal fails.
vCenter also has its own native auto-renewal (vCenter 8.0 U3h / VCF 9.0.2 and later). According to KB 427937, it renews ESXi certificates 10 days before expiry (vpxd.certmgmt.certs.autoRenewThreshold) and the machine SSL certificate 5 days before, and it does not work when the certificate mode is custom. For VCF, Broadcom recommends configuring the CA in Fleet Management instead. The auto-renewal article in this series covers the vCenter side.

Custom certificate mode and new ESX hosts

This is the part that catches teams during expansion. KB 427937 says that the first time you configure an ESX host with a CA-signed certificate through Fleet Management, vCenter’s vpxd.certmgmt.mode advanced setting changes to custom. As a result, you must apply a CA-signed certificate to new hosts before you commission them. KB 417983 adds that the switch happens even when the replacement certificate comes from VMCA, because vCenter does not allow ESX certificate changes outside custom mode. After the switch, vCenter raises the alarm “When ESXi Certificate Mode is set to custom it is mandatory to add the custom CA certificates to vCenter trusted root store before updating the host certificates”. The KB treats this as expected and says you can reset it to green.

In custom mode, vCenter no longer provisions VMCA certificates to hosts, and certificate management becomes your responsibility (see vSphere 9.0 “Change the ESX Certificate Mode”). If you try to commission a host that still has its default certificate, it can fail validation with Host SSL certificate is not trusted by SDDC Manager / SDDC_TRUST_HOST_SSL_CERT_FAILED (KB 415767, VCF 5.2.x and 9.x). The commissioning documentation states the same rule for deployments done with external ESX certificates: all hosts added later must also use external certificates.

A repeatable onboarding procedure for a fleet in custom mode:

Check the mode on the target vCenter: Configure > Advanced Settings, filter on vpxd.certmgmt.
Prepare the host as usual: DNS forward and reverse records, host name equal to the FQDN, self-signed certificate regenerated for the FQDN.
Issue a certificate for the host from the same CA chain the rest of the domain uses. Include the FQDN in the SAN; in 9.1, VCF Operations requires both the FQDN and the IP in the SAN for certificates it generates or imports.
Install it on the host (/etc/vmware/ssl/rui.crt and rui.key, then restart hostd and vpxa), following “Configure ESX Hosts with Signed Certificates”.
Make sure the issuing root and any intermediates are trusted by vCenter and SDDC Manager, then commission the host.
After the host is added, confirm it appears under the instance in Fleet Management with Show ESX Hosts turned on, and that it falls under auto-renewal if its issuer is a configured CA.

KB 415767 also describes a workaround for environments that moved to external certificates after bring-up: temporarily set the mode back to vmca, commission the host, then revert. The new host then carries a VMCA certificate that you still have to replace, so treat this as an exception.

Certificate ownership matrix

A template to complete for your own fleet. Rows reflect the documented behaviour described above. Where the documentation does not settle a cell for every deployment, the cell says “check your deployment”.

Component	Issuer	Renewal mechanism	Monitoring	Onboarding procedure
vCenter machine SSL	VMCA, Microsoft CA or OpenSSL CA (configured)	Fleet Management auto-renewal, 60 days before expiry (NDC)	Fleet Management > Certificates, Certificate Alerts	Replace with configured CA certificate at instance level
ESX host SSL	Configured CA (mode switches to custom)	Fleet Management auto-renewal (NDC)	Certificate Alerts, Show ESX Hosts; vCenter host certificate alarms	CA-signed certificate on the host before commissioning
NSX Manager (LM and VIP)	Configured CA	Fleet Management auto-renewal (NDC)	Certificate Alerts	Check your deployment
SDDC Manager	Configured CA	Fleet Management auto-renewal (NDC)	Certificate Alerts	Check your deployment
VCF Operations, Automation, logs, networks, identity broker, Fleet Management	VCF 9.0: Microsoft CA or Fleet Management default CA; 9.1: check your deployment	Management-level auto-renewal (NDC)	Certificate Alerts (VCF Management)	Check your deployment
Any component with an imported external-CA certificate	External / public CA	Manual: CSR, sign, import, replace, before expiry	Expiry monitoring in VCF Operations	Your PKI process; record the owner and expiry date
System-managed internal certificates	Component-internal	Renewed by the component itself	VCF Operations alerts on failed renewal	Check your deployment

In your own copy, add a named owner and the CA template used for each row. Use the same CA settings (URL, template, service account) in every VCF Instance, and keep imported external-CA certificates to a minimum, because each one is a manual renewal. If the CA wizard fails in VCF 9.0, see the KB 406901 write-up.

Sources

Related on vdan.cz

Author: Daniel Micanek

Senior Service Architect, SAP/TDL Platform Services Team at Vivicta | vExpert ⭐⭐⭐⭐⭐⭐⭐ | Broadcom Knight: vSphere Kubernetes Service, VCF Networking (NSX), VCF Automation | Broadcom Software Knight: vSphere | Cisco Champion. Notes from running about 1,000 ESXi hosts on Cisco UCS, VCF 9 and SAP HANA on vSphere. View all posts by Daniel Micanek