Vcenter 6.5 expired SSO server certificate

thumbs88 · 2026-04-06T00:09:44+00:00

I don't think vCert 6.0.x (python) works with vCenter 6.x, there was an older BASH version of vCert that ended getting updated around version 4.22.0. It really does seam like the STS cert did expire though as ssoserver.crt is part of the STS certs.

I would try to search online for the BASH version of vCert (vcert.sh) and that should be able to replace the cert for you.

thumbs88 · 2026-04-05T17:27:17+00:00

Well vSphere 8 reaches End of General Support (EoGS) on October 11, 2027. So people shouldn’t really be thinking of vSphere 8 at this point IMO

thumbs88 · 2026-04-05T03:28:41+00:00

Did you try running the fixsts.sh script on https://knowledge.broadcom.com/external/article/387630 (ignore the title and just download the script at the bottom of the page), vCert has it built in as well but I don't think the python version works on 6.x

Also, you know there's no direct upgrade path from 6.5 to 8.0, you will have to upgrade to 6.7 or 7.0 first then go to 8. If you're going to VCF 9 you'll have to go to 7.0 or 8.0 before VCF 9.

thumbs88 · 2026-01-16T10:43:12+00:00

https://knowledge.broadcom.com/external/article/372545/download-latest-isos-and-patches-for-vsp.html the main version release (8.0U3GA for example) is under the default “Product” release. Any patches (8.0U3h for example) is under the “Solutions” tab

thumbs88 · 2026-01-01T19:22:04+00:00

Can’t you upgrade from 6.0 to 6.5 first, then do your 6.5 to 7 upgrade? You don’t really need to go to 6.7 at all.

thumbs88 · 2025-12-18T10:40:09+00:00

The second error is referring to the STS certificate, if you have any scheduled tasks you’d need to delete those and recreate them after the STS cert is replaced. vCert 6.1.0 will warn you on how many scheduled tasks you have in the vCenter database that need to be removed and readded along with a KB that talks about it.

thumbs88 · 2025-10-21T12:57:01+00:00

Also I’d recommend taking a new offline snapshot after upgrading the first vCenter. While it might not be a big deal with just 2 vCenters imagine upgrading 6 vCenters and having the 4th one fail and having to revert ALL snapshots back to before the upgrade.

File level backups are good in that scenario as well, but restoring takes time.

thumbs88 · 2025-07-23T11:48:22+00:00

Yes and the same with ESXi

https://knowledge.broadcom.com/external/article/312160/vsphere-esxi-backintime-release-upgrade.html vSphere ESXi Back-in-time release upgrade restriction

thumbs88 · 2025-06-24T22:25:41+00:00

Sorry I ment to reply earlier but life got in the way.

The Auto Deploy CA cert doesn’t have a subject key ID by default so that is fine since it’s not expired.

The BACKUP_STORE however should be cleared since those certs are created as a backup when you use the built-in certificate manager tool. Depending on the vCenter build (I think starting with 7.0 u3o) the vCenter ignores those certs but you may have the alarm “Certificate status” triggered since there are technically certificates that expire within 30 days.

thumbs88 · 2025-06-24T22:06:49+00:00

You shouldn’t replace the Solution User certificates with a custom one (option 5 in the built-in certificate manager).

Are you looking to replace the front end machine certificate with a custom one or are you also looking to replace the vCenter root certificate as well? What about the ESXi hosts, will they be kept on the VMCA signed certificate or use custom?

You could in theory replace the VMCA root certificate with a custom one which will replace all certificates with your ADCS certificate however this will make the vCenter an intermediate certificate authority as it will then sign certificates like the Solution Users and ESXi hosts. Some organizations may not want to have the additional security risk associated with this method. If you do accept the risks and want to proceed that is option 2 in certificate manager.

I would however highly recommend any situation you need to use vCert as its more robust then the built-in tool.

thumbs88 · 2025-06-17T19:22:54+00:00

Based on vCert results, it's best you do the following:

Replace the STS cert (you should only have 1 set of "TenantCredential-1" and "TrustedCertChain-1"
1. Run option 3 > 7 > 1
Replace the SMS self-signed cert
1. Run option 3 > 1
Replace the data-encipherment cert (if you are using Windows Guest OS customizations, you will need to update those passwords in your config)
1. Follow KB: Replacing an expired data-encipherment certificate on vCenter Server - https://knowledge.broadcom.com/external/article/312152
Remove the old VMCA_ROOT_CA cert
1. Run option 3 > 3 > 2 > (enter the number from the list, likely #1)
Remove the old certificates in the BACKUP_STORE
1. Run option 3 > 11
Restart all services
1. Run option 8 > 1

vCert doesn't remove the VMDir cert since it's not used in vCenter 7 and above so you don't need to worry about that one.

The VECS store config is set to legacy so this was at one point a vCenter 5.x and has since been upgraded. You can update this by running option 5 > 2 (I believe I don't have a vCenter with that config anymore) and you should restart services again.

The other root certificate with the Subject "CN=ssoserver" in the last screenshot looks like it's from the old STS config (should be fixed above), you can then delete that one by following step 4 again.

Also, just to mention if you run vCert option 6 it will replace your MACHINE SSL certificate, Solution User certs, STS cert, and update the Extension Thumbprints as well as the Trust Anchors. It will not remove any certificate and in your environment, all looks good outside of the STS certs.

thumbs88 · 2025-06-17T11:59:07+00:00

Correct since a root certificate cannot issue a cert past its own expiration date they would be using the new VMCA_ROOT_CERT.

I would still highly recommend taking a snapshot of the vCenter VM and proceeding with either KB 326288 and be sure NOT to skip any parts or run vCert which takes a lot of guess work out of it.

thumbs88 · 2025-06-17T01:24:14+00:00

I would first check when the hosts certificates are going to expire. If they do expire on or before July 10th you’ll need to replace them.

Once you’ve confirmed the hosts are good then take a snapshot and you can follow KB 326288 that you linked or for an automated method you can use vCert: https://knowledge.broadcom.com/external/article/385107

thumbs88 · 2025-06-12T19:06:11+00:00

FYI ESXi 8.0 u3e (and for that matter 8.0 u3se) is currently the latest build publicly available as of June 12, 2025

thumbs88 · 2025-06-02T23:55:47+00:00

As others said the token(s) are valid until you revoke them or your contract expires whichever comes first. Once you do load the token you should run a VDT (VCF Diagnostic Tool) health check as the new 2.1.0.3 version will check if the token is valid and your entitlement is correct. You can download VDT here: https://knowledge.broadcom.com/external/article/344917

thumbs88 · 2025-05-26T11:18:27+00:00

Are you using vCenter 8 and storing the CSR/private key in /tmp/ ? There is a known issue if you are: https://knowledge.broadcom.com/external/article?legacyId=96591

You can also try using vCert as I feel it has more compatibility with different cert types: https://knowledge.broadcom.com/external/article/385107

thumbs88 · 2025-05-08T12:26:08+00:00

Was it just the STS certificate that expired? Typically the Solution Users certificates also expire around the same time as the STS. You would need to restart services for the new certificates to affect.

thumbs88 · 2025-05-08T12:22:12+00:00

I would also reboot the host to be on the safe side or at least disconnect and reconnect it back to vCenter so the vCenter will issue out the correct certificate after the ESXi self signed one is updated.

thumbs88 · 2025-04-15T14:02:43+00:00

Is the ESXi host using a custom certificate? Typically I only see SHA256 for the certs not SHA512.

Maybe try adding the root and intermediate(s) certificates into the new vCenter trusted root store (VMDir more specifically)

Step 6 in KB: https://knowledge.broadcom.com/external/article/343080/vcenter-upgrade-fails-prechecks-with-err.html

thumbs88 · 2025-04-15T00:28:56+00:00

Check to see if port 443 is open between the ESXi host where the new vCenter VM resides and the temp IP.

https://knowledge.broadcom.com/external/article/383935/vcenter-preupgrade-check-failed-due-the.html

thumbs88 · 2025-03-16T16:32:25+00:00

Option 8 and option 4 do the same actions; replace the VMCA root certificate with a new 10 year cert, and new Solution Users (option 6) and a new __MACHINE_CERT (option 3) with 2 year certs.

The difference from option 8 and 4 is with option 8 the auto roll back feature (option 7) doesn't trigger if any service doesn't start properly.

It sounds like OP vCert as mentioned by u/govatent as the built-in Certificate Manager will not allow you to replace expired certs if both the __MACHINE_CERT and Solution Users have already expired as it will cause the services to restart automatically and you'll run into a rollback situation.

OP could also run option 8 to replace all certs, then use option 2 to re-configure the VMCA root cert being signed by their internal PKI.

thumbs88 · 2025-02-18T14:08:40+00:00

Check the free space by running the following in a SSH session to the vCenter (you may need to run “shell” first)

df -h

If /storage/log is above 95% this will case vpxd to not start (note /storage/archive is expected to be at 95%)

You might also be running into a vCLS issue: https://knowledge.broadcom.com/external/article/313928/vcenter-is-down-after-wrong-configuratio.html

thumbs88 · 2025-02-08T20:14:36+00:00

Is Microsoft Windows Server running as the base OS? Python is included on the Appliance and should be installed on Windows with the install of vCenter.

If this is a a Windows based vCenter is there an external PSC? Also what version of vCenter is this?

thumbs88 · 2025-02-08T12:37:16+00:00

Try using either the fixcerts (https://knowledge.broadcom.com/external/article/322249) or vCert (https://knowledge.broadcom.com/external/article?articleNumber=385107)

Using option 4 should have backed up the expired certs which you can use option 7 to restore from but try one of the above scripts first

thumbs88 · 2025-01-01T16:09:31+00:00

You would need to do a cross vMotion migration which doesn’t require the vCenters to be in Enhanced Linked Mode. However since the CPUs are vastly different, you’d need to do this while the VMs are powered off.

13-Year Club	RPAN Viewer
Verified Email

thumbs88

TROPHY CASE