Certificates in vSphere are easy to underestimate until they become the reason vCenter will not authenticate, services will not start cleanly, NSX loses trust in its Compute Manager, or SDDC Manager stops interacting with the management domain the way it should. That is why a VMCA reset should not be treated as a generic “renew the certs” task. It is a trust-anchor decision. Broadcom KB 318767 documents how to regenerate vSphere 6.x, 7.x, and 8.0 certificates using a new self-signed VMCA certificate. The same KB now points administrators toward vCert as the improved certificate workflow tool, while still documenting the certificate-manager path for regenerating certificates with self-signed VMCA. Broadcom’s vCert article lists vCenter 7.0 through 9.0 support, so vSphere 6.x environments should be handled carefully against the specific KB workflow and support guidance before production execution. This article is not just a command walkthrough. It is a decision model for knowing when full regeneration is the right move, when it is overkill, and what blast radius you need to plan for in a vSphere or VMware Cloud Foundation environment.
TL;DR
A VMCA reset is appropriate when the root of trust is the problem, not when a single endpoint certificate is inconvenient. Use renewal when the certificate identity and trust chain are still correct but expiration is approaching. Use replacement when a specific certificate needs to change, such as replacing the vCenter Machine SSL certificate with a custom CA-signed certificate. Use full regeneration when the VMCA root is expired or near expiration, multiple VMCA-issued certificates are expired, the trust chain is broken broadly, or you need to recover a vCenter environment back to the default self-signed VMCA model. Before any full reset, check STS. An expired STS signing certificate can prevent vCenter services from starting and can produce authentication and “No Healthy Upstream” style failures. In VCF, the blast radius extends beyond vCenter. SDDC Manager, NSX Compute Manager, backup platforms, monitoring systems, Aria integrations, automation scripts, and anything that pinned or imported the old chain may need to re-trust the new VMCA root or Machine SSL chain after regeneration.
Source Validation Note
Broadcom KB 318767 is the anchor source for regenerating vSphere 6.x, 7.x, and 8.0 certificates using self-signed VMCA. It states that Broadcom recommends vCert for certificate workflows and also documents the certificate-manager procedure, including Option 4 and Option 8 paths. Broadcom KB 385107 positions vCert as a menu-driven certificate management tool for vCenter 7.0 through 9.0 and warns that certificate operations can render the system inoperable if performed incorrectly. That same guidance calls for VAMI backups or offline snapshots of all vCenter and PSC nodes in the SSO domain before making changes. For production publishing, keep this nuance visible: KB 318767 includes the vSphere 6.x regeneration workflow, but vCert’s current support article lists vCenter 7.0 to 9.0. Validate the vSphere 6.x execution path before touching a legacy production system.
Why This Decision Matters
There are two common mistakes with vSphere certificate work. The first is treating every certificate warning as a full platform emergency. A browser warning against the vCenter UI does not automatically mean the VMCA root should be replaced. In many cases, replacing the Machine SSL certificate is cleaner and has a smaller blast radius. The second mistake is treating a broken root of trust as a leaf-certificate problem. If the VMCA root is near expiration, repeatedly regenerating Machine SSL and Solution User certificates can still leave you with certificates that inherit the same limited expiration window because subordinate certificates cannot outlive the signing CA. Broadcom documents this issue when reset or regeneration workflows produce new certificates with the same expiration because the VMCA root itself is near expiry. That is the heart of the VMCA reset decision. Do not reset VMCA because one thing looks messy. Reset VMCA when the trust anchor itself is no longer trustworthy, valid, or operationally recoverable.
VMCA as a Trust Factory, Not Just a Certificate Store
The VMware Certificate Authority, or VMCA, is the built-in certificate authority used by vCenter to automate certificate management inside the vSphere environment. In the default model, VMCA acts as a self-signed CA that issues certificates for vCenter services and ESXi hosts. VMware has described VMCA as a “just-enough-CA” inside vCenter rather than a general-purpose enterprise CA. That distinction matters. VMCA is not only about the certificate shown in your browser when you connect to https://vcenter-fqdn/ui. It supports a set of identities and trust relationships that make the management plane work.
Broadcom’s certificate-manager documentation describes default VMCA-generated certificates as stored in VECS and notes that these certificates are not trusted outside vSphere by default. External trust usually requires importing the VMCA root into the systems that need to trust vCenter.
The Trust Chain at a Glance
The diagram below shows the important mental model: a VMCA reset changes the trust anchor and then issues new downstream certificates. Anything outside vCenter that trusted the old chain may need to be updated.
The most important thing to notice is that the root sits above the operational identities. When the VMCA root changes, you are not just refreshing a certificate. You are changing what downstream systems must trust. The STS certificate is called out separately because it has its own failure mode. An expired STS signing certificate can prevent authentication and service startup, so it should be checked before attempting a broad VMCA regeneration.
Scope and Terminology Guardrails
This article is focused on vSphere and VCF environments using self-signed VMCA as the certificate authority model.
In scope: vCenter Server Appliance and legacy vCenter 6.x certificate-manager workflows, vSphere 6.x, 7.x, and 8.0 self-signed VMCA regeneration as described by KB 318767, vCert considerations for supported versions, Machine SSL, Solution User, VMCA root, STS, VECS, and ESXi trust considerations, and VCF-adjacent blast radius, especially SDDC Manager and NSX Compute Manager trust. Out of scope: designing a full enterprise PKI hierarchy, replacing every VCF component certificate with third-party CA certificates, converting VMCA into an enterprise subordinate CA as a blanket recommendation, and remediating every possible third-party integration after a certificate reset.
Renewal, Replacement, and Full Regeneration Are Not the Same Operation
This is where many certificate incidents go sideways. Teams use “renew,” “replace,” and “reset” interchangeably, but operationally they are different actions.
Broadcom’s certificate-manager options reflect this distinction. Option 3 can replace the Machine SSL certificate with a VMCA-generated certificate, while Option 4 regenerates a new VMCA root and replaces all certificates. Option 8 resets all certificates and is called out for situations where both Machine SSL and Solution User certificates are expired. KB 318767 adds an important caution: Option 8 performs similar functionality to Option 4 but does not provide automatic rollback. That matters during recovery planning.
When Full VMCA Regeneration Is the Right Move
A full VMCA regeneration is appropriate when the root of trust is the problem or when the certificate state is too broadly broken to fix cleanly one certificate at a time. Good candidates include a VMCA root that is expired or near expiration, multiple VMCA-issued certificates that are expired, a need to return the environment to default VMCA trust, recovery from broad vCenter access or internal service trust issues, or a lab and non-production environment where self-signed VMCA is operationally acceptable. If the VMCA root is near expiry, regenerated subordinate certificates may retain the same limited expiration date because they cannot exceed the validity of the signing CA. Broadcom documents this behavior and recommends renewing the VMCA root before regenerating Machine SSL and Solution User certificates in that scenario. If Machine SSL and Solution User certificates are both expired, KB 318767 points to the reset path where Option 8 is needed, with the no-automatic-rollback caveat. Some environments inherit messy custom certificate attempts, broken chains, missing intermediates, or inconsistent trust stores. If the target state is self-signed VMCA, a reset may be cleaner than continuing to patch symptoms.
When VMCA Regeneration Is the Wrong Move
A full reset is disruptive when the problem is narrow. Do not jump to VMCA regeneration when only the browser warning is the issue and the VMCA root is healthy, only the Machine SSL certificate needs to be replaced with a custom CA-signed certificate, the problem is an expired STS certificate and vCenter authentication is failing, NSX or SDDC Manager lost trust after a recent vCenter certificate change, compliance requires enterprise CA-signed certificates for the vCenter endpoint, or backup and monitoring tools simply need their trust store updated. For many customers, VMware’s own certificate guidance favors a hybrid mode: use a trusted custom certificate for human-facing endpoints such as Machine SSL, while allowing VMCA to manage internal service certificates. VMware also cautions against making VMCA a subordinate CA in many environments because it extends enterprise CA trust to anyone with access to the VMCA root key material. That hybrid model often gives the best operational balance: clean browser/API trust without turning every internal vSphere certificate into a manual PKI project.
Service Restart Impact and Blast Radius
Regenerating certificates is a management-plane event. KB 318767 states that the certificate-manager regeneration process automatically restarts vCenter services. It also warns administrators to confirm the operation before proceeding. vCert also includes service restart capabilities, including restarting all VMware services or specific services. The practical impact is that vCenter UI, API, SSO, and dependent integrations can become unavailable during the operation. Do not schedule this during another platform change, upgrade, workload migration, backup reconfiguration, or NSX maintenance window.
This is why certificate regeneration should be coordinated as a platform operation, not a quick shell task.
Runbook Stage 0: Decide the Correct Action
Before logging in to the appliance shell, decide what you are actually trying to accomplish.
For production, document the target certificate model, maintenance window, snapshot and backup owner, validation owner, rollback decision point, connected systems that need re-trust, and whether the vCenter is standalone or part of Enhanced Linked Mode or a shared SSO domain.
Runbook Stage 1: Preserve and Inventory the Current State
Do not start with the reset. Start with evidence. For vCert-supported versions, use vCert to generate a certificate report and check current certificate status. Broadcom documents vCert menu options for checking certificate status, viewing certificate information, managing certificates, resetting all certificates with VMCA-signed certificates, restarting services, and generating certificate reports. Also confirm the PNID before generating new certificate identities:
/usr/lib/vmware-vmafd/bin/vmafd-cli get-pnid –server-name localhost
KB 318767 specifically calls out the need for certificate values such as Name, Hostname, and VMCA Name to align with the PNID/FQDN and warns against problematic localhost values in certificate generation. Use VECS to inventory expiration dates:
for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do
echo “[*] Store: $store”
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store “$store” –text | grep -ie “Alias” -ie “Not After”
done
This gives you a quick view of certificate stores and expiration values before the change. It also helps prove whether the issue is one certificate, several leaf certificates, or the VMCA root itself. Before proceeding, create proper backups and snapshots. Broadcom’s vCert article warns that certificate changes can render systems inoperable and calls for VAMI-based backups or offline snapshots of all vCenter and PSC nodes in the SSO domain.
Runbook Stage 2: Check STS Before VMCA
STS deserves its own checkpoint. Broadcom recommends replacing the STS certificate if it expires within six months. The legacy checksts.py script has been deprecated, and Broadcom now directs administrators to vCert or the vSphere Client certificate management interface for supported versions. An expired STS certificate can prevent vmware-stsd from starting, cause vCenter services to fail, and produce login errors such as “Cannot connect to vCenter Single Sign-On,” “Signing certificate is not valid,” “503 Service Unavailable,” or “No Healthy Upstream.” For vCenter 7.0 U2 and later, the vSphere Client includes STS certificate visibility and replacement workflows. Broadcom’s STS replacement guidance also warns that forcing a refresh can require rebooting VCSA systems and can replace custom STS certificates with vCenter-issued certificates, which may violate compliance requirements in environments that intentionally use custom certificates. The operational rule is simple: if STS is expired or close to expiration, handle STS deliberately before treating VMCA regeneration as the fix.
Runbook Stage 3: Choose the Execution Path
There are two practical tooling paths to understand. For vCenter 7.0 through 9.0, Broadcom documents vCert as a menu-driven tool for common certificate operations. vCert includes options to manage Machine SSL, Solution User certificates, CA certificates in VMware Directory and VECS, STS signing certificates, VMCA certificates, SSL trust anchors, and more. For a full reset with VMCA-signed certificates, vCert includes a reset-all workflow. Broadcom KB 318767 also recommends vCert Option 6 for resetting all certificates with VMCA-signed certificates. For a VMCA root nearing expiration, Broadcom’s reset-expiration guidance is more precise: renew the VMCA root first, then regenerate Machine SSL and Solution User certificates, update STS, restart services, verify expiration, refresh ESXi host certificates, and re-authenticate third-party systems connected to vCenter. For the KB 318767 workflow, launch certificate-manager on the vCenter Server Appliance:
/usr/lib/vmware-vmca/bin/certificate-manager
For legacy Windows vCenter 6.x:
C:Program FilesVMwarevCenter Servervmcadcertificate-manager
The two options that matter most for this article are:
KB 318767 states that Option 8 performs the same functionality as Option 4 but does not support automatic rollback. That no-rollback detail is exactly why this decision belongs in a runbook, not in an ad hoc SSH session.
Runbook Stage 4: Use Correct Identity Values
Certificate regeneration is not just about dates. Identity matters. When prompted for certificate values, use the actual vCenter identity. The hostname, certificate name, VMCA name, and SAN values should align with how vCenter is accessed and how its PNID is configured. KB 318767 explicitly recommends using the PNID-derived FQDN and avoiding localhost values that can cause certificate mismatch problems. A practical rule: use the vCenter FQDN as the primary identity, include IP SANs only when there is a real operational requirement to access vCenter by IP, do not use localhost, and do not “clean up” names during a certificate reset unless you are deliberately executing a supported rename or reconfiguration workflow. Bad identity values can leave you with fresh certificates that still fail trust validation.
Runbook Stage 5: Execute and Let Services Restart Cleanly
Once the backup, snapshot, STS check, PNID validation, and decision point are complete, execute the chosen workflow. During execution, do not interrupt certificate-manager or vCert, allow vCenter services to restart, keep another admin from starting parallel maintenance, capture logs and screen output, and track the exact option selected and values entered. KB 318767 notes that the certificate-manager process automatically restarts vCenter services. When a manual service restart is required by the workflow or by support guidance, the standard VCSA service control pattern is:
service-control –stop –all
service-control –start –all
Broadcom’s VMCA-root-expiration remediation also includes restarting all vCenter services after certificate operations.
Runbook Stage 6: Validate vCenter Before Fixing Integrations
Do not jump straight into SDDC Manager, NSX, or backup tools. First prove that vCenter is healthy. Validate vSphere Client login, SSO authentication, vCenter service health, inventory visibility, API access, Machine SSL certificate chain, VECS expiration dates, STS certificate state, and the absence of new certificate alarms. Use the VECS inventory command again:
for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do
echo “[*] Store: $store”
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store “$store” –text | grep -ie “Alias” -ie “Not After”
done
Validate the vCenter endpoint certificate chain from a trusted admin workstation or appliance shell:
openssl s_client -showcerts -connect <vcenter-fqdn>:443 </dev/null
For NSX-related trust problems, Broadcom’s NSX Compute Manager troubleshooting guidance uses openssl s_client -showcerts -debug -connect <VC-IP>:443 to inspect the presented chain and confirms that a valid chain should follow the Server/Leaf → Intermediate → Root pattern.
Runbook Stage 7: Re-Establish Downstream Trust
Once vCenter itself is healthy, move outward. In VMware Cloud Foundation, SDDC Manager can retain trust in the old vCenter root certificate. Broadcom documents cases where SDDC Manager cannot see utilization, commission hosts, add hosts, or log in when the vCenter root certificate is not published to SDDC Manager trust stores. The cause can be an out-of-band vCenter root certificate change where SDDC Manager still references the old root. Broadcom specifically notes that this can occur when Option 8 is run in certificate-manager. The documented remediation includes taking a snapshot of SDDC Manager and using VcRootCaSync.py or manually importing the new root into SDDC Manager trust stores. The root certificate can be exported from vCenter with:
/usr/lib/vmware-vmca/bin/certool –getrootca –cert=/tmp/root.cer
Broadcom’s manual process then uses the SDDC Manager trusted certificates key and Java keytool trust store imports, followed by a trusted-certificates refresh API call. That manual path should be followed directly from the current KB or support guidance because it touches SDDC Manager trust stores. NSX may show the vCenter Compute Manager connection as down after a certificate change if the vCenter Machine SSL chain is invalid, incomplete, or no longer trusted. Broadcom documents invalid chain and missing trusted root conditions as causes of Compute Manager trust failures. The operational remediation is usually not “reset VMCA again.” Validate the chain, correct the trust relationship, edit and save the Compute Manager entry, and confirm the connection returns to Up. Any system that connects to vCenter over HTTPS may need to accept the new certificate or import the new root. This includes backup platforms, monitoring systems, VMware Aria integrations, PowerCLI or Python automation hosts, CI/CD runners, CMDB and inventory tools, security scanners, and custom scripts that pin certificate fingerprints. If the old root or thumbprint was pinned, those integrations will not trust the new chain until updated. Broadcom’s VMCA-root-expiration remediation includes refreshing ESXi host certificates and re-authenticating third-party systems connected to vCenter after the VMCA root and downstream certificates are corrected.
Troubleshooting Patterns After Regeneration
If new certificates still show the old expiration window, the issue usually points back to the VMCA root. If the VMCA root is near expiration, regenerated subordinate certificates may inherit the root’s remaining validity window. Broadcom documents this behavior and recommends renewing the VMCA root before regenerating Machine SSL and Solution User certificates. If vCenter shows “No Healthy Upstream” or SSO login fails, do not assume this is a Machine SSL issue. Check STS. Broadcom documents expired STS symptoms including service startup failures, SSO connection failures, signing certificate validity errors, 503 errors, and “No Healthy Upstream.” If SDDC Manager cannot interact with vCenter after the reset, it may still trust the old root. Broadcom documents this as a known outcome of out-of-band vCenter root changes, including certificate-manager Option 8 scenarios. If NSX Compute Manager is down, validate the vCenter certificate chain. Broadcom’s NSX guidance points to invalid or incorrect Machine SSL certificate chains and missing trusted roots as common causes. If only browsers or API clients complain, that may be a Machine SSL trust issue, not a VMCA reset issue. Consider replacing the Machine SSL certificate with a trusted custom certificate or importing the VMCA root into trusted stores, depending on the organization’s certificate model.
Rollback and Fallback Guidance
A certificate reset is only safe when rollback is real. Minimum controls include a completed VAMI backup, completed offline snapshot, consistent protection for all linked vCenter and PSC nodes in the SSO domain, an approved change window, checked STS state, confirmed PNID, captured current certificate inventory, prepared connected systems list, assigned rollback owner, and identified support path. Do not rely on automatic rollback for Option 8. KB 318767 states that Option 8 does not support automatic rollback. For Enhanced Linked Mode or shared SSO domains, do not snapshot one node casually and leave others at different states. Certificate and SSO trust data is shared enough that inconsistent rollback can make recovery worse.
The rule is simple: fix the broken trust relationship at the layer where it broke. Do not keep resetting VMCA because downstream tools still trust the old root.
Operational Implications for VCF
In a standalone vSphere environment, certificate regeneration is already significant. In VCF, it is a management-domain trust event. That means the runbook should live with the rest of your VCF lifecycle and operations documentation, not in a personal notes file. It should identify who owns vCenter certificate operations, who owns SDDC Manager trust validation, who owns NSX Compute Manager validation, who owns backup and monitoring re-trust, who validates automation accounts and scripts, and who approves the certificate authority model. It should also state the intended certificate posture.
VMware’s own certificate guidance describes hybrid mode as a practical option for many customers and cautions against using VMCA as an intermediate under an enterprise CA because it extends enterprise trust into VMCA key custody. That is a governance decision, not just a technical preference.
Conclusion
Regenerating vSphere certificates with self-signed VMCA is the right move when the trust anchor is the problem, when multiple VMCA-issued certificates are expired, or when the environment needs to return cleanly to the default VMCA model. It is the wrong move when only one leaf certificate, one browser warning, one NSX trust entry, or one SDDC Manager trust store needs attention. Treat VMCA regeneration as management-plane trust surgery. The successful outcome is not just “the command completed.” The successful outcome is that vCenter services restart cleanly, STS is valid, VECS shows sane expiration dates, Machine SSL presents the expected identity and chain, SDDC Manager trusts the current vCenter root, NSX Compute Manager is connected, backup, monitoring, Aria, and automation clients trust the new endpoint, and the certificate model is documented so the next renewal is planned instead of recovered. That is the difference between certificate maintenance and certificate incident response.
From Fixcerts to vCert: A Safer vCenter Certificate Recovery Path
vCenter certificate problems rarely arrive as clean, isolated maintenance tasks. They usually show up as failed logins, services that refuse to start,…
The post The VMCA Reset Decision: When Regenerating vSphere Certificates Is the Right Move appeared first on Digital Thought Disruption.