Horizon can't connect to vCenter after a certificate renewal? Fix the stored certificate in ADAM

Horizon can’t connect to vCenter after a certificate renewal? Fix the stored certificate in ADAM

If Horizon says „Unable to establish a connection to the vCenter Server“ right after you renewed the vCenter certificate, and it never asks you to accept the new one, the Connection Server is still pinned to the old certificate. Here’s the fix, with a real example: vCenter 7.0.3 with VMCA certificates and Omnissa Horizon 8 (Connection Server 8.18).

Why bother?

The vCenter Machine SSL certificate issued by VMCA is valid for 2 years. When it expires, or when you renew it, Horizon can’t talk to vCenter anymore. Users can still log in to desktops that are already running, but provisioning and power operations stop. With instant clones every logoff ends with Resync operation failed, and the pool slowly drains.

Normally you just edit the vCenter in Horizon Console and accept the new certificate. In my case the accept dialog never showed up.

What you’ll need

SSH access to the VCSA as root.
Admin access to Horizon Console and RDP to the Connection Server.
A fresh Connection Server backup (Settings → Servers → Connection Servers → Backup Now).

Step 1: Renew the Machine SSL certificate

In vSphere Client go to Administration → Certificates → Certificate Management → Machine SSL Certificate → Actions → Renew and keep 730 days. vCenter restarts its services, which takes about 10–15 minutes.

Heads up: check the STS signing and solution user certificates too. If STS expires, nobody can log in to vCenter at all, and Renew on Machine SSL won’t fix that.

Check the new certificate on the VCSA:

openssl x509 -in <(/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store MACHINE_SSL_CERT --alias __MACHINE_CERT) -noout -fingerprint -sha1 -enddate

Write down the SHA-1 fingerprint, you’ll need it in Step 5.

Step 2: Try to accept the certificate in Horizon

In Horizon Console go to Settings → Servers → vCenter Servers, select the vCenter, click Edit and then OK. Normally an „Invalid Certificate Detected“ dialog appears, and you click Accept. Done.

In my case it didn’t. I only got „Unable to establish a connection to the vCenter Server“, and after a Connection Server service restart the whole vCenter Servers tab failed with „An internal server error occurred“.

Step 3: Find the real error in the Connection Server log

Watch out: on Omnissa builds the logs are no longer in C:\ProgramData\VMware\VDM\logs. The old folder may still be there after an upgrade, but nothing new gets written to it. The current path is C:\ProgramData\Omnissa\Horizon\logs.

$log = (Get-ChildItem C:\ProgramData\Omnissa\Horizon\logs\debug-*.txt | Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName
Get-Content $log -Tail 5000 | Select-String "thumbprint|VirtualCenter|Exception" | Select-Object -Last 30 | ForEach-Object { $_.Line }

The log made it clear:

[CertMatchingTrustManager] invalid certificate (doesn't match trusted thumbprint) for vcsa.example.local:443
Caused by: com.omnissa.vdi.ssl.MismatchedThumbprintException: InvalidCertificateException[reasons:notTrusted;cantCheckRevoked;chainReasons:partialChain, noTrust]

The Connection Server doesn’t trust the VMCA root, so it compares the certificate with the copy it has stored. They don’t match, and the TLS handshake fails before the console ever gets to the accept dialog.

Step 4: Find the vCenter object in ADAM

Horizon keeps the trusted vCenter certificate in its ADAM database (DC=vdi,DC=vmware,DC=int). The GUID of the vCenter object is in the log (VirtualCenterDriver-<GUID>). OU=Properties has thousands of objects, so PowerShell is faster than clicking through ADSI Edit:

$r=[ADSI]"LDAP://localhost:389/DC=vdi,DC=vmware,DC=int"
$o=(New-Object DirectoryServices.DirectorySearcher($r,"(cn=<GUID>)")).FindOne(); $o.Path
$o.Properties.PropertyNames | ? { $_ -match 'thumb|url|cert' } | % { "$_ = $($o.Properties[$_])" }

This was the surprise: pae-VCSSLCertThumbprint doesn’t hold a hash. With pae-VCSSLCertThumbprintAlgorithm = DER_BASE64_PEM it holds the whole old certificate in PEM.

Step 5: Write the new certificate

The script backs up the old value to the desktop and pulls the certificate from vCenter. It writes it only if the SHA-1 matches the one from Step 1:

$e=[ADSI]"LDAP://localhost:389/CN=<GUID>,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int"
$old=[string]$e.Properties['pae-VCSSLCertThumbprint'].Value
$old | Out-File "$env:USERPROFILE\Desktop\vc-cert-backup.txt"
$nl= if($old -match "`r`n"){"`r`n"}else{"`n"}; $end= if($old.EndsWith("`n")){$nl}else{""}

$h='vcsa.example.local'; $t=New-Object Net.Sockets.TcpClient($h,443)
$s=New-Object Net.Security.SslStream($t.GetStream(),$false,{$true})
$s.AuthenticateAsClient($h,$null,[Security.Authentication.SslProtocols]::Tls12,$false)
$c=New-Object Security.Cryptography.X509Certificates.X509Certificate2($s.RemoteCertificate); $t.Close()
if($c.Thumbprint -ne '<SHA1_WITHOUT_COLONS>'){ throw "Thumbprint mismatch" }

$b64=([Convert]::ToBase64String($c.RawData) -replace '(.{64})',"`$1$nl").TrimEnd()
$e.Put('pae-VCSSLCertThumbprint',"-----BEGIN CERTIFICATE-----$nl$b64$nl-----END CERTIFICATE-----$end"); $e.SetInfo()

Heads up: Windows PowerShell 5 tries TLS 1.0 by default and fails with „A call to SSPI failed“, because vCenter 7 only allows TLS 1.2. That’s why Tls12 is set explicitly.

Step 6: Restart the Connection Server service and clean up

Restart the Connection Server service and wait 2–3 minutes. The vCenter Servers tab loads again and System Health turns green.

Careful: with Secure Tunnel enabled, the restart drops every active session. With a single Connection Server, do it after hours.

Machines stuck in Problem Machines (for me an instant clone with Resync operation failed) go to Inventory → Machines → More Commands → Recover. If that doesn’t help, Remove them and the pool rebuilds them.

Common issues

Still no accept dialog in Horizon? That’s expected here. The dialog only appears when the connection gets as far as the certificate check. With a mismatched thumbprint it fails earlier.

Can’t find debug.txt? It doesn’t exist. The current log is the newest debug-<date>.txt in C:\ProgramData\Omnissa\Horizon\logs.

Want to avoid this next time? Import the VMCA root into Local Computer → Trusted Root Certification Authorities on every Connection Server. Download it from the vCenter landing page → Download trusted root CA certificates, certs\win folder. Also hook the vCenter certificate expiration alarm to email, so the next renewal isn’t a last-minute job.

(Visited 31 times, 1 visits today)