ESXi upgrade shows SHA1 cert issue

VMware upgrades are supposed to be boring. But one old certificate can still blow up an ESXi or vCenter move to 8.0 before the installer really starts. That’s the story here — not a brand-new bug, but a compatibility trap Broadcom is still updating KBs for in 2025 and 2026. Basically, vSphere 8 rejects SHA-1-signed certificates in places a lot of operators don’t think to check, and the failure shows up as a precheck stop rather than a graceful warning. ### What is actually failing? The upgrade precheck looks through vCenter and connected ESXi hosts for weak certificate signatures. If it finds SHA-1 anywhere relevant, the upgrade stops. On the ESXi side, the error often names the host certificate `rui.crt`. On the vCenter side, it can point at the VECS `TRUSTED_ROOTS` store or the machine SSL chain. Broadcom’s current guidance is simple but unforgiving — SHA-1 is not supported in vSphere 8 in these paths, so the certs have to be replaced or removed before you continue. (knowledge.broadcom.com) ### Why does SHA-1 matter now? Because vSphere 8 draws a harder line than older releases did. Plenty of environments carried forward ancient internal PKI, old VMCA roots, or custom CA chains that still worked in 7.x. The upgrade to 8.0 is where that technical debt gets surfaced. The catch is that the problem may not be the leaf cert you’re actively using — it can be an old root or intermediate still sitting in trust stores and getting pushed around the environment. (knowledge.broadcom.com) ### Where does the bad cert usually hide? Three places keep showing up. First, the ESXi host’s own TLS cert — `rui.crt`. Second, `castore.pem` on standalone hosts or hosts with custom trust material. Third, vCenter’s VECS `TRUSTED_ROOTS`, which can then propagate trusted roots down to hosts when you’re using VMCA mode. That means an operator can renew one visible certificate and still fail the precheck because an older SHA-1 root is hanging around elsewhere in the chain. (knowledge.broadcom.com) ### What about custom CA setups? That’s where things get messier. Broadcom has a separate KB for environments where VMCA is configured as a subordinate CA. In that setup, if the external root uses SHA-1, you don’t just swap one cert. You may need to reset VMCA, replace the root or intermediate, regenerate vCenter certs, reissue ESXi TLS certs, and then clean old roots out of `TRUSTED_ROOTS`. In other words — the upgrade problem is really a PKI cleanup problem. (knowledge.broadcom.com) ### How are you supposed to catch it early? Broadcom’s main upgrade KB points admins to a Python precheck script, `vsphere8_upgrade_certificate_checks.py`, that scans vCenter stores and connected ESXi hosts before the upgrade. If it throws `ERROR` or `FAIL`, Broadcom says to fix those entries first. That’s the practical move — run the check, inventory every SHA-1 hit, then decide whether you’re replacing a machine cert, removing stale roots, or reissuing host certs. (knowledge.broadcom.com) ### Is every SHA-1 error real? Turns out, no. A March 2026 KB documents a false positive during ESXi 8 patching where memory exhaustion prevents OpenSSL validation from running correctly. The UI then surfaces a bogus message like “SHA-1 signature found in host certificate False.” That matters because it changes the playbook — if your cert checks are clean but lifecycle operations still scream SHA-1, you may be looking at a host resource problem, not a crypto problem. (knowledge.broadcom.com) ### So what should operators do before upgrading? Treat certificate hygiene as part of the upgrade, not a post-check box. Audit vCenter VECS stores. Check ESXi `rui.crt` and certificate stores. Remove stale SHA-1 roots. Reissue anything chained to SHA-1 with SHA-2. Then refresh CA certificates to hosts and rerun the precheck. That sounds tedious — but it is much better than discovering in stage 2 that a forgotten root from 2014 is now the thing blocking your 8.0 rollout. (knowledge.broadcom.com) ### Bottom line The real news is that this is still an active operational footgun. Broadcom’s latest KB updates make clear the SHA-1 blocker is not just a one-off migration anecdote — it’s a recurring upgrade failure mode across host certs, trust stores, and custom CA chains, with at least one newer false-positive edge case layered on top. (knowledge.broadcom.com)