vCenter Sign-In Fails After a Certificate Expires: Find the Store Responsible

Direct answer: If the vSphere Client spins at sign-in, shows "no healthy upstream", "503 Service Unavailable" or "Signing certificate is not valid", or vCenter services such as vpxd will not start after a reboot, an expired certificate is one of the first things to check. vCenter uses several kinds of certificate, and they fail in different ways. The Security Token Service (STS) signing certificate is the one used to issue sign-in tokens. It is not covered by the general certificate expiry alarm. The Machine SSL certificate and the solution-user certificates live in the VMware Endpoint Certificate Store (VECS). Find which one expired, with read-only listings, before you change anything. Broadcom's documented renewal path is its vCert tool, and the tool's own warning sets the precondition: a valid file-based backup, or offline snapshots of every vCenter in the Single Sign-On (SSO) domain.

Why it matters

When vCenter cannot sign anyone in, administrators lose the console for every host and VM it manages. Running VMs keep running, but vCenter-driven work stops: migrations, backup jobs that authenticate through vCenter, monitoring and scheduled tasks. Broadcom's KB 316619 notes one sharp edge. In an Enhanced Linked Mode (ELM) environment, an expired STS certificate can make all linked vCenter Server instances inaccessible, not just one.

The urgency often pushes people towards a quick reset of every certificate. That can work. But it changes trust relationships that other products may depend on, and on a linked vCenter a partial rollback can leave the directory replication inconsistent. A few minutes spent identifying the expired certificate keeps the change as small as it needs to be.

How it works

Three groups of certificates

For diagnosis, treat vCenter's certificates as three groups:

• STS signing certificate. The SSO service uses it to sign the tokens that the vSphere Client and internal services present. When it expires, KB 316619 says the vmware-stsd service cannot start and internal services and solution users cannot acquire valid tokens. Broadcom states that it "generally expires two years from the initial creation or when its own signing certificate has expired", which varies with how the environment's certificates were set up.
• Machine SSL certificate. This is the certificate the appliance presents on its web endpoints, held in the MACHINE_SSL_CERT store. KB 396907 describes an expired self-signed Machine SSL certificate causing "Error occurred while fetching machine certificates", with the sps and vpxd-svcs services failing to start.
• Solution-user certificates. KB 421381 lists machine, vsphere-webclient, vpxd, vpxd-extension and hvc. These certificates let vCenter's own services authenticate to the STS to obtain tokens. When they expire, vpxd and vpxd-svcs may stay in a Stopped or StartPending state.

Expired CA certificates also appear in KB 344201's symptom list, alongside SMS and data-encipherment certificates. If a root CA has expired, renewing a single leaf certificate is not the whole answer.

What warns you, and what does not

KB 318968 states: "The certificate expiry alarm does not account for the STS certificate. There is a separate alarm for the STS certificate status." From vCenter 7.0 Update 1, a weekly notification starts 90 days before the STS certificate expires and becomes daily in the final week. From 7.0 Update 2, the vSphere Client shows the STS signing certificate's "Valid until" date under Administration > Certificates > Certificate Management.

From vCenter 8.0 Update 3h, KB 396907 states that Machine SSL certificates renew automatically five days before expiry, as long as the advanced setting vpxd.certmgmt.mode is vmca. Releases before 8.0 Update 3h need manual replacement. Custom CA-signed certificates are outside that auto-renewal statement.

Read-only checks

None of these was run for this article. None of them replaces or changes a certificate. Running vCert does write files: it creates /var/log/vmware/vCert/vCert.log and a dated working directory under /storage/vCert (KB 385107). The SSH commands need a root shell on the appliance. Treat that access as a privileged change-window activity under your normal approval process.

1. Record the exact symptom. Capture the sign-in page error, the time, and whether the VAMI on port 5480 loads. KB 344201 lists a VAMI message that points directly at certificates: "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired".

2. Check service state. service-control --status --all lists the services that are stopped. A stopped vmware-stsd points at the STS certificate (KB 316619). Stopped vpxd and vpxd-svcs with a running STS point at Machine SSL or solution-user certificates (KB 421381, KB 396907).

3. List every VECS store with its expiry dates. This is the command given in KB 344201 and KB 421381:

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;

Read the output store by store. MACHINE_SSL_CERT holds the Machine SSL certificate. The machine, vsphere-webclient, vpxd and vpxd-extension stores hold solution-user certificates. TRUSTED_ROOTS holds CA certificates. Write down every alias whose "Not After" date has passed or is close.

4. Check the STS signing certificate separately. It is not in the VECS listing above. If the vSphere Client still opens (7.0 U2 and later), read the STS card under Certificate Management. If it does not, KB 318968 and KB 316619 point to vCert's menu 2 (View Certificate Info), option 8 (STS signing certificates). The view options do not replace any certificate, although the session still writes the vCert log and working directory noted above. Keep the view menu separate from the replacement options. The older checksts.py script is deprecated in favour of vCert.

5. Read the logs that name the failure. KB 316619 identifies two log lines. One is "InvalidTimeRange ... Signing certificate is not valid" in /var/log/vmware/sso/vmware-identity-sts.log. The other is a matching token-authority rejection in /var/log/vmware/vpxd-svcs/vpxd-svcs.log. KB 421381 shows vpxd.log reporting "certificate has expired" during the TLS check against the vCenter FQDN when Machine SSL has expired.

6. Find out whether this vCenter is linked. KB 318333 gives a read-only command to show replication partners:

/usr/lib/vmware-vmdir/bin/vdcrepadmin -f showpartnerstatus -h localhost -u administrator

It prompts for the SSO administrator password. Enter it interactively and do not put it on the command line. If partners are listed, the vCenter is in ELM, and the snapshot rules below apply to every node.

7. Check for vCenter HA. Broadcom's guidance is not to snapshot a vCenter that is part of a vCenter High Availability (VCHA) configuration. The VCHA configuration has to be removed first and redeployed afterwards (KB 318333, KB 344201).

Interpreting the results

The last row matters. Clock skew, DNS failures and identity-source changes also stop sign-in. If every listed date is valid, do not replace certificates just in case.

Decision guidance

Certificate replacement is a change to the vCenter SSO domain. Plan it as one.

Choose the rollback point first. Broadcom's KB 313886 lists certificate replacement ("Machine, CA, STS, etc") among the changes that require offline snapshots of all nodes in the SSO domain. The vCert tool's own warning asks for "a valid VAMI-based backup or offline snapshots of ALL vCenter/PSC nodes in the SSO domain". For ELM, KB 313886 explains why. Linked vCenters replicate their directory every 30 seconds. Snapshots of running appliances are in an uncertain replication state even when quiesced, and reverting one node but not the others can introduce inconsistencies that sometimes cannot be repaired. The documented pattern has three parts:

• power off every linked vCenter, snapshot each one (KB 318333 recommends doing this from the ESXi host client), then power them back on;
• if you must roll back, revert all nodes to that same snapshot set, and start powering them on only once every node has been reverted;
• make sure no vCenter backup task is running when you take the snapshots (KB 313886).

Supervisor and VKS exception. If the vCenter runs vSphere Supervisor or VKS, KB 313886 warns that vCenter snapshot rollbacks will not work with the Supervisor Control Plane VMs. In that case the rollback point is a file-based backup, taken as part of the Supervisor backup and restore process, not a snapshot set.

A standalone vCenter without Supervisor can be snapshotted online without memory (KB 318333, KB 316619). File-based backup is Broadcom's stated alternative. Make sure a recent file-based backup exists and that you know how to restore it before you start.

Use the documented tool, at the documented scope. The vCert banner states that it "is intended to be used at the direction of Broadcom Global Support" and that changes "could render this system inoperable". If you have a support contract, open a case and follow the support engineer's direction. Replace only what step 3 or step 4 showed as expired, unless support advises a full reset.

Know what changes for other products. A new Machine SSL certificate changes the thumbprint that external integrations see. Backup software, monitoring and anything else that pinned the old certificate may need to re-trust vCenter. List those integrations before the change so you can check each one afterwards. Do not assume they will reconnect on their own.

After replacement, KB 344201 and KB 396907 restart all services and then check status:

service-control --stop --all && service-control --start --all
service-control --status --all

Restarting all services interrupts vCenter for every user and integration, so it belongs inside the change window.

What not to do

• Do not snapshot only one vCenter in a linked group, or revert one node on its own.
• Do not snapshot a vCenter while it is part of a VCHA cluster.
• Do not delete VECS entries or edit certificate stores by hand to "clear" an expired entry. Use the tool's replacement workflow. KB 344201 notes the VMware Directory may also fail to update during replacement and then need separate repair.
• Do not treat a reset of all certificates as a routine fix when one store has expired. It replaces trust that integrations rely on.
• Do not stop at the vSphere Client sign-in. Prove that the integrations work too.
• Do not paste the SSO administrator password into commands, scripts or tickets.

Limitations

• No command was run for this article, and no lab validation has been done.
• Broadcom KB "Updated On" dates were not displayed in the retrieved copies. Check the current KB before acting, because vCert versions and menu numbers change.
• vCenter 6.x and Windows vCenter use certificate-manager instead (KB 344201). They are not covered here.
• Custom and enterprise CA-signed certificate workflows, and ESXi host certificates, are out of scope.
• The general vCenter file-based backup and restore procedure is covered by the existing vCenter recovery article, not here.

Acceptance checklist

• [ ] The expired certificate is named by store or type with its "Not After" date, and the evidence is saved.
• [ ] Whether this vCenter is in ELM or VCHA is recorded.
• [ ] A rollback point exists: a file-based backup, or offline snapshots of every node in the SSO domain taken while all nodes were powered off. With vSphere Supervisor or VKS, it is a file-based backup, because snapshot rollback does not work for the Supervisor Control Plane VMs.
• [ ] Replacement followed the Broadcom procedure for that certificate type, under support direction where available.
• [ ] service-control --status --all shows the expected services running.
• [ ] A test administrator signs in to the vSphere Client.
• [ ] Each listed integration (backup, monitoring, automation) has reconnected or been re-trusted.
• [ ] Snapshots taken for the change are removed once the result is accepted, following the snapshot article.
• [ ] A calendar check or alarm review for the STS certificate is in place before its next expiry.

References

Accessed 2 November 2026. Broadcom "Updated On" dates were not displayed in the retrieved copies.

• Broadcom Knowledge, Checking the STS certificate expiration and replacing expired STS certificates on vCenter Servers (318968)
• Broadcom Knowledge, "Signing certificate is not valid" or "No healthy upstream" error in vCenter Server Appliance (316619, legacy 76719)
• Broadcom Knowledge, Error: "no healthy upstream" or "503 Service Unavailable" when accessing vCenter Server (344201)
• Broadcom Knowledge, Machine SSL certificate replacement and auto-renewal in vCenter Server 8.x (396907)
• Broadcom Knowledge, vCenter Server inaccessible due to expired vCenter certificates (421381)
• Broadcom Knowledge, vCert - Scripted vCenter expired certificate replacement (385107)
• Broadcom Knowledge, VMware vCenter in Enhanced Linked Mode pre-changes snapshot (online or offline) best practice (313886)
• Broadcom Knowledge, Snapshot Best practices for vCenter Server Virtual Machines (318333)

Related articles

• How to harden VMware without breaking operations or recovery
• How to back up and rehearse recovery of the vCenter appliance
• VMware Snapshots vs Backups: A Practical Guide to Recoverability
• AD Users Cannot Sign In to vCenter After a Domain Controller Certificate or Server Change

Learning notes

1. vCenter sign-in depends on several certificate groups. Diagnose which group failed before choosing a fix.
2. The STS signing certificate has its own check and its own alarm. The general certificate alarm does not cover it.
3. The VECS listing with "Not After" dates is the read-only starting point for Machine SSL and solution-user certificates.
4. In Enhanced Linked Mode, rollback means offline snapshots of every node, reverted together, or a file-based backup. With Supervisor or VKS, only the file-based backup applies.
5. A replacement is finished only when sign-in and every dependent integration have been proven.