The short answer
You replace a vCenter certificate by running /usr/lib/vmware-vmca/bin/certificate-manager on the appliance, or from the vSphere Client under Administration → Certificate Management. Option 1 handles the Machine SSL certificate, which is the only one most environments should replace — solution user and ESXi host certificates stay signed by VMCA. Two requirements decide whether a public certificate is possible at all: the SubjectAltName must carry the appliance’s FQDN and that name must match its PNID, and vSphere does not support wildcards. As of August 2026 a public certificate lasts at most 200 days, and vSphere has no built-in ACME client, so budget for doing this by hand roughly twice a year.
Broadcom’s documentation is thorough about the mechanics and silent about the thing that stops most of these projects before they start. It has to be: the vendor cannot know where your certificate comes from, so it describes a procedure that assumes you already have one in your hand. That assumption is doing a lot of work, and the sections below start with the question the vendor cannot ask you.
Can a public CA issue a certificate for your vCenter?
Only if the appliance’s fully qualified domain name sits in a domain you own and can prove control of in public DNS. A publicly trusted certificate authority cannot issue for vcenter.corp.local, vcenter.lan, or a bare hostname, and this is not a policy any individual CA can waive. The CA/Browser Forum barred certificates containing internal server names and reserved IP addresses from 1 November 2015, and required CAs to revoke any still-unexpired ones by 1 October 2016.
That rule collides with how vCenter appliances are typically named. A great many were deployed on an internal-only domain because nothing about vCenter needs to be reachable from the internet, which is good security practice and also an absolute bar on getting a publicly trusted certificate for that name. It is worth being precise about what “public” requires here: the name must exist in public DNS well enough for the CA to validate it, but the appliance itself never has to be reachable from outside. You can hold a public certificate for vcenter.example.com while the only A record that resolves it lives on your internal resolver, provided you can complete domain control validation for example.com by DNS.
If the appliance is on an internal name and renaming it is not on the table, stop here and use VMCA or your own internal CA. That is not a consolation prize. VMCA already issues every certificate in the environment and vCenter already trusts it; the only thing a public certificate adds is that browsers and API clients trust it without you distributing a root. Where nobody outside your team ever opens the vSphere Client, that is a small benefit for a recurring cost.
Which of the four vCenter certificates you replace
Replace the Machine SSL certificate and nothing else. vSphere keeps four distinct certificate types, and only the Machine SSL certificate is presented to browsers and API clients connecting to vCenter. Solution user certificates authenticate vSphere components to each other, ESXi host certificates serve the host management interfaces, and the VMCA root signs all of them. VMware documents replacing only the Machine SSL certificate as the option most environments should choose, a configuration commonly called hybrid mode.
The reasoning is worth spelling out, because “replace your vCenter certificates” is such common phrasing that people assume it means all of them. Solution user certificates are never seen by a human or a browser. Putting publicly trusted certificates on them buys nothing, costs money per certificate, and multiplies the renewal work by the number of components. ESXi host certificates are the same argument at greater scale: on a cluster of thirty hosts, that is thirty more certificates to buy and thirty more to replace on the schedule described further down.
The fourth row deserves its own warning. Replacing the VMCA root with a signing certificate from your corporate CA — making VMCA a subordinate CA — is genuinely appealing, because afterwards everything in the environment chains to a root your machines already trust. VMware’s own guidance on that mode is unusually direct about the trade: it warns of significant complexity, potential negative impact to security, and an unnecessary increase in operational risk. You are taking on the operation of a subordinate CA inside an appliance not built to be one.
What you need before you start
You need four things: the appliance’s PNID confirmed, root SSH or console access to the appliance, a snapshot or backup taken, and a maintenance window. The PNID is the one people skip. VMware warns that if the host name does not match the FQDN, certificate replacement does not complete correctly and can leave the environment in an unstable state, so confirm it rather than assuming it.
| Requirement | What vSphere expects |
|---|---|
| Key algorithm and size | RSA, at least 2048 bits and at most 8192 bits |
| Encoding | PEM, with the key in PKCS#1 or PKCS#8 format |
| SubjectAltName | Must contain a DNS entry for the appliance FQDN |
| Hostname | The PNID must match that FQDN exactly |
| Wildcards | Not supported |
On the certificate itself, an OV certificate is the usual choice for infrastructure like this: the organisation behind the name is validated, which is the part that matters when the certificate identifies a management plane rather than a shop front. If you are covering vCenter alongside other appliance hostnames, a multi-domain certificate listing each of them is more economical than one certificate each — and, given the wildcard restriction, it is the only way to cover several names at once. Both are on our SSL certificates page.
Take the snapshot. The certificate manager can roll its own work back, but that only covers the certificate store, and a vCenter that will not start after a botched replacement is a much longer evening than a snapshot that took ninety seconds.
How to generate the CSR on vCenter Server
Run /usr/lib/vmware-vmca/bin/certificate-manager as root on the appliance, choose Option 1 — Replace Machine SSL certificate with Custom Certificate, then at the next prompt choose Option 1 — Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate. The utility asks for a directory to write the files into and for the subject details, then produces a CSR and a matching private key. Leave the session there — you come back to the same menu to import.
Answer the subject prompts with the appliance’s FQDN as the common name, and give the organisation details exactly as they appear on the company registration you will be validated against. The utility writes both files where you told it to; copy the CSR off the appliance and leave the key exactly where it is. If you would rather not use the shell, the vSphere Client offers the same thing under Administration → Certificate Management, where the Machine SSL row has a Generate Certificate Signing Request action.
Submit the CSR to your CA and complete validation. For an OV certificate that means the CA verifies both control of the domain and the existence of the organisation, so the paperwork side runs on its own clock rather than yours. If the CSR itself is unfamiliar territory, our explainer on what a CSR contains and why covers the fields you just filled in.
How to import the signed certificate
Return to certificate-manager, choose Option 1 again, and this time take the option to continue importing custom certificates and keys for the Machine SSL certificate. It asks for three full paths: the issued certificate, the private key generated alongside the CSR, and the CA chain file. The utility then replaces the certificate and restarts the vCenter services, which is where the outage in your maintenance window happens.
The chain file is where imports usually fail. It must contain the intermediate certificates and the root, concatenated as PEM blocks in one file, and if your CA issued through more than one intermediate then every one of them belongs in there. Certificate authorities do not agree on what to call this file — bundle, chain, CA certificate, sometimes an issuer certificate delivered separately from the rest — so check what you actually received rather than what the filename suggests. Our guide to building a complete certificate chain covers the ordering and how to tell when one is short a link.
If the files you received are in the wrong shape entirely — a PFX when you need separate PEM blocks, say — converting them is straightforward but easy to get subtly wrong, and the certificate file formats explainer has the OpenSSL commands. When the services come back, load the vSphere Client in a browser that has never seen the old certificate and confirm the padlock, rather than trusting a cached tab.
Why a wildcard certificate will not work
vSphere does not support wildcard certificates, stated plainly in VMware’s certificate requirements. A *.example.com certificate you already own for the web estate cannot be reused on vCenter, no matter that it would technically match the hostname. The Machine SSL certificate has to name the appliance specifically, with the FQDN present as a DNS entry in the SubjectAltName extension.
This catches people who bought a wildcard precisely so they would not have to think about individual hostnames again, and it is the single most common reason a vCenter certificate arrives unusable. If you are covering several infrastructure names, the answer is a multi-domain certificate that lists each hostname explicitly. It costs more than a wildcard and it is the shape vSphere will actually accept.
How often you will have to redo this
About twice a year today, and more often from 2027. As of August 2026 a publicly trusted TLS certificate can be issued for at most 200 days, following CA/Browser Forum ballot SC-081v3, which took effect on 15 March 2026. The maximum drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. vSphere 8 ships no ACME client, so each renewal is the procedure above, run by hand, with the service restart it entails.
It is worth sitting with that for a moment before committing, because the honest conclusion cuts against buying anything. For a vCenter that only your own team ever opens, VMCA issues certificates with a much longer life, renews them from the vSphere Client, and asks nothing of the CA/Browser Forum’s schedule. Distributing the VMCA root once to the machines that need it is a one-off; a public certificate on a 47-day clock is not.
The case for a public certificate is strongest where vCenter is genuinely reached by people or systems you do not administer: auditors, a managed service provider, contractors on unmanaged laptops, or tooling with its own trust store you cannot easily add a root to. There the recurring window buys something real. Administrators who want both tend to script the renewal against a third-party ACME client and the vCenter REST API, which works and is entirely self-managed, so test a full cycle in a lab before letting it touch production. Our guide to preparing for shorter certificate lifetimes works through the same maths for everything else you run.
When it goes wrong, and how to get back
Re-run certificate-manager and choose the option to revert the last performed operation, which restores the certificates that were in place beforehand. That covers the common failures: an import rejected for a malformed chain, services that do not come back cleanly, or a certificate whose SubjectAltName turns out not to match the PNID after all. Rollback is a first move, not a last resort.
Three failures account for most of what goes wrong. A certificate whose SubjectAltName lacks a DNS entry for the appliance FQDN is rejected, or worse, accepted and then distrusted by every client that checks. A chain file missing an intermediate produces a certificate that validates in one browser and fails in another, because some clients fetch the missing link and others do not — the classic broken-chain symptom, and the reason to test from more than one machine. And a mismatch between the hostname and the FQDN produces the unstable state VMware warns about, which is exactly why the PNID check belongs before the CSR rather than after the import.
Verify from outside the appliance rather than from the vSphere Client, which is a poor witness to its own certificate. Running openssl s_client -connect vcenter.example.com:443 -showcerts from another machine returns the full chain the appliance is actually presenting: count the certificates that come back, and if there is only one, the chain file never made it in.
Getting the certificate for vCenter
If your appliance is on a name you own publicly, an OV certificate naming the FQDN is what vSphere expects, and a multi-domain certificate is the way to cover vCenter alongside your other appliance hostnames given that wildcards are out. Every certificate we sell is issued by Certum, a publicly trusted CA whose roots already ship in the major browser and operating system trust stores, so nothing has to be distributed to the machines your administrators use. Compare the options on our SSL certificates page.
Related reading
- Multi-domain SSL certificates — the shape to buy when a wildcard is off the table and you have several appliances to cover.
- SSL certificate chain explained — how to assemble the chain file the import step asks for, and how to spot a missing link.
- Preparing for shorter certificate lifetimes — what the 2027 and 2029 steps do to anything renewed by hand.