VMware Cloud Community
nas061000
Contributor
Contributor
Jump to solution

The host name used for the connection does not match the subject name on the host certificate

SSLVerifyCertAgainstSystemStore: Subject mismatch: VMware vs 10.110.97.13

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

Failed to send request. Retrying. Error: class Vmacore::Ssl::SSLException(SSL Exception: error:00000001:lib(0):func(0):reason(1))

SSLVerifyCertAgainstSystemStore: Subject mismatch: VMware vs 10.110.97.13

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

This is an error I am recieving on several VC's that we run. Each VC has several ESX hosts hooked up to it, and this is clogging our error logs, how can this be resolved.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Craig_Baltzer
Expert
Expert
Jump to solution

This basically means that the self-signed SSL certificate created by the ESX host during its installation isn't 100% "correct" as far as the VC server is concerned...

  • The "host name used for the connection..." error usually means that you named the server one way on installation and either renamed it or have another name for it in VC (i.e. the name used when you created the ESX host was "esx-1.company.com" and you've subsequently created a DNS record for it as "production.company.com" and have VC conencting to it as "production.company.com")

  • The "A certificate in the host's chain..." errror means that the self signed cert generated by the ESX server isn't trusted by the VC server. This will always happen unless you do something specific to trust the self-signed cert

The "host name used for the connection..." issue is a matter of getting the name you're using to connect to the host to match the certificate on ESX. You can see the actual name in the ESX server certificate by going to https://esxervername from a web browser and then looking at the certificate that's presented once the web page is displayed (i.e. in IE7 click on the toolbar where it has the red X shield and says "Certificate Error", or in Firefox 3 you'll see a page displayed that says "The certificate is only valid for ..." and will show the server name in the cert. You can either change the DNS name you use to access the ESX box to match that in the cert, or you can regenerate the cert on the ESX box to match the DNS name you want to use (see doc link below on how to regenerate the SSL cert).

The untrusted root issue has a few possible solutions, all of which involve generating a new SSL certificate request on your ESX hosts. Once you've done that you can:

  • If you have an internal PKI already setup which is trusted by your VC server then submit the certificate requests to the internal CA

  • If you don't have an internal PKI then submit the certificate requests to a trusted 3rd party CA such as Verisign, Entrust, etc.

Once you get the certificate back from the CA then install it on each of the ESX boxes.

gives a good rundown on all of this in a lot more detail on how to regenerate certs, etc.

View solution in original post

0 Kudos
4 Replies
pomiwi
Enthusiast
Enthusiast
Jump to solution

We have the same error however I dont see any problems as a result of it... must be something to do with the host name slightly changing (FQDN?? maybe) after the install? I guess you could regenerate your certificates however I would only do that if you are seeing issues.

0 Kudos
Craig_Baltzer
Expert
Expert
Jump to solution

This basically means that the self-signed SSL certificate created by the ESX host during its installation isn't 100% "correct" as far as the VC server is concerned...

  • The "host name used for the connection..." error usually means that you named the server one way on installation and either renamed it or have another name for it in VC (i.e. the name used when you created the ESX host was "esx-1.company.com" and you've subsequently created a DNS record for it as "production.company.com" and have VC conencting to it as "production.company.com")

  • The "A certificate in the host's chain..." errror means that the self signed cert generated by the ESX server isn't trusted by the VC server. This will always happen unless you do something specific to trust the self-signed cert

The "host name used for the connection..." issue is a matter of getting the name you're using to connect to the host to match the certificate on ESX. You can see the actual name in the ESX server certificate by going to https://esxervername from a web browser and then looking at the certificate that's presented once the web page is displayed (i.e. in IE7 click on the toolbar where it has the red X shield and says "Certificate Error", or in Firefox 3 you'll see a page displayed that says "The certificate is only valid for ..." and will show the server name in the cert. You can either change the DNS name you use to access the ESX box to match that in the cert, or you can regenerate the cert on the ESX box to match the DNS name you want to use (see doc link below on how to regenerate the SSL cert).

The untrusted root issue has a few possible solutions, all of which involve generating a new SSL certificate request on your ESX hosts. Once you've done that you can:

  • If you have an internal PKI already setup which is trusted by your VC server then submit the certificate requests to the internal CA

  • If you don't have an internal PKI then submit the certificate requests to a trusted 3rd party CA such as Verisign, Entrust, etc.

Once you get the certificate back from the CA then install it on each of the ESX boxes.

gives a good rundown on all of this in a lot more detail on how to regenerate certs, etc.

0 Kudos
nas061000
Contributor
Contributor
Jump to solution

So the problem lies within each individual host I have connected to the VC, not the certs on VC itself?

0 Kudos
Craig_Baltzer
Expert
Expert
Jump to solution

Correct. The error in the VC logs is VC complaining that it doesn't like the certificate it received from the ESX host(s) when it tried to connect.

The certificate warning you get when you try to connect to VC from your workstation using the VI Client is being caused by the cert on VC itself.