VMware Cloud Community
Box293
Enthusiast
Enthusiast

Having issues adding ESXi host to vCenter Server Appliance

I've been spending lots of time working on the new vCenter 5.1.0A.

I have two vCenter environments in my test and dev.

vCenter1 = Windows 2008 R2 vCenter server. It has local domain Microsoft CA self signed certificates as per following Derek Seamans blog http://derek858.blogspot.com.au/2012/09/vmware-vcenter-51-installation-part-1.html. I can add ESXi hosts to this vCenter no problems. These ESXi hosts have local domain Microsoft CA self signed certificates.

vCenter2 = VMware vCenter Server Appliance. It has local domain Microsoft CA self signed certificates as per following Doug Baer's blog http://www.goitpartners.com/blog/?p=662. I CANNOT add ESXi hosts to this vCenter when they have local domain Microsoft CA self signed certificates. I CAN add an ESXi host only if I have NOT done anything with the certificates.

The error I get is:

License not available to perform the operation.
License file download from blade001.xxx.yyy to vCenter Server failed due to exception: vim.fault.SSLVerifyFault.

I've attached the screenshot "unable to add host to ESXi - custom cert.png" that shows this.

When I add an ESXi host that has NOT had the certificate replaced, I get prompted that it is unable to verify the authenticity of the host and asks me to veryify the thumbprint. I click yes to verify and the host is added successfully.

I've attached the screenshot "Adding host blade002 with default cert.png" that shows this.

So this is really puzzling. When a host has a replaced certificate, the thumbpring MUST be verified by the vCenter Appliance because I DO NOT get prompted about the authenticity of the host.

Is anyone else experiencing this?

The one thing I really want to make clear is:

  • I can add the ESXi host with replaced certificates to a vCenter 5.1.0A server running on Windows 2008 R2 (vCenter1)
  • This then confirms with me that there is nothing wrong with the certificate on the ESXi host
  • I remove the host from vCenter1
  • I try and add the host to vCenter2 (Appliance) and I get the error, the host never gets added to vCenter
VCP3 & VCP4 32846 VSP4 VTSP4
25 Replies
robsh
Contributor
Contributor

After replacing default certs on VC appliance deploying vms from templates might fail with "Authenticity of the host's SSL certificate is not verified".

It might be because of mismatch between expected_ssl_thumbprint & host_ssl_thumbprint. For cloning with customization to work , please update expected_ssl_thumbprint with host_ssl_thumbprint value.

It can be achieved by running this query :

UPDATE VPX_HOST SET expected_ssl_thumbprint = host_ssl_thumbprint WHERE DNS_NAME = “esxi-50.abc.com”; >>> Whatever the host FQDN name is

0 Kudos
DougBaer
Commander
Commander

While not a pretty script, I hacked together the following PowerShell to address this issue on a larger scale. Be aware that it replaces the thumbprint value in vCenter with whatever the host reports.

Connect-VIServer YOUR_VCENTER

$hosts = Get-VMHost

$spec = New-Object VMware.Vim.HostConnectSpec

$spec.Force = $True

$rspec = New-Object VMware.Vim.HostSystemReconnectSpec

Foreach ($h in $hosts) {

      $hv = Get-View $h

      #Read the (POSSIBLY WRONG) thumbprint from the host object in vCenter

      $hostname = $h.name

      Write-Host "VC says $hostname - $($hv.Summary.Config.SslThumbprint)"

      #Get the current certificate from the host itself

      $wr = [Net.WebRequest]::Create("https://$hostname")

      #The request usually fails for one reason or another:

      # untrusted (self-signed) cert or untrusted root CA are most common...

      # we just want the cert info, so it usually doesn't matter

      try { $response = $wr.GetResponse() }

      catch{}

      $t = $wr.ServicePoint.Certificate.GetCertHashString()

      $spec.SslThumbprint = ([regex]::matches($t, '.{1,2}') | %{$_.value}) -join ':'

      #Reconnect the host to vCenter using the 'correct' thumbprint

      if($($spec.SslThumbprint) -ne $($hv.Summary.Config.SslThumbprint)) {

           Write-Host "... correct host thumbprint is $($spec.SslThumbprint)"

           $hv.ReconnectHost($spec,$rspec)

      } else {

        Write-Host " ... host agrees"

      }

}

Disconnect-VIServer -confirm:$false


I hope this helps... I usually run it after I replace a batch of self-signed certificates on hosts with CA-signed certificates.


-Doug

Doug Baer, Solution Architect, Advanced Services, Broadcom | VCDX #019, vExpert 2012-23
csdibiase
Enthusiast
Enthusiast

In my case what I found was that the expected_ssl_thumbprint field was empty, probably because I had done a remove/readd and disconnect/reconnect cycle on the impacted host to resolve the issue.

To address I connected to my VCSA over SSH and did the following:

# service vmware-vpxd stop

# /opt/vmware/vpostgres/1.0/bin/psql VCDB -U vc

VCDB=> select id,dns_name,expected_ssl_thumbprint,host_ssl_thumbprint from vpx_host

VCDB=> \g

  id  |          dns_name           |                   expected_ssl_thumbprint                   |                     host_ssl_thumbprint                    

------+-----------------------------+-------------------------------------------------------------+-------------------------------------------------------------

5242 | host03.demo.local |                                                             | 75:67:0F:9D:45:F6:AB:AA:83:02:66:4D:46:53:F0:82:1E:80:32:DB

VCDB=> update vpx_host set expected_ssl_thumbprint = host_ssl_thumbprint where dns_name = 'host03.demo.local'

VCDB=> \g

VCDB=> select id,dns_name,expected_ssl_thumbprint,host_ssl_thumbprint from vpx_host

VCDB=> \g

  id  |          dns_name           |                   expected_ssl_thumbprint                   |                     host_ssl_thumbprint                    

------+-----------------------------+-------------------------------------------------------------+-------------------------------------------------------------

5242 | host03.demo.local | 75:67:0F:9D:45:F6:AB:AA:83:02:66:4D:46:53:F0:82:1E:80:32:DB | 75:67:0F:9D:45:F6:AB:AA:83:02:66:4D:46:53:F0:82:1E:80:32:DB

VCDB=> \q

# service vmware-vpxd start

0 Kudos
kasaj
Enthusiast
Enthusiast

Hi,

This is an old post, but since it's unanswered, and I had the same issue, I'm posting my solution:

We were adding a newly installed ESXi 5.1 host to vCenter 5.1 and failed with error:

License file download from xxxxx to vCenter Server failed due to exception: vim.fault.SSLVerifyFault.

The host would successfully join vCenter using IP address, but not hostname.

After a little head scratching, we noticed that the IP address of this host was previously used by an old vCenter.

All we had to do was log into vCenter 5.1 (windows) and ipconfig /flushdns

That solved the issue.

Hope it helps.

</BR>

0 Kudos
Veers
Contributor
Contributor

I bumb in the same kind of error with VCSA 6. After a fresh install and a change of certificate, I can't create a cluster or add a host, I get a SSL error about licensing.

I figure a simple workaround if you are already install a CA signed certificate.

In VCSA 6, ou can use this command to change a certificate:

/usr/lib/vmware-vmca/bin/certificate-manager

For change the SSL certificate for the web client, you use option 1 (and broke adding hosts...).

So, if you rerun the command, you can see option 8: Reset all Certificates

If you use it, reboot, you will be able to add hosts (and a cluster)

So, add your hosts and rechange the certificate for the signed one once this is done.

The bad thing is that you have to do it each time you want to add a cluster or a host... Or even change cluster setting...

0 Kudos
linkages
Contributor
Contributor

I ran into a similar issue with VCSA 6 and using custom certificates. The problem turns out to be that the certificate authority ( CA ) that I am using is signed by another intermediate authority which is also signed by another authority. What happens is when the trusted certificate chain is pushed to the ESXi server, it was only giving it the CA that signed the certificate and not the whole chain. Unfortunately fixing this requires using more than the certificate-manager tool. I had to import both the intermediate and root certificate into the VECS on the VCSA using the following command:

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert publish --cert <path to cert>


Where the <path to cert> is a path to the intermediate and root CA certificates. In my example, I am using InCommon RSA CA. InCommon RSA CA is signed by UserTrust. UserTrust is then signed by AddTrust. I had to go out and get the public certificates to the InCommon RSA CA, UserTrust, and AddTrust CAs. I put each of those certificates in a different file and then imported them one by one. I did not import the InCommon RSA CA since that will be imported by certificate-manager during the import of the custom certificate. Once the intermediate and root CA certificates were in VECS, I then followed the directions here:


Replacing vCenter 6.0’s SSL Certificate - VMware Blogs


To replace the machine certificates.

0 Kudos