Dr. Pranay Jha

Certificates are the chore everyone postpones until something breaks: an expired cert locks you out of a UI, a browser throws a warning your security team will not ignore, or an audit flags self-signed certificates across the stack. VCF 9 changes the experience in a way that genuinely matters operationally. Certificate management is no longer scattered across SDDC Manager and a dozen component UIs; it is centralized in the VCF Operations console, and it finally ships automatic certificate renewal for the components that used to cause the most outages.

This guide walks the full lifecycle end to end: how certificates work in VCF 9, preparing your Certificate Authority, generating a CSR, getting it signed, replacing the certificate, and turning on auto-renewal. It pairs with Part 22, which covers certificate, identity and backup failures — this part is the build-it-right companion to that fix-it-when-broken piece.

Why certificate handling is different in VCF 9

Everything runs over TLS, and defaults are not production-grade

Every management interface in VCF is reached over TLS. During deployment each component is issued a certificate from a default signing authority — VMCA or a self-signed certificate. That is fine for bring-up but not for production. You replace those defaults with certificates signed by your enterprise CA so browsers and API clients trust the endpoints without warnings, so you meet internal security and compliance requirements, and so revocation and rotation follow your organization’s PKI policy. You also replace a certificate when it has expired or is nearing expiry, when the issuing CA revokes it, and optionally whenever you stand up a new workload domain.

The console moved — it is one place now

The biggest shift is where you do this. In earlier releases you bounced between SDDC Manager and per-product certificate screens. In VCF 9, certificate operations for the whole fleet live in the VCF Operations console: view certificates and alerts, configure a CA, generate CSRs, replace certificates, and enable automatic renewal — for both the management layer and your VCF instances, from a single dashboard.

The two scopes: VCF Management vs. VCF Instances

This distinction trips people up, so be precise about it. VCF 9 splits certificate management into two scopes with different rules. You configure the CA for each scope separately, and if you run more than one VCF Instance you configure each instance individually — the management plane and your workload domains are never set in a single shared step.

Scope	Components	Supported CA	Auto-renew
VCF Management	Fleet Management, VCF Automation, Identity Broker, VCF Operations, Operations for Logs, Operations for Networks	Microsoft CA only	Yes (Microsoft CA)
VCF Instance / domain	ESX hosts, NSX Manager, SDDC Manager, vCenter	Microsoft CA or OpenSSL (external CA via import)	Yes (Microsoft CA)

Table 1 — Scope determines which signing authority you can use.

VCF 9 also supports non-disruptive certificate updates and auto-renewal for the core certificate set — ESX SSL, vCenter machine SSL, NSX LM and VIP, SDDC Manager SSL, VCF Identity Broker, VCF Operations, VCF Automation, Operations for Logs and Operations for Networks. Managing these from VCF Operations is exactly what lets you enable auto-renewal and avoid the outages certificate rotation used to cause.

Choosing your signing approach

Before you touch the console, decide how certificates get signed. There are three practical paths, and the choice affects whether you get the auto-renewal payoff.

Approach	Where it works	Auto-renew	Best for
Integrated Microsoft CA	Management + Instances	Yes	Production with AD CS
Integrated OpenSSL	Instances only	Yes	Lab / no Microsoft CA
External / third-party CA	Any (manual import)	No	Public CA or strict PKI

Table 2 — Signing approaches compared.

The decision tree below is the fastest way to land on the right path for a given component. The rest of this guide follows the integrated Microsoft CA flow — the most common production choice — and then covers the external-CA variation.

The end-to-end pipeline at a glance

Whatever signing path you choose, the lifecycle is the same shape: configure the CA, generate a CSR, sign it, replace the live certificate, then let auto-renewal keep it current. Hold this picture in your head as we go through each step — every action below maps to one stage of it.

Step 1: Prepare your Microsoft Certificate Authority

The integrated flow only works if your Microsoft CA is set up to accept requests from VCF. This preparation happens on the Windows CA server, not in VCF, and it has four parts plus two easily-missed prerequisites.

Install the required roles

On the Microsoft CA server install the Certificate Authority role and the Certificate Authority Web Enrollment role. The web enrollment role exposes the certsrv endpoint that VCF Operations calls to submit requests.

Enable Basic Authentication over HTTPS

VCF authenticates to the web enrollment interface using HTTP Basic Authentication. Configure the site for basic auth and make sure it is served over HTTPS. Basic auth transmits credentials in an easily decoded form, so TLS transport encryption is not optional here — it is the only thing protecting that service account password in flight.

Create and publish a certificate template

Create a template in the Microsoft CA carrying the signing attributes VCF needs, then add it to the CA’s list of issued templates. Note the exact template name — it is case-sensitive when you enter it in VCF Operations later, and a casing mismatch is one of the most common reasons CA configuration fails.

Create a least-privileged service account

Rather than handing VCF a domain admin, create a dedicated Active Directory account (for example svc-vcf-ca) and grant it only the certificate-management privileges it needs on AD CS. You will use this account in the CA configuration.

Step 2: Configure the Certificate Authority in VCF Operations

With the CA prepared, connect VCF to it. Log in to the VCF Operations console at https://<vcf_operations_fqdn> as a user with the Administrator role, go to Fleet Management > Certificates, choose your scope (VCF Management, or VCF Instances and a specific instance), click Configure CA, enter the details and Save.

For a Microsoft CA you provide the CA Server URL (must begin with https:// and end with certsrv, e.g. https://ca.example.com/certsrv), the User Name (the least-privileged service account such as svc-vcf-ca, full username including domain), the Password, and the Template Name exactly as created (case-sensitive). For OpenSSL (instance components only) you instead supply the certificate subject fields: Common Name (the SDDC Manager FQDN), Country, Locality, Organization, Organizational Unit and State. Repeat for each scope and each VCF Instance.

Step 3: Generate the Certificate Signing Request

This is the heart of the workflow — the CSR captures the component’s identity and the cryptographic parameters of the certificate you want issued. In Fleet Management > Certificates, pick the scope, select the component (use the Show ESX Hosts toggle to reveal hosts), open the three-dot menu and click Generate CSR. Fill in the fields and Save.

• Common Name — the component’s FQDN.
• Organization / Organizational Unit — the legal registrant and the division the certificate belongs to.
• Country / State–Province / Locality — where your company is legally registered (state full, not abbreviated).
• Email Address — optional contact.
• Host — the host name.
• Subject Alternative Name — the SAN entry or entries. Get these right; modern clients validate the SAN, not the Common Name.
• Key Size — 2048-bit or 4096-bit. ESX hosts support 2048-bit only.

Wait until the CSR is generated successfully before continuing — the replace action only becomes available once the request exists. Generating CSRs for several components at once is fine; just let each complete.

Step 4: Get the certificate signed and install it

Option A — Integrated CA (Microsoft CA or OpenSSL)

Once the CSR has generated, open the component’s three-dot menu, select Replace With Configured CA Certificate, choose your CA and click Confirm. VCF submits the CSR to the configured CA, retrieves the signed certificate, and installs it on the component — no copy-pasting PEM files, no manual chain assembly. (OpenSSL is offered for instance components only.) This is the fully automated path: you defined the request, VCF handled signing and installation.

Option B — External / third-party CA

If you did not configure a CA in VCF Operations, you drive the signing yourself: download the generated CSR, submit it to your external CA and obtain the signed server certificate, collect the CA chain (root and any intermediates), then in VCF Operations import the signed server certificate together with the certificate authority files and use it to replace the existing certificate. This works with any CA, including public ones, but it is manual and it does not enroll the certificate in auto-renewal.

Step 5: Turn on automatic renewal (the payoff)

This is the feature that makes VCF 9 worth the upgrade for anyone who has been burned by an expired certificate. For components managed through VCF Operations you can toggle automatic renewal so certificates are reissued before they expire — non-disruptively, without a maintenance-window scramble. Certificates issued by an integrated Microsoft CA are eligible. Go to Fleet Management > Certificates, select the component(s) and enable automatic renewal; from then on VCF watches the expiration window and renews on your behalf. You can also manually renew TLS certificates at any time for components using VMCA, Microsoft CA, OpenSSL or self-signed certificates.

Common pitfalls and where they bite

Most failed certificate jobs trace back to a short list of causes. The map below pairs the symptom you see with the root cause to check first.

• Wrong scope. Management components are Microsoft-CA-only; OpenSSL is for instance components.
• Least privilege. Do not use a domain admin for the CA service account — scope a dedicated account to certificate management only.
• CA URL format. It must start with https:// and end with certsrv.

A recommended end-to-end sequence

1. Prepare the Microsoft CA: install the CA and Web Enrollment roles, enable Basic Authentication over HTTPS, create and publish a template, and create a least-privileged service account.
2. Verify connectivity and NTP time sync between VCF Operations / SDDC Manager and the CA.
3. Configure the CA for VCF Management.
4. Configure the CA for each VCF Instance.
5. Generate CSRs per component with correct SANs and key size (2048-bit for ESX).
6. Replace each certificate with the configured CA certificate.
7. Validate access to each component over HTTPS with no warnings.
8. Enable automatic renewal so the fleet stays current on its own.

Wrapping up

Certificate management in VCF 9 is a real improvement: one console for the whole fleet, an integrated path from CSR to installed certificate without manual file shuffling, and automatic renewal that removes the most common cause of certificate-related outages. The workflow is identical whether you are securing the management plane or a workload domain — prepare the CA, configure it in VCF Operations, generate the CSR, replace the certificate, enable auto-renewal. Do it once at deployment time, and certificates stop being the thing that wakes you at 2 a.m.

About The Author