I've run into many vcenter/VMware product certificate replacement issues over the years, so I'm sure I've seen various permutations of this same error with different causes. None of the fixes out there, including the one in this thread, addressed the issue I've been dealing with for the past couple of days, so I'm putting what I found in this thread in case it helps someone else.
I am hitting this issue on a vCenter v6.7 server. Some of the registered services show v6.5.0, but the server version is v6.7. This appears to be normal.
In the cert replacement log (/var/log/vmware/vmcad/certificate-manager.log) I saw the following error, essentially exactly the same series of messages as appears in the OP's post. Note the 'ID' of the service that is failing the reregister.
2022-02-07T15:18:55.671Z INFO certificate-manager lstool command currently being executed is : ['/usr/java/jre-vmware/bin/java', '-Djava.security.properties=/etc/vmware/java/vmware-override-java.security', '-cp', '/usr/lib/vmidentity/tools/lib/lookup-client.jar:/usr/lib/vmidentity/tools/lib/*', '-Dlog4j.configuration=tool-log4j.properties', 'com.vmware.vim.lookup.client.tool.LsTool', 'reregister55', '--no-check-cert', '--url', 'https://<VCENTER_FQDN>/lookupservice/sdk', '--id', 'local:7', '--spec', '/tmp/svcspec_9f34k7xn', '--user', '<SSO_ADMIN>', '--password', '*****']
2022-02-07T15:18:58.6Z ERROR certificate-manager 'lstool reregister' failed: 1
2022-02-07T15:18:58.6Z ERROR certificate-manager Error while replacing Machine SSL Cert, please see /var/log/vmware/vmcad/certificate-manager.log for more information.
2022-02-07T15:18:58.6Z ERROR certificate-manager 'lstool reregister' failed: 1
2022-02-07T15:18:58.6Z INFO certificate-manager Performing rollback of Machine SSL Cert...
Unfortunately, certificate-manager.log isn't capturing the output of the commands it's running. However, you can take the command that appears here and convert all of the delimiters (', ') to spaces to get a command that you can run yourself. When the tool fails, the "spec" that is created is not deleted, so the "spec" file should still be in /tmp/, allowing you to try the command again and view its output. For example:
/usr/java/jre-vmware/bin/java -Djava.security.properties=/etc/vmware/java/vmware-override-java.security -cp /usr/lib/vmidentity/tools/lib/lookup-client.jar:/usr/lib/vmidentity/tools/lib/* -Dlog4j.configuration=tool-log4j.properties com.vmware.vim.lookup.client.tool.LsTool reregister55 --no-check-cert --url https://<VCENTER_FQDN>/lookupservice/sdk --id local:7 --spec /tmp/svcspec_9f34k7xn --user <SSO_ADMIN> --password <PASSWORD>
When executing this command, I'd get a bunch of output, including an error message at the end:
(lookup.fault.ServiceFault) {
faultCause = null,
faultMessage = null,
errorMessage = Already exists
}
This was actually vaguely useful, unlike the output in certificate-manager.log and made me interested to check the registered services on my vcenter. You can do that with the commands in this KB: Process to view the List of Services Registered with Single Sign-On (2043509)
On vcenter 6.7, for example, you can view the services registered with SSO with this command, on the local shell:
python /usr/lib/vmidentity/tools/scripts/lstool.py list --url http://localhost:7080/lookupservice/sdk | less
In the output of "lstool.py list", I searched for "local:7". I could see that it appeared to be "Service Type: vsphereclient". I searched the rest of the output for another service with type "vsphereclient" and found there were two services with this type:
-------------------------------------------------------
Name: cis.vsphere-client.ServiceName
Description: cis.vsphere-client.ServiceDescription
Service Product: com.vmware.cis
Service Type: vsphereclient
Service ID: local:7
Site ID: local
Owner ID: vsphere-client-<VCENTER_NAME>-df9ecf85-3cae-4744-8505-2c4783ab2cc1@vsphere.local
Version: 6.5.0
-------------------------------------------------------
Name: cis.vsphere-client.ServiceName
Description: cis.vsphere-client.ServiceDescription
Service Product: com.vmware.cis
Service Type: vsphereclient
Service ID: de1da181-6a32-4841-a406-d230f61e86e7
Site ID: local
Node ID: b4e06b6d-f5b6-41b1-adf4-f37d0bf20d5a
Owner ID: vsphere-webclient-b4e06b6d-f5b6-41b1-adf4-f37d0bf20d5a@vsphere.local
Version: 6.5.0
Note that the failing "local:7" service has no "Node ID", and the "Service ID" is not a GUID, unlike all of the other services. Referencing another vcenter in my environment, I found that there should only be one service with type "vsphereclient", the service should likely have a "Node ID" listed, and the "Service ID" should likely be a GUID.
I unregistered the "bad", duplicate "local:7" vsphereclient service using this command:
python /usr/lib/vmidentity/tools/scripts/lstool.py unregister --url https://<VCENTER_FQDN>/lookupservice/sdk --id local:7 --user <SSO_ADMIN> --password <PASSWORD> --no-check-cert
I verified it was gone using the above "lstool.py list" command; I now have only one service with type "vsphereclient". After unregistering the duplicate service, I was able to successfully replace the certificate.