Wednesday, September 17, 2025

Upgrade vCenter Server Appliance 7.0 U3s to 8.0 U3g

Upgrade vCenter Server Appliance 7.0 U3s to 8.0 U3g

Synopsis

We are now extremely close to when all things vSphere 7 are at EOL date. Many companies have waited until the last minute to do these upgrades and so now we are at ‘game day’ for upgrading them. Fortunately for a basic vCenter installation the process is pretty painless. Anytime you are performing upgrades to your vSphere services I highly recommend utilizing the VMware Product Interoperability Matrices in order to ensure all of your products are able to work with one another.

Prerequisites

  • The vSphere environment is running as a standard deployment (doesn’t matter the size)
  • The environment is designed to be as secure as possible; this includes limiting connections into the VMs to ensure compliance.
  • DNS, including both A and PTR records, is in place and working as expected prior to upgrading.
  • NTP is configured and working as expected.
  • SSH/Shell access is enabled.
  • Root PW is not expired.
  • Upgrade all hypervisors to the latest version of ESXi 7.0 U3 (Recommended)
  • Upgrade all existing VMware vSphere Distributed Switch (VDS) to 7.0 (Recommended) (See footnotes 1)
  • VECS store root CA certificate is SHA-2 (See footnotes 2)
  • A backup has been performed on the vCenter.
  • A clone of the vCenter is created.
  • A snapshot of the vCenter is created.

NOTE: It is highly recommended that you clone your vCenter and perform these upgrades in a network isolated environment. This will ensure you have the best chance of success as you can ensure any issues you run into will be addressed in a ’safe’ enviornment.

NTP configuration

The easiest way to configure NTP is through the VAMI. However, if your unable to adjust it properly through the VAMI then you can log into the primary SSH access (do NOT go fully into shell) and run the following command at the ‘command>ʼ prompt:

ntp.set –servers 172.0.0.1,time.google.com

Upgrade VDS to 7.0 (Recommended)

  • In vCenter on the inventory screen click on globe icon, this is for network, and locate the VDS.
  • Click on Actions –> Upgrade –> Upgrade Distributed Switch.
  • Select the highest version of Distributed Switch that you can, generally that will be 7.0.3 and select ‘nextʼ.
  • Confirm your compatibility is correctly showing for all of the hosts in the VDS and click ‘Nextʼ. NOTE: Any hosts that are not compatible should be fixed prior to upgrading!
  • Review all of the information and finish out the wizard.

Deploy Appliance

  1. Right click on the hypervisor you want to put the new vCenter onto and click on ‘Deploy OVF Template’
  2. On ‘Select an OVF template’ either enter the URL or click local files and upload the file.
  3. On ‘Select a name and folder’ enter the name the VM will show within vCenter and select the location of the VM.
  4. On ‘Select a compute resource’ ensure your hypervisor is selected and that it passes compatibility checks (You can select auto power on if you would like).
  5. On ‘Review details’ confirm the information is accurate.
  6. On ‘License agreements’ read over the EULA and click ‘I accept all license agreements.’
  7. On ‘Configuration’ select the appropriate size and type of deployment.
  8. On ‘Select storage’ select the appropriate datastore you want to put the VM on and select the disk format type.
  9. On ‘Select networks’ make sure you connect the new VM to the appropriate network for the vCenter. It is recommended it is the same network as the existing vCenter because the new VM will eventually be given the old vCenter’s IP address.
  10. On ‘Customize template’ enter the root PW that you use for your existing vCenter (this just makes the process easier) and leave all other values alone.
  11. On ‘Ready to complete’ review the information and complete the wizard.
  12. Power on the new vCenter VM. NOTE: If you did not set any variables earlier then you will need to log into the machine at console and check all settings. Example: IP address configuration, NTP settings, any hosts files, etc. It is important that NTP is setup and it is best to ensure this machine is on the same VLAN as the source VLAN.

Perform Upgrade

  1. Browse to the VAMI of the new target appliance and log in with the password you configured.
  2. Click on the ‘Upgrade’ button.
  3. On the ‘Introduction’ page click on ‘Next’.
  4. Enter the appropriate information and click ‘Next’.
  5. Wait for the ‘Pre-upgrade checks are in progress …’ to complete and review the results. If there is no failures then you can click ‘CLOSE’ and proceed with the rest of the process.
  6. On ‘Select upgrade data’ select whichever is appropriate for your configuration and click ‘NEXT’
  7. Provide an answer to the ‘Configure CEIP’ and and click ‘NEXT’
  8. Finally, review your information then scroll down the page and click the tick box for ‘I have backed up the source vCenter Server and all the required data from the database.’ and click ‘FINISH’
  9. Review the ‘Warning’ dialog and click ‘OK’ when you are ready.
  10. Allow the process to complete. If you get signed out the process will continue in the background. However, if you do not want to get kicked out then copy the URL, open a new browser window, and then you can refresh it to your hearts content.
  11. Log into the vCenter and confirm everything is working as expected.

Known Issues

vCenter 8 does not allow SHA-1 SSL certificates. If you are using a self-signed certificate then there is a good chance yours is going to run into this issue. For our vCenter we will go ahead and update it as it is indeed an SHA-1. If you go through the vCenter upgrade process and it fails with the error below then you know you have the same problem and need to review the ‘Prerequisites’ above, specifically “VECS store root CA certificate is SHA-2”.

Error
Support for certificates with weak signature algorithms has been removed in vCenter
Server 8.0. The certificate with subject ’/C=US/ST=CA/L=Palo Alto/OU=VMware/O=
VMware/CN=VMware’ in VECS store TRUSTED_ROOTS has weak 
signature algorithm sha1WithRSAEncryption.

Resolution
Replace the certificate with subject ’/C=US/ST=CA/L=Palo Alto/OU=VMware/O=
VMware/CN=VMware’ in VECS store TRUSTED_ROOTS with a
certificate that uses the SHA-2 signature algorithm. Caution: Verify that any
certificates signed by the problematic certificate are not in use by vCenter
Server. Refer to the vCenter Server release notes and VMware KB 89424 for more 
details

CA root cert is not SHA-2

Self-Signed Root Cert

If you are using the built-in VMware certificate authoring system then the process to update a SHA1 certificate is pretty simple with the built-in certificate manager tool.

  1. Lets update all certificates on the vCenter by running the built-in certificate manager tool. Log in via command line to the vCenter and run the command.
  2. The results will look something like this: 
     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|                                                                     |
|      *** Welcome to the vSphere 7.0 Certificate Manager  ***        |
|                                                                     |
|                   – Select Operation –                              |
|                                                                     |
|      1. Replace Machine SSL certificate with Custom Certificate     |
|                                                                     |
|      2. Replace VMCA Root certificate with Custom Signing           |
|         Certificate and replace all Certificates                    |
|                                                                     |
|      3. Replace Machine SSL certificate with VMCA Certificate       |
|                                                                     |
|      4. Regenerate a new VMCA Root Certificate and                  |
|         replace all certificates                                    |
|                                                                     |
|      5. Replace Solution user certificates with                     |
|         Custom Certificate                                          |
|         NOTE: Solution user certs will be deprecated in a future    |
|         release of vCenter. Refer to release notes for more details.|
|                                                                     |
|      6. Replace Solution user certificates with VMCA certificates   |
|                                                                     |
|      7. Revert last performed operation by re-publishing old        |
|         certificates                                                |
|                                                                     |
|      8. Reset all Certificates                                      |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
  3. You will want to select option 8, to ‘Reset all Certificatesʼ. 
    Note : Use Ctrl-D to exit.
Option[1 to 8]: 8
Do you wish to generate all certificates using configuration file : 
Option[Y/N] ? : y
  4. Enter the SSO account and password. NOTE: This can also be administrator@vsphere.local 
    Please provide valid SSO and VC privileged user credential to perform certificate operations.
Enter username [Administrator@vsphere.local]:administrator@vsphere.local
Enter password:
  5. Enter the appropriate information for the certificate. Please adjust values as needed. 
    Please configure certool.cfg with proper values before proceeding to next step.
  6. When asked to continue the operation type Y 
    Continue operation : Option[Y/N] ? : y
  7. Make sure you agree to reset/regenerate question. 
    You are going to reset by regenerating Root Certificate and replace all
certificates using VMCA
Continue operation : Option[Y/N] ? : y
  8. Now we want to present the script to the vCenter to get the details about your old SHA-1 certificate. The fastest way for me to do this was to create a .iso image of the script from VMware titled “vsphere8_upgrade_certificate_checks.py” Alternatively you can upload the file via other means. Upgrading vCenter Server or ESXi 8.0 fails during precheck due to a weak certificate signature algorithm.
  9. Allow the process to complete. NOTE: At this point your certificates have all been updated and you will get a new certificate when you refresh the browser.
  10. Now mount the .iso file to the VM within vCenter, copy it, and change directories to where it is located. 
    mount /dev/cdrom /mnt/cdrom/
cp /mnt/cdrom/vsphere8_upgrade_certificate_checks.py /tmp/
cd /tmp/
  11. Now we need to execute the script. 
    python /tmp/vsphere8_upgrade_certificate_checks.py
  12. In the output you will see some results with the vCenter and hosts that use the old SHA-1 certificates. In order to get these properly renewed we are forced to remove them from our configuration. 
    2025-08-14 14:59:14.803Z ERROR #################### Errors Found ####################
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR Support for certificates with weak signature 
algorithms has been removed in vSphere 8.0. Weak signature algorithm certificates 
must be replaced before upgrade. Refer to the vSphere release notes and VMware KB 
89424 for more details. Correct the following 3 issues before proceeding with 
upgrade.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 1. The certificate with subject ’/C=US/ST=CA/L=Palo 
Alto/OU=VMware/O=VMware/CN=VMware’ in VECS store TRUSTED_ROOTS has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Caution: Verify that 
any certificates signed by the problematic certificate are not in use by vCenter 
Server.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 2. Host hyp03.vsphere.local has a configured 
certificate authority (CA) with subject name 
‘/C=US/ST=CA/L=Palo Alto/OU=VMware/O=VMware/CN=VMware’ that has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Cleanup vCenter 
Server TRUSTED_ROOTS before explicitly removing certificates from the host.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 3. Host hyp02.vsphere.local has a configured 
certificate authority (CA) with subject name 
‘/C=US/ST=CA/L=Palo Alto/OU=VMware/O=VMware/CN=VMware’ that has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Cleanup vCenter 
Server TRUSTED_ROOTS before explicitly removing certificates from the host.
2025-08-14 14:59:14.804Z ERROR
2025-08-14 14:59:14.804Z ERROR #####################################################
  13. Copy off the Subject Key Identifier and remove all of the colons as this is the ID of the certificate we need to remove. Example: 
    AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ –> AABB11223344556677889900CCDDEEFFGGHHIIJJ
  14. Now we need to output this old certificate to a file: 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert get –id AABB11223344556677889900CCDDEEFFGGHHIIJJ –outcert /tmp/oldcert.cer

    NOTE: You can also provide the following variables if you would prefer, however this could leave your account and/or password stuck in the history of the vCenter appliance, which might go against policy.

    –login administrator@vsphere.local
–password ’P@SSW0rD’
  15. Un-publish the CA certificate from VMDIR, being sure to use any incremental file name if you have multiple SHA1 certificates to remove. IE: oldcert1.cer, oldcert2.cer, etc 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish –cert /tmp/oldcert.cer
  16. We now want to confirm the Certificate was un-published. 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert list
  17. Delete the certificate from VECS using the ID obtained earlier. Be sure to answer ‘Yʼ when asked “Do you wish to continue?” as the default answer is no. 
    /usr/lib/vmware-vmafd/bin/vecs-cli entry delete –store TRUSTED_ROOTS –alias AABB11223344556677889900CCDDEEFFGGHHIIJJ
  18. Refresh the certificates and display them to ensure they are no longer there. If you find Alias there that you did not expect then repeat the above steps. 
    /usr/lib/vmware-vmafd/bin/vecs-cli force-refresh
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store TRUSTED_ROOTS –text | grep Alias
  19. We will want to stop and start all VMware services, alternatively you can reboot the appliance. 
    service-control –stop –all
service-control –start –all
  20. Log back into vCenter and click on each hypervisor and go to ‘Configure’ tab and scroll down to ‘Certificate’ and click on ‘Refresh CA Certificates’. Optionally you can also click on the ‘Renew’ link at the top right if your host certs are close to expiring. Repeat for all hosts.
  21. Re-Run the python script to confirm the certificates have been renewed. 
    python /tmp/vsphere8_upgrade_certificate_checks.py
  22. Positive Results should be zero issues with a successful final line. 
    2025-08-14 15:09:33.680Z INFO Validation was successful.
  23. Negative Results will display an ‘errorʼ like this when you run the python script. If this happens then proceed to the next section and run the fixcerts_3_2.py script. 
    Enter hostname [Default: localhost]:
2025-09-16 09:27:18.517Z INFO Verifing vCenter Server VECS store: MACHINE_SSL_CERT
2025-09-16 09:27:18.556Z INFO Verifing vCenter Server VECS store: TRUSTED_ROOTS
2025-09-16 09:27:18.598Z INFO Verifing vCenter Server VECS store: TRUSTED_ROOT_CRLS
2025-09-16 09:27:18.636Z INFO Verifing vCenter Server VECS store: machine
2025-09-16 09:27:18.674Z INFO Verifing vCenter Server VECS store: vsphere-webclient
2025-09-16 09:27:18.711Z INFO Verifing vCenter Server VECS store: vpxd
2025-09-16 09:27:18.748Z INFO Verifing vCenter Server VECS store: vpxd-extension
2025-09-16 09:27:18.785Z INFO Verifing vCenter Server VECS store: hvc
2025-09-16 09:27:18.822Z INFO Verifing vCenter Server VECS store: data-encipherment
2025-09-16 09:27:18.859Z INFO Verifing vCenter Server VECS store: APPLMGMT_PASSWORD
2025-09-16 09:27:18.895Z INFO Verifing vCenter Server VECS store: wcp
2025-09-16 09:27:19.178Z INFO Loading certificate and key for user ’vpxd-extension’ from VECS
2025-09-16 09:27:19.182Z INFO Key saved in file: /tmp/tmptryb84a_
2025-09-16 09:27:19.182Z INFO Certificate saved in file: /tmp/tmpfchybsos
2025-09-16 09:27:19.235Z INFO Creating LookupService client with URL: https://vcenter.nuthouse.us:443/lookupservice/sdk
2025-09-16 09:27:19.242Z ERROR Failed to create LookupService stub
Traceback (most recent call last):
File ”/usr/lib/vmware-updatemgr/python/hcl/hardware_discovery/services/lookup_service.py”, line 35, in __init__
self.content = self._si.RetrieveServiceContent()
File ”/usr/lib/vmware/site-packages/pyVmomi/VmomiSupport.py”, line 595, in <lambda>
self.f(*(self.args + (obj,) + args), **kwargs)
File ”/usr/lib/vmware/site-packages/pyVmomi/VmomiSupport.py”, line 385, in _InvokeMethod
return self._stub.InvokeMethod(self, info, args)
File ”/usr/lib/vmware/site-packages/pyVmomi/SoapAdapter.py”, line 1525, in InvokeMethod
conn.request(’POST’, self.path, req, headers)
File ”/usr/lib/python3.7/http/client.py”, line 1281, in request
self._send_request(method, url, body, headers, encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1327, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1276, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1036, in _send_output
self.send(msg)
File ”/usr/lib/python3.7/http/client.py”, line 976, in send
self.connect()
and you will also see errors when trying to start services:
File ”/usr/lib/vmware/site-packages/pyVmomi/SoapAdapter.py”, line 1153, in connect
six.moves.http_client.HTTPSConnection.connect(self)
File ”/usr/lib/python3.7/http/client.py”, line 1451, in connect
server_hostname=server_hostname)
File ”/usr/lib/python3.7/ssl.py”, line 423, in wrap_socket
session=session
File ”/usr/lib/python3.7/ssl.py”, line 899, in _create
self.do_handshake()
File ”/usr/lib/python3.7/ssl.py”, line 1168, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for ’vcenter.nuthouse.us’. (_ssl.c:1076)
2025-09-16 09:27:19.250Z ERROR Caught exception: Failed to create LookupService stub with URL https://vcenter.nuthouse.us:443/lookupservice/sdk
Traceback (most recent call last):
File ”/usr/lib/vmware-updatemgr/python/hcl/hardware_discovery/services/lookup_service.py”, line 35, in __init__
self.content = self._si.RetrieveServiceContent()
File ”/usr/lib/vmware/site-packages/pyVmomi/VmomiSupport.py”, line 595, in <lambda>
self.f(*(self.args + (obj,) + args), **kwargs)
File ”/usr/lib/vmware/site-packages/pyVmomi/VmomiSupport.py”, line 385, in _InvokeMethod
return self._stub.InvokeMethod(self, info, args)
File ”/usr/lib/vmware/site-packages/pyVmomi/SoapAdapter.py”, line 1525, in InvokeMethod
conn.request(’POST’, self.path, req, headers)
File ”/usr/lib/python3.7/http/client.py”, line 1281, in request
self._send_request(method, url, body, headers, encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1327, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1276, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File ”/usr/lib/python3.7/http/client.py”, line 1036, in _send_output
self.send(msg)
File ”/usr/lib/python3.7/http/client.py”, line 976, in send
self.connect()
File ”/usr/lib/vmware/site-packages/pyVmomi/SoapAdapter.py”, line 1153, in connect
six.moves.http_client.HTTPSConnection.connect(self)
File ”/usr/lib/python3.7/http/client.py”, line 1451, in connect
server_hostname=server_hostname)
File ”/usr/lib/python3.7/ssl.py”, line 423, in wrap_socket
session=session
File ”/usr/lib/python3.7/ssl.py”, line 899, in _create
self.do_handshake()
File ”/usr/lib/python3.7/ssl.py”, line 1168, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for ’vcenter.nuthouse.us’. (_ssl.c:1076)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File ”/tmp/vsphere8_upgrade_certificate_checks.py”, line 641, in validate_all_esx_hosts
si = get_si(cert_store)
File ”/tmp/vsphere8_upgrade_certificate_checks.py”, line 316, in get_si
vcService = getVCServiceFromCertificate(cert_store)
File ”/usr/lib/vmware-updatemgr/python/hcl/hardware_discovery/services/vc_service.py”, line 103, in getVCServiceFromCertificate
ls_client = LookupService(ls_url)
File ”/usr/lib/vmware-updatemgr/python/hcl/hardware_discovery/services/lookup_service.py”, line 38, in __init__
raise LookupServiceError(”Failed to create LookupService stub with URL {}”.format(ls_url))
hardware_discovery.services.lookup_service.LookupServiceError: Failed to create LookupService stub with URL https://vcenter.nuthouse.us:443/lookupservice/sdk
2025-09-16 09:27:19.262Z INFO Deleting key file: /tmp/tmptryb84a_
2025-09-16 09:27:19.262Z INFO Deleting cert file: /tmp/tmpfchybsos

    and you will also see errors when trying to start services:

    service-control  –start –all
Operation not cancellable. Please wait for it to finish…
Performing start operation on service lwsmd…
Successfully started service lwsmd
Performing start operation on service vmafdd…
Successfully started service vmafdd
Performing start operation on service vmdird…
Successfully started service vmdird
Performing start operation on service vmcad…
Successfully started service vmcad
Performing start operation on profile: ALL…
Service-control failed. Error: Failed to start services in profile ALL. RC=4, stderr=Failed to start vpxd-svcs services. Error: A system error occurred. Check logs for details

Company CA root cert

If you company has its own CA but is unable to change it from an SHA1 to SHA2 root CA certificate then we will need to download and use the fixcerts script from VMware.

  1. Download the fixcerts_3_2.py from VMware. Replace certificates on vCenter server using the Fixcerts script and make an ISO out of it. I also have it attached (as an ISO) to this article.
  2. Mount the ISO to the vCenter VM.
  3. Log into the console of the vCenter, mount the CDRom, and copy the file over to the tmp directory. 
    mount /dev/cdrom /mnt/cdrom
cd /mnt/cdrom/fixcerts_3_2.py /tmp/
  4. Start the script. 
    python /tmp/fixcerts_3_2.py replace –certType all
  5. Read over the information and answer the question appropriately. 
    Please read above points and enter YES to proceed further [{Yes/yes/YES/Y/y}] ? y
  6. The tool will now get details of the existing root CA, once prompted you will need to answer the questions appropriately. 
    Do you want to proceed with the default values mentioned above ? please enter YES/NO [{Yes/yes/YES/Y/y} or {No/no/NO/N/n}] ? y
STS (Token Signing) Certificate is Valid for more than 1 YEAR (Till - DATE).  Do you really want to replace STS Certificate [Y/N] ? y
VMCA Root Certificate is valid for more than 1 YEAR (Till - DATE), Do you really want to replace Root Certificate [Y/N] ? y
  7. The process will then go through and update all of the certificates in vCenter with the updated certificate that is generated. When asked if you want to restart services, simply enter ‘y’ 
    Services needs to be restarted after cert replacement, please enter Yes to restart the services [{Yes/Y/y}] ? y
  8. Once it is done you should get the following statement. 
    Successfully Completed the Certificate Replacement -> Total Execution Time ## 333 seconds ##
  9. We have now replaced all certificates, however VMware does not automatically remove the old root CAs from inside the certificate store. Due to this we need to manually remove the old SHA1 signed certificate from the certificate store. Present the script “vsphere8_upgrade_certificate_checks.py” to the vCenter to get the details about the SHA1 certificate. The fastest way for me to do this was to create a .iso image of the script from VMware titled “vsphere8_upgrade_certificate_checks.py” Alternatively you can upload the file via other means. Upgrading vCenter Server or ESXi 8.0 fails during precheck due to a weak certificate signature algorithm The ISO file is attached to this article.
  10. Now mount the .iso file to the VM within vCenter, copy it, and change directories to where it is located.
  11. Now we need to execute the script.
  12. In the output you will see some results with the vCenter and hosts that use the old SHA-1 certificates. In order to get these properly renewed we are forced to remove them from our configuration. 
    2025-08-14 14:59:14.803Z ERROR #################### Errors Found ####################
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR Support for certificates with weak signature 
algorithms has been removed in vSphere 8.0. Weak signature algorithm certificates 
must be replaced before upgrade. Refer to the vSphere release notes and VMware KB 
89424 for more details. Correct the following 3 issues before proceeding with 
upgrade.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 1. The certificate with subject ’/C=US/ST=CA/L=Palo 
Alto/OU=VMware/O=VMware/CN=VMware’ in VECS store TRUSTED_ROOTS has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Caution: Verify that 
any certificates signed by the problematic certificate are not in use by vCenter 
Server.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 2. Host hyp03.vsphere.local has a configured 
certificate authority (CA) with subject name 
‘/C=US/ST=CA/L=Palo Alto/OU=VMware/O=VMware/CN=VMware’ that has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Cleanup vCenter 
Server TRUSTED_ROOTS before explicitly removing certificates from the host.
2025-08-14 14:59:14.803Z ERROR
2025-08-14 14:59:14.803Z ERROR 3. Host hyp02.vsphere.local has a configured 
certificate authority (CA) with subject name 
‘/C=US/ST=CA/L=Palo Alto/OU=VMware/O=VMware/CN=VMware’ that has weak signature 
algorithm sha1WithRSAEncryption. The certificate thumbprint is 
AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ. The certificate 
Subject Key Identifier is 
AC:AC:AC:AC:AC:AC:AC:AC:AC:AC:11:11:11:11:11:11:11:11:11:11. Cleanup vCenter 
Server TRUSTED_ROOTS before explicitly removing certificates from the host.
2025-08-14 14:59:14.804Z ERROR
2025-08-14 14:59:14.804Z ERROR #####################################################
  13. Copy off the Subject Key Identifier and remove all of the colons as this is the ID of the certificate we need to remove. Example: 
    AA:BB:11:22:33:44:55:66:77:88:99:00:CC:DD:EE:FF:GG:HH:II:JJ –> AABB11223344556677889900CCDDEEFFGGHHIIJJ
  14. Now we need to output this old certificate to a file: 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert get –id AABB11223344556677889900CCDDEEFFGGHHIIJJ –outcert /tmp/oldcert.cer

    NOTE: You can also provide the following variables if you would prefer, however this could leave your account and/or password stuck in the history of the vCenter appliance, which might go against policy.

    –login administrator@vsphere.local
–password ’P@SSW0rD’
  15. Un-publish the CA certificate from VMDIR, being sure to use any incremental file name if you have multiple SHA1 certificates to remove. IE: oldcert1.cer, oldcert2.cer, etc 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish –cert /tmp/oldcert.cer
  16. We now want to confirm the Certificate was un-published. 
    /usr/lib/vmware-vmafd/bin/dir-cli trustedcert list
  17. Delete the certificate from VECS using the ID obtained earlier. Be sure to answer ‘Yʼ when asked “Do you wish to continue?” as the default answer is no. 
    /usr/lib/vmware-vmafd/bin/vecs-cli entry delete –store TRUSTED_ROOTS –alias AABB11223344556677889900CCDDEEFFGGHHIIJJ
  18. Refresh the certificates and display them to ensure they are no longer there. If you find Alias there that you did not expect then repeat the above steps. 
    /usr/lib/vmware-vmafd/bin/vecs-cli force-refresh
/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store TRUSTED_ROOTS –text | grep Alias
  19. We will want to stop and start all VMware services, alternatively you can reboot the appliance. 
    service-control –stop –all
service-control –start –all
  20. Log back into vCenter and click on each hypervisor and go to ‘Configure’ tab and scroll down to ‘Certificate’ and click on ‘Refresh CA Certificates’. Optionally you can also click on the ‘Renew’ link at the top right if your host certs are close to expiring. Repeat for all hosts.
  21. Re-Run the python script to confirm the certificates have been renewed. 
    python /tmp/vsphere8_upgrade_certificate_checks.py
  22. Results should be zero issues with a successful final line. 
    2025-08-14 15:09:33.680Z INFO Validation was successful.
NSX for vSphere errors for large DB or diskspace usage »