Short answer: the vCenter alarm “STS Signing Certificates are about to expire” means the Security Token Service signing certificate, which signs every vCenter SSO token, is within 90 days of expiry. Renew it before it lapses: in the vSphere Client (Administration → Certificate Management → STS signing certificate → Refresh with vCenter certificate) while vCenter still works, or with vCert over SSH if it doesn’t. An expired STS certificate breaks logins and can cause No healthy upstream.
Certificates in vCenter are usually associated with Machine SSL, Solution Users, or trusted roots. However, there is another certificate that can have a very large operational impact: the Security Token Service signing certificate, commonly known as the STS signing certificate.
The STS certificate is not the certificate you see in your browser when opening the vSphere Client. It is part of the vCenter Single Sign-On authentication flow. When a user or internal service authenticates, STS validates the primary credentials and issues a SAML token containing user or service attributes. That token is then used by vCenter services to trust the authenticated identity.
In short: if STS cannot issue valid tokens, vCenter authentication starts to break.
Broadcom describes the STS certificate as critical for vSphere SSO because it is responsible for issuing, validating, and renewing security tokens.
What is the STS signing certificate?
The Security Token Service is part of vCenter Single Sign-On. Its job is to issue signed SAML tokens after successful authentication.
By default, the VMware Certificate Authority, or VMCA, generates the STS signing certificate. In most environments, the default VMCA-issued STS certificate is sufficient. A fresh installation of vSphere 7.0 Update 1 or later creates an STS signing certificate valid for 10 years, while KB 318968 describes a lifetime of around two years in its replacement scenarios, so check the actual date on your system rather than assume. You can refresh it with a new VMCA-issued certificate, or import a custom / third-party STS signing certificate if your company security policy requires all certificates to be replaced.
However, replacing the STS certificate should not be treated as a routine cosmetic change. Broadcom specifically warns that refreshing the STS certificate with a vCenter-issued certificate can replace third-party/custom certificates and may take the environment out of compliance if custom certificates are required.
Why does STS expiration matter?
When the STS signing certificate expires, vCenter may no longer be able to issue valid SAML tokens. This affects both users and internal solution users.
The result can be severe:
- vSphere Client login failures
- vCenter services failing to start after reboot
vmware-stsdservice not startingvpxdauthorization errorsSigning certificate is not validNo Healthy Upstream- failures in Enhanced Linked Mode environments
- problems exporting OVF templates
- certificate replacement workflows failing because authentication itself is broken
Broadcom’s KB for "Signing certificate is not valid" or "No healthy upstream" explains that these issues occur when the STS certificate or its signing root certificate has expired, preventing internal services and solution users from acquiring valid tokens.
This is why an STS certificate problem can look much bigger than a normal certificate warning. It can make the entire vCenter feel broken.
Typical symptoms
If the STS certificate is already expired, you may see errors such as:
HTTP Status 400 – Bad Request
Signing certificate is not validCannot connect to vCenter Single Sign-On server
https://VC_FQDN/sts/STSService/vsphere.local503 Service Unavailable
No Healthy UpstreamYou may also see service startup failures after reboot. Broadcom notes that an expired STS certificate can prevent the vmware-stsd service from starting, which then causes dependent vCenter services to fail as well.
The warning: “STS Signing Certificates are about to expire”
In newer vCenter versions, you may receive the following alarm in the vSphere UI:
STS Signing Certificates are about to expireThis alarm means that the STS certificate for the vCenter Server Appliance is nearing expiration. Broadcom states that if the STS signing certificates expire without being replaced, vCenter will no longer be functional.
That warning should not be ignored.
When the alarm fires, and why it says 90 days when vCert says 91
The alarm starts 90 days before expiry and repeats once a week, then daily from seven days before expiry (Broadcom TechDocs). It actually triggers 90.999 days before the expiration date, so the alarm can say “expires in 90 days” while vCert reports 91. That is expected behaviour, not a second problem (KB 429527).
VMware Security Token Service “Healthy with warnings”
If the VMware Security Token Service shows warnings in the service health view or triggers a health alarm, two documented causes are worth checking:
- The STS signing certificate is close to expiry. Check its Valid until date as described below and renew it.
- The appliance is short on memory. During workload spikes the STS Java process can fail to allocate memory, exit with code 143 and be restarted by vMon, so its health briefly turns red and then green again. The SSO log directory then contains
hs_err_sts_pid<PID>.logfiles. One-off events can be ignored; if it keeps happening, add RAM to the VCSA (KB 433542).
How to check the STS certificate
For vCenter 7.0 Update 2 and later, the STS certificate can be checked from the vSphere Client:
vSphere Client
→ Administration
→ Certificates
→ Certificate Management
→ STS signing certificateThe UI shows the Valid until date, certificate status, and certificate chain details. Broadcom recommends checking the STS certificate periodically, because the general certificate expiry alarm does not account for the STS certificate in the same way.
checksts.py is deprecated: use vCert instead
For command-line or advanced checks, Broadcom now recommends using vCert instead of the older checksts.py script. The checksts.py script is deprecated, and vCert is the current recommended tool for certificate management and replacement workflows.
Recommended tool: vCert
Broadcom provides vCert.py, a menu-driven tool for certificate management on vCenter Server 7.0, 8.0, and 9.0. Its purpose is to simplify certificate replacement when certificates expire or are about to expire.
Basic usage:
unzip -q vCert-<version>.zip
cd vCert-<version>
chmod +x vCert.py
./vCert.pyUseful menu paths:
2. View certificate info
→ 8. STS signing certificates3. Manage certificates
→ 8. STS signing certificatesBroadcom’s KB also states that vCert creates logs under:
/var/log/vmware/vCertand uses a working directory under:
/root/vCert-masterfor staging and backups.
Replacing or refreshing the STS certificate before it expires
If the STS certificate is still valid and the vSphere Client is accessible, the preferred approach is usually to refresh it from the UI.
Path:
vSphere Client
→ Administration
→ Certificate Management
→ STS signing certificate
→ Actions
→ Refresh with vCenter certificateBroadcom marks Refresh with vCenter certificate as the recommended UI option. It generates a new VMCA-issued STS certificate. In vSphere 8.0 and later, refreshing or replacing the STS signing certificate no longer requires a vCenter restart (TechDocs).
There is also an Import and Replace Certificate option for custom or third-party certificates. Use this only when required by your company security policy.
Important: Before making certificate changes, create proper offline snapshots of all vCenter Server appliances in the environment. In Enhanced Linked Mode, this means all vCenter / PSC nodes in the same SSO domain. Broadcom explicitly recommends snapshots before STS certificate replacement operations.
What if vCenter is already broken?
If the STS certificate has already expired, the vSphere Client may not be usable. You may be stuck with:
No Healthy Upstreamor:
Signing certificate is not validIn that case, use vCert directly on the VCSA via SSH. Broadcom recommends vCert for checking and replacing STS signing certificates when vCenter is inaccessible.
The high-level recovery flow is:
1. Take offline snapshot / backup.
2. SSH to VCSA as root.
3. Upload and extract vCert.
4. Run ./vCert.py.
5. Check STS signing certificate.
6. Replace STS signing certificate.
7. Restart services if required.
8. Validate vSphere Client login.Never skip the snapshot step. Certificate repair can make the situation worse if performed incorrectly.
Important note for vSphere 8
In vSphere 8.0, vCenter Single Sign-On can automatically renew a VMCA-generated STS signing certificate before it expires. However, Broadcom has documented rare cases where an STS refresh happening during long-running vSphere Lifecycle Manager operations can cause task failures due to cached STS certificate data.
So even with automatic renewal, it is still useful to know where the STS certificate is, how to check it, and how it affects authentication.
Best practices
My practical checklist:
1. Check STS certificate validity regularly.
2. Do not wait until the last week before expiration.
3. Replace if the certificate expires within 6 months.
4. Use vSphere Client if vCenter is still healthy.
5. Use vCert if vCenter login or services are already broken.
6. Take offline snapshots before any certificate operation.
7. In ELM, snapshot all vCenter/PSC nodes in the SSO domain.
8. Be careful with custom/third-party STS certificates.
9. Document the certificate state before and after replacement.
10. Validate vCenter login, service health, and integrations after replacement.Broadcom recommends replacing the STS certificate if it is set to expire within six months. If expiration is more than six months away, schedule the replacement for an appropriate maintenance window.
Summary
The STS signing certificate is easy to overlook because it is not the browser-facing Machine SSL certificate. But it is one of the most important certificates in vCenter authentication.
When it expires, the impact can be dramatic: broken SSO, failed service startup, Signing certificate is not valid, and even No Healthy Upstream.
The key lesson is simple:
Do not wait for STS expiration to become an outage. Check it, plan it, snapshot first, and use the supported Broadcom workflows.
Not the same certificate: the STS signing certificate is different from the STS service’s TLS certificate on port 3128. If vCert reports STS_INTERNAL_SSL_CERT as LEGACY, or a scanner flags an old certificate on 3128 after you renewed Machine SSL, see STS_INTERNAL_SSL_CERT Explained: What vCert’s LEGACY Result Means. For which certificates vCenter now renews on its own, see vCenter Certificate Auto-Renewal: When You Still Need vCert.
Related vCenter certificate guides
- vCert: check and fix vCenter certificates with vCert.py
- lsdoctor: check and repair the vCenter Lookup Service
- vCenter “User password expired” on VAMI: a login failure that isn’t a certificate
References
- Broadcom KB 318197 —
"STS Signing Certificates are about to expire" alert received in vSphere UI - Broadcom KB 316619 —
"Signing certificate is not valid" or "No healthy upstream" error in vCenter Server Appliance - Broadcom KB 385107 —
vCert - Scripted vCenter expired certificate replacement - Broadcom KB 318968 —
Checking the STS certificate expiration and replacing expired STS certificates on vCenter Servers - Broadcom KB 423367 —
How to Export the STS Certificate from vCenter Server - Broadcom KB 429527 –
The alarm "STS Signing Certificates are about to expire" is issued but it actually expires in 91 days - Broadcom KB 433542 –
sts status changed from green to red alarm triggered in vCenter Server - Broadcom TechDocs –
Managing the vCenter Security Token Service
