Integrating
Microsoft Certificate Authority with VMware Cloud Foundation 9.x

Certificate management in VCF has come a long way. If you wired up
Microsoft CA against VCF 5.2 (or earlier), you’ll find most of the
Windows-side prep is identical, but the consumer of that CA has moved.
In VCF 9.x, you no longer configure the CA from SDDC Manager directly —
certificate authority configuration now lives in VCF Operations → Fleet
Management → Certificates, and it splits into two distinct scopes: VCF
Management components and VCF Instances.

This walkthrough rebuilds the original 5.2 procedure against the 9.x
topology, calls out a few gotchas I’ve hit in the lab, and lands you
with a working auto-renewing Microsoft CA integration.

What’s actually different
in VCF 9.x

A quick mental model before we start clicking:

• CA configuration lives in VCF Operations, not SDDC Manager. The
  Fleet Management appliance is the new control plane for
  management-component certificates.
• Two CA scopes, configured separately:
  • VCF Management — Fleet Management, VCF Operations, VCF Automation,
    VCF Operations for Logs, etc. Microsoft CA only.
  • VCF Instances — SDDC Manager, vCenter, NSX Managers, ESXi hosts
    (per-instance). Microsoft CA or OpenSSL.
• Auto-renewal is now a first-class feature for both Microsoft CA and
  OpenSSL flows. Certificates renew before expiry without a midnight pager
  event.
• OpenSSL fallback — SDDC Manager still ships an embedded OpenSSL CA
  for instance-level components if you don’t want to wire up Microsoft CA
  at all.
• Avi (NSX ALB) certificates are not (yet, as of 9.0.1) managed
  through this interface — handle those out of band.

Everything below targets the Microsoft CA path, which is the only
supported option if you want CA-signed certs on management
components.

Prerequisites

This guide assumes you have an existing Microsoft Enterprise Root CA
running on Windows Server (2019 / 2022 / 2025) with AD DS, DNS, and NTP
in place. If you don’t, build the CA first and come back.

Before you start the VCF-side configuration:

• DNS A records for your CA’s web enrollment FQDN (I use
  certs.virtualbytes.io).
• Time sync between the Microsoft CA, Fleet Management, SDDC Manager,
  and the rest of the fleet — same NTP source is strongly
  recommended.
• Network reachability from Fleet Management and each SDDC Manager to
  the CA on 443. Note that in 9.x both the Fleet Management appliance and
  each SDDC Manager talk to the CA depending on the scope you’re
  configuring, so don’t punch a one-way firewall hole.
• A least-privilege service account in AD (mine is
  [email protected]).

Step 1 — Install the
Microsoft CA roles

RDP into the CA server and add these roles via Server Manager:

• Certification Authority
• Certification Authority Web Enrollment
• Certificate Enrollment Policy Web Service
• Certificate Enrollment Web Service

Reboot after the install completes. The Web Enrollment role is what
exposes /certsrv, which is the endpoint VCF Operations and
SDDC Manager will hit.

Step 2 — Enable Basic
Authentication on IIS

The Web Enrollment site uses Windows Auth by default. VCF needs Basic
Auth.

In Server Manager, open the IIS feature page and add the Basic
Authentication role service under Web Server (IIS) → Web Server →
Security if it isn’t already installed.

Then in IIS Manager:

1. Expand Sites → Default Web Site → CertSrv.
2. Open Authentication.
3. Right-click Basic Authentication → Enable.
4. Select Default Web Site in the navigation pane.
5. In the Actions pane under Manage Website, click Restart.

Step 3 — Bind a
trusted server certificate to IIS

VCF requires the connection to /certsrv to be HTTPS with
a certificate that the VCF appliances trust. Self-signed will not
fly.

Issue a Web Server certificate to the CA server itself with:

• Subject CN: the FQDN you’ll point VCF at
  (e.g. certs.virtualbytes.io)
• SANs: the FQDN and the CA server’s IP

In IIS Manager: right-click Default Web Site → Edit Bindings → https
(443) → Edit and attach the certificate. Confirm
https://certs.virtualbytes.io/certsrv loads in a browser
and prompts for Basic Auth without a TLS warning.

If you’re standing up a fresh CA, you’ll need to first issue this Web
Server certificate from the CA to itself, then bind it. Common
chicken-and-egg trap.

Step 4 — Create the
VCF certificate template

VCF needs a custom template — the stock Web Server template won’t
work because it includes Server Authentication only and doesn’t allow
nonrepudiation.

Open certtmpl.msc:

1. Right-click Web Server → Duplicate Template.
2. Compatibility tab:
   • Certification Authority: Windows Server 2008 R2 (or higher, matched
     to your CA)
   • Certificate recipient: Windows 7 / Server 2008 R2 (or higher)
3. General tab:
   • Template display name: VMware (VCF 9 docs use
     VMware as the example — pick a name and remember it, you’ll
     type it into VCF Operations)
   • Validity period: 2 years
4. Extensions tab:
   • Application Policies → Edit → remove Server Authentication, click
     OK.
   • Basic Constraints → Edit → tick Enable this extension, click
     OK.
   • Key Usage → Edit → tick Signature is proof of origin
     (nonrepudiation), leave the rest at defaults, click OK.
5. Security tab — add your service account
   ([email protected]) with:

The 5.2 guide had Read deselected. In 9.x, give the service account
Read. Without it the template enumeration call from Fleet Management
fails silently and you’ll spend an afternoon staring at “Certificate
authorities update failed.”

Step 5 — Publish the template

Open certsrv.msc:

1. Right-click Certificate Templates → New → Certificate Template to
   Issue.
2. Select your template (VMware) and click OK.

The template is now live and issuable.

Step 6 — Configure
the CA in VCF Operations

Here’s where 9.x diverges hard from 5.2. Do not go to SDDC Manager.
Log in to VCF Operations as a user with the Administrator role:

https://<vcf-operations-fqdn>/

Navigate to Fleet Management → Certificates.

You’ll see two tabs:

• VCF Management — applies to Fleet Management, VCF Operations, VCF
  Automation, and VCF Operations for Logs.
• VCF Instances — applies per-instance to SDDC Manager, vCenter, NSX
  Managers, ESXi.

Pick the scope you’re configuring (you’ll repeat this for each scope
you care about), then click Configure CA.

Enter:

Click Save.

Critical gotcha: the username must be in UPN format
([email protected]). If you enter it as
DOMAIN\username the save call fails with
Certificate authorities update failed and a
JSON parse error: Unrecognized character escape 's' in the
response — the backslash blows up JSON serialization. This is documented
in Broadcom KB 416470 and it bites everyone who’s used to NETBIOS-style
logins.

Repeat for the other scope (VCF Management vs VCF Instances) and for
each additional VCF Instance you operate.

Step 7 — Replace certificates

Once the CA is configured, head into the Certificates view for the
scope you want to update. Each row is a component with a TLS
Certificate.

For any TLS Certificate row (skip Root Certificate rows — those will
pick up the new Microsoft Root automatically when components
rotate):

1. Click the ⋯ menu → Generate CSR.
2. Fill out the CSR details (Common Name, Org, OU, Country, State,
   Locality, SANs) and save.
3. Click ⋯ again → Replace with Configured CA Certificate →
   Confirm.

The replace operation takes a few minutes per component. Run them
sequentially. The UI lets you fire multiple at once but in practice that
fails ugly — wait for each to complete.

The component-level replacement finishes a bit before the VCF
Operations UI catches up, so give the UI an extra couple of minutes
after the job reports complete before you assume something’s wrong.

Step 8 — Turn on auto-renewal

This is the part that didn’t exist in 5.2 and is genuinely the best
operational reason to wire up Microsoft CA.

In Fleet Management → Certificates, toggle auto-renewal on for the
components you want maintained automatically. Auto-renew kicks in before
expiry and uses the configured CA to issue and install the replacement
without operator action.

You can leave auto-renew off and manage manually if your change
control requires it — but for anything internal-facing where downtime
from an expired cert is a non-starter, turn it on.

Troubleshooting cheat sheet

A few things I’ve hit:

• Certificate authorities update failed on save — almost
  always the username format. Switch from DOMAIN\user to
  [email protected]. (KB 416470.)
• Save works from SDDC Manager UI but fails from VCF Operations — same
  root cause as above; the SDDC Manager-side input validation is more
  forgiving than the Fleet Management API.
• CSR generation works, certificate install fails — check that the
  service account has Read and Enroll on the template. The
  5.2-era docs had Read deselected, which now breaks 9.x.
• TLS warnings from VCF to the CA — the IIS binding cert isn’t trusted
  by the appliance. Make sure the issuing CA’s root is in the trust store;
  if you’ve rebuilt the CA recently you may need to push the root into the
  appliances.
• Time skew errors — Kerberos and certificate operations both hate
  clock drift. Same NTP source across CA, Fleet Management, and SDDC
  Manager.

Closing notes

The Windows side of this hasn’t really changed since 5.2 — same
roles, same IIS basic auth, same template tweaks. What’s new is
where you configure the consumer (VCF Operations / Fleet
Management), the split between management and instance scopes, and
auto-renewal. If you’ve done this before, the muscle memory mostly
carries; if this is your first CA integration, the 9.x flow is actually
cleaner once you know which tab you’re supposed to be on.

Next post in this series I’ll walk through pairing this with a deploy
hook so the Microsoft Root CA gets pushed into the appliance trust
stores during VCF lifecycle operations.