VMware Cloud Community
PKaufmann
Enthusiast
Enthusiast

SSL Verification Problem

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?

Reply
0 Kudos
5 Replies
esiebert7625
Immortal
Immortal

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

Reply
0 Kudos
PKaufmann
Enthusiast
Enthusiast

Thanks, I will try that and come back to you ...

Reply
0 Kudos
Ross_Walter
Contributor
Contributor

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:

Initializing SSL context

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

Logged in!

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.

Reply
0 Kudos
levinest
Contributor
Contributor

I'm having exactly the same problem. Anyone?

Reply
0 Kudos
Ross_Walter
Contributor
Contributor

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.

Reply
0 Kudos