Hi guys,
I have some error message in the vmcenter server log:
SSLVerifyIsEnabled: failed to read registry value. Assuming verification is disabled
SSLVerifyCertAgainstSystemStore: Certificate verification is disabled, so connection will proceed despite the error
SSLVerifyCertAgainstSystemStore: Subject mismatch: rz2esxlan003 vs rz2esx03
SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
\* The host name used for the connection does not match the subject name on the host certificate
\* A certificate in the host´s chain is based on an untrusted root..
I think this is because I changed the name of the esx server (old name: rz2esxlan003, new name: rz2esx03) ..
Is there a possibility to resolve this problem?
You might try the procedure documented in the below post...
How to regenerate SSL certificates in ESX 3 - http://www.vmware.com/community/thread.jspa?messageID=614861
Thanks, I will try that and come back to you ...
hi!
The suggested fix for this issue in the link above did not resolve this for me when using the VMware Converter v3.0.3 - I am still getting the above error. The full details of the error in the vmware-client.log file on my PC (where the VMware Converter is installed) are as follows:
SSLVerifyCertAgainstSystemStore: Subject mismatch: VMware vs pbnevipvc4031.xxx.xxx
SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
The host name used for the connection does not match the subject name on the host certificate
A certificate in the host's chain is based on an untrusted root.
SSLVerifyCertAgainstSystemStore: Certificate verification is disabled, so connection will proceed despite the error
Local and remote namespace are the same
Connecting to host pbnevipvc4031.xxx.xxx on port 443 using protocol https
SSLVerifyCertAgainstSystemStore: Subject mismatch: VMware vs pbnevipvc4031.xxx.xxx
SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
The host name used for the connection does not match the subject name on the host certificate
A certificate in the host's chain is based on an untrusted root.
SSLVerifyCertAgainstSystemStore: Certificate verification is disabled, so connection will proceed despite the error
Authenticating user int\a312302
SSLVerifyCertAgainstSystemStore: Subject mismatch: VMware vs pbnevipvc4031.xxx.xxx
SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
The host name used for the connection does not match the subject name on the host certificate
A certificate in the host's chain is based on an untrusted root.
SSLVerifyCertAgainstSystemStore: Certificate verification is disabled, so connection will proceed despite the error
Task failed: at line number 14, not well-formed (invalid token)
Transition from InProgress to Failure requested
Has anyone seen and resolved this SSL issue another way please? (or any other information that can help to resolve this please?!)
thanks,
Ross.
I'm having exactly the same problem. Anyone?
hi all!
a bit of an update... we haven't fixed the problem, but we have a workaround which enables us to get Converter working:
We have a Production firewall in place to prevent unauthorised access to the ESX consoles, except to the platform admins such as myself, and something appears to have changed on the network which is preventing SSL or certificates from working.
Anyway, the workaround is to create a temporary second service console on the destination ESX host server, using one of the vmnic adapters from the VM port group! it's sneaky as it gets around the firewall rules, but it works!
To do this:
1) remove one vmnic from the VM data port groups (they should be dual connections, shouldn't they?!),
2) Create a new service console port group using the now available vmnic,
3) configure the new service console port group with a temporary IP address that's on the VM data network - ie one of the port group VLANs and save this configuration,
4) Edit the new service console port group to change the gateway to be the same as the temporary 2nd service console IP address,
There is some degree of danger to the above - if you don't wait for the previous change to be saved, the host can drop out of VirtualCenter and you'll have to manually reconfigure the vmnics back to the original configuration via Putty/SSH to the host console.
To revert it back, just delete the new service console port group and attach this vmnic back to the original port group.
good luck!
Ross.