Resolving SHA-1 Certificate Issues When Upgrading to VMware vSphere 8

With the end of general support for vSphere 7 approaching in October 2025 (VMware Blog), many customers are preparing to upgrade. During a recent vSphere 7 to vSphere 8 upgrade, I encountered an expected / unexpected issue related to SSL certificates that I wanted to share.

SHA-1 Certificates No Longer Supported in vCenter 8

Starting with VMware vCenter Server 8.0, SHA-1 signature algorithms are no longer supported. Any SSL certificates using SHA-1 must be replaced with stronger SHA-2 (e.g., SHA-256) certificates before upgrading. This change is a security measure to eliminate vulnerabilities associated with weak encryption algorithms like SHA-1.

Pre-Upgrade Certificate Cleanup

Before running the migration pre-checks, I had to clear existing SHA-1 certificates on the vCenter 7 appliance (vCSA7). If you're facing a similar upgrade, refer to using the certificate-manager Broadcom Knowledge Base - vSphere Certificate Manager for options with managing certificates on vCSA before migration.

Another helpful resource is Broadcom VMware KB Article 313460 (link), which details potential pre-check failures before upgrading to vSphere 8.

Installation Error: SHA-1 Certificates Rejected

After completing the installation and migration to vCenter 8 (vCSA8), I attempted to reinstall an externally signed (SHA-2) SSL certificate.

I knew that my new certificate was SHA-2 compliant....as shown below:

However, I encountered the following error:

[CERTIFICATE] Replace cert Failed: Exception found (Certificate uses a weak signature algorithm - SHA1WITHRSA. Only SHA-2 RSA algorithms are supported on the vCenter Server.)

In simple terms, vCenter 8 would not accept my SSL certificate. However, it wasn't the certificate that was the problem it was the CA Root Chain bundle.....because it contained a SHA-1 signature. This wasn't immediately clear from the error message, so here's how I tracked that down.

Troubleshooting and Resolution

So this error led to a frustrating back-and-forth with a well-known domain registrar and certificate authority (let’s just say their name evokes a paternal presence). Their support team assured me that the certificate bundle they provided was SHA-2 signed—but it wasn’t.

After researching, I found Broadcom VMware KB Article 322174 (link), which advises:

• Verify the new certificate files use SHA-2 (SHA256) algorithms.
• Check every certificate in the chain individually. If you only inspect the combined chain certificate, it may hide embedded SHA-1 certificates in the bundle. (THIS IS THE KEY!)
• Use a text editor to extract each certificate from the chain file and examine them separately.
• Ensure the entire chain (root, intermediate, and leaf certificates) is SHA-2 signed.

Final Fix

After verifying the certificate bundle using the breaking apart process, I confirmed that one of the embedded certificates was still SHA-1 signed. Notice the initial certificate bundle I open up and verify SHA-2, but then I break it apart to reveal one of the three certs are SHA-1 signed, See video below:

Ultimately, I went back to the certificate authority's root repository, found an updated SHA-2-only root bundle. Using this new CA Root bundle, my first indicator that I was on the right track was that the error message I received had changed. See below.....

"[CERTIFICATE] Replace cert Failed: Exception found (The provided MACHINE_SSL certificate and provided private key are not valid.)"

In this situation, my colleague generated a new CSR from vCenter and used it to obtain a signed certificate. However, I had a different version of the signed certificate that wasn’t linked to that CSR. After aligning our efforts, I shared my findings with him, and together, we used the new SHA-2-only root bundle to correctly install the new server certificate.

Takeaways

• Before upgrading to vSphere 8, check all SSL certificates to ensure they are SHA-2 signed.
• Do not rely on the combined chain file’s cryptography level—inspect each certificate separately.
• If an upgrade fails due to a weak signature algorithm, request an updated SHA-2 certificate bundle from your provider. Trust, but Verify - Make sure to double-check what was provided or downloaded.

Hopefully, this helps anyone facing the same issue and saves some troubleshooting time.

##########################

One way businesses and agencies can navigate the complex world of technology is by working with a trusted value-added reseller (VAR). VARs buy products from manufacturers and add additional value in the form of customized services, technical support, or expertise in a particular industry or market before reselling them to the end customer. A trusted VAR can provide advice, guidance, and support throughout the entire buying process, helping customers make informed decisions and get the most out of their technology investment. With their knowledge and experience, VARs can be an invaluable asset for individuals or businesses looking to purchase technology products or services. By working with a trusted VAR, customers can have peace of mind knowing they are getting high-quality products and services tailored to their specific needs.

Colossal, established in 2009, is a value-added reseller headquartered in Annapolis, Maryland. As a Service-Disabled Veteran-Owned Small Business (SDVOSB), we boast a range of premier vendor partnerships, industry accredited certifications, and employ top-notch engineering resources in-house to assist our customers.

Thanks for reading my article!!