architecture

Fleet operations without a fleet

VCF Operations certificate management now reaches standalone vCenter 8.0 Update 3 and above, and VCF 5.2, without converting those estates to VCF. What 9.1.1 added, the CA options, and the licensing line that decides whether you can use it.

Every large vSphere estate I have worked on has the same quiet liability sitting in it. Somebody, years ago, built a spreadsheet of certificate expiry dates. It was accurate on the day it was written. Since then two of the people who maintained it have left, a vCenter has been rebuilt, and nobody is completely sure whether the dates in column C are the certificate or the CA.

It holds until it does not. Then an STS certificate expires on a Saturday, authentication stops working across a platform that was otherwise perfectly healthy, and a Sunday gets spent on something that was knowable three months in advance.

There is a change in VCF 9.1 and 9.1.1 that addresses this, and the interesting part is not the feature. It is the scope. You no longer have to convert an estate to VCF to put its certificates under management.

What actually changed

VCF Operations has handled certificate lifecycle inside a VCF fleet for a while. In 9.1 that reach was extended to standalone vSphere 8.0 Update 3 and above, and to VCF 5.2. A standalone vCenter that is not part of any VCF instance is brought in through a workflow under the Integrations menu in VCF Operations.

Read that in terms of an estate rather than a feature list. The fourteen vCenters you have not converted, will not convert this year, and in two cases will never convert because the application sitting on them is going to be decommissioned, can still be managed from one place for the thing most likely to take them down.

Then 9.1.1 filled in the two gaps that mattered most. VCF Operations now manages the vCenter Security Token Service certificate and the VMware Certificate Authority root certificate. STS is the one that causes the Saturday. VMCA root is the one that nobody wants to touch because the blast radius of getting it wrong is the whole platform.

The addition I would actually act on

9.1.1 adds alerting for failed component-managed certificate renewals, with a knowledge base link attached to the alert. Automated renewal that fails silently is worse than no automation, because it replaces a known manual task with an assumption. An alert on renewal failure is the part that makes the automation safe to rely on.

It also lets you view, manage and filter components that are using non-TLS certificates, which is a small feature with a large use in an audit. "Show me everything in the estate not on TLS" is a question most teams currently answer by hand.

What it covers now

vCenter STS certificate

New in 9.1.1. The expiry that most commonly causes an authentication outage.

VMCA root certificate

New in 9.1.1. Managed rather than hand-rotated.

Root and TLS certificates

Across managed components.

NSX Edge

Covered.

Supervisor

Covered.

License Server

Covered. Worth noting given the 9.1 License Server is mandatory and has its own DNS requirements.

VCF Operations Unified Cloud Proxy

Covered.

VCF Operations for Networks collector

Covered.

AVI load balancer, HCX instances

Added in 9.1, and these two need 9.1 plus the relevant management pack and adapter rather than working out of the box.

The CA question, which is where designs usually stall

In my experience the certificate conversation in a bank does not stall on the platform. It stalls on the certificate authority, because the security team has a CA, a process attached to it, and no appetite for a second path to issuance.

The position in 9.1 is better than it was:

Microsoft CA

Supported across VCF instances and management components. In 9.0 the management components supported Microsoft CA only, so this is the gap closing rather than something new.

OpenSSL

Supported alongside Microsoft CA at both levels.

Third-party external CA

VCF Operations generates the CSR and imports the returned certificate. DigiCert, Google and Sectigo are named as examples. This is the path for an estate whose issuance is outsourced.

VMCA

Remains the default internal CA. A standalone vCenter can also replace VMCA with a subordinate CA, which is the arrangement most security teams actually want.

REST API

9.1 adds an API for third-party CA and certificate lifecycle integration, which is the one to point your automation team at rather than having them script against the UI.

The subordinate CA option is the one I would lead with in a design review. It keeps issuance inside the organisation’s existing trust chain, which is usually the actual requirement hiding behind "we need to use our CA".

The line that decides whether you can use any of this

Here is the part to be clear-eyed about, because it is where the idea either survives contact with procurement or does not.

Certificate and password management is a VCF capability. On Broadcom’s own feature comparison it sits in the VCF column, not the VVF one, along with centralised tag management, lifecycle management, real-time monitoring, predictive capacity management, SecOps and VCF Operations for Networks. VVF customers are pointed at vLCM for lifecycle. Fleet management is listed as a VCF component only.

Check this against your own entitlement before you design on it

That comparison document presents much of this as a table that does not extract cleanly, and I am reading availability off column positions. The direction is clear enough to plan around, but before anybody builds a design on it, have your account team confirm in writing that certificate management across standalone vCenters is covered by the SKUs you hold.

So "fleet operations without a fleet" is accurate about the vCenters and not about the licence. You still need a VCF Operations instance, and that instance needs to be entitled. What you do not need is to convert every vCenter in the estate into a VCF instance before the capability reaches it. For a large brownfield environment that distinction is the whole argument, because converting fourteen vCenters is a programme and integrating fourteen vCenters is a change.

How I would actually use it

If I were holding a mixed estate right now, this is the sequence I would run.

Start with the vCenters you are least likely to convert, not the ones you are most likely to convert. The ones heading for VCF will pick this up anyway. The ones that are staying standalone for another three years are where the spreadsheet risk actually lives, and they are the ones this was extended to reach.

Get the inventory before the automation. Integrate, let it discover what is there, and look at what comes back. On every estate I have done this kind of exercise on, the discovered list and the maintained list have disagreed, and the disagreement has been the most useful output of the week.

Then turn on renewal alerting before you turn on anything that renews. In that order. An alert that fires on a manual process is useful on day one. Automation whose failure mode is silence is not something to introduce to a regulated platform on a Friday.

And agree the CA path with the security team before you integrate rather than after. If the answer is going to be a subordinate CA under the corporate root, that is a conversation with a lead time measured in weeks, and it is better had while the platform work is still a plan.