Replace the Omnissa Horizon Connection Server Certificate

Horizon Connection Server selects its TLS certificate from the Local Computer Personal store by the friendly name vdm. It reads that selection when the Connection Server service starts.

The product is now Omnissa Horizon (formerly VMware Horizon), and its documentation lives on Omnissa's site. The vdm procedure below is the same under either name; aethercert's deploy-target picker still lists it as VMware Horizon.

Before you beginCopy Anchor Link

Omnissa's requirements for the certificate:

• Server Authentication in the Enhanced Key Usage, and Digital Signature and Key Encipherment in the Key Usage,
• a CN or SAN matching the Connection Server's FQDN or the configured external URL - include the load-balanced name and each server's own name,
• a chain of trust that ends in the server's Trusted Root Certification Authorities store,
• a private key that is exportable.

You can use one certificate with all names on every Connection Server, or one per server. List every Connection Server in the pod (the group of replicated Connection Servers) and check every Unified Access Gateway (UAG): in the UAG admin console, under Edge Service Settings > Horizon Settings, a value in Proxy Destination URL Thumbprints means the UAG pins the Connection Server's certificate and must be updated.

Step-by-step certificate replacementCopy Anchor Link

1. Take one Connection Server out of the load balancer. Sessions whose connection is tunneled through this server are interrupted when its service restarts; desktops that clients reach directly keep running. Change servers in a quiet period, and let users reconnect through the other server.

2. Import the PFX into Certificates (Local Computer) > Personal > Certificates. In the import wizard, select Mark this key as exportable.

3. Import new intermediate certificates into Intermediate Certification Authorities > Certificates, and the root into Trusted Root Certification Authorities if it is not already there.

4. Move the friendly name:

   • On the old certificate: Properties > General, clear the Friendly name vdm, Apply.
   • On the new certificate: set the Friendly name to exactly vdm, Apply.
   • Check that no other certificate in Personal > Certificates is named vdm. A certificate named vdm.ec may exist - leave it alone (see below).

5. Restart the Connection Server service so it reads the new selection:

   Copy Text

   Restart-Service wsbroker -Force

   In services.msc it is listed as Omnissa Horizon Connection Server (older versions: VMware Horizon View Connection Server).

6. Verify the server (below), put it back into the load balancer, and repeat on every Connection Server in the pod.

7. If a UAG pins the thumbprint (see Before you begin), replace it in Proxy Destination URL Thumbprints with the new certificate's thumbprint.

Product-specific considerationsCopy Anchor Link

The client-facing vdm certificate is not the vdm.ec certificate. Horizon creates vdm.ec itself for internal purposes such as the Enrollment Server used by True SSO (single sign-on with certificates). Renaming or removing it breaks those functions, so never touch it when moving the vdm name.

If Horizon still presents the old certificate after the restart, check that exactly one certificate is named vdm, that it has a private key, that the chain is complete, and that the service actually restarted.

Verify the new certificateCopy Anchor Link

openssl s_client -connect cs01.example.com:443 -servername cs01.example.com -showcerts </dev/null

Check subject and SAN, issuer, expiry date and the chain. Open Horizon Console against the server and the load-balanced URL - the dashboard shows the Connection Server's status - then launch a desktop with Horizon Client and through HTML Access, and check UAG health.

RollbackCopy Anchor Link

Do not delete the old certificate until the new one is verified. To go back, set the friendly name vdm on the old certificate again, clear it on the new one, restart wsbroker, and run the checks above before putting the server back into service.

Common problemsCopy Anchor Link

• More than one certificate has the friendly name vdm.
• The private key was not marked exportable on import.
• The new certificate is missing its private key or an intermediate.
• vdm.ec was renamed by mistake.
• A UAG still pins the old backend thumbprint.
• Only one Connection Server of the pod was updated.

Automating certificate replacement with aethercertCopy Anchor Link

The aethercert Horizon target imports the certificate with friendly name vdm and restarts the local wsbroker service. Deploy it to each Connection Server separately.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

SourcesCopy Anchor Link

• Omnissa: update the certificates on a Connection Server instance
• Omnissa: configure Connection Server to use a new TLS certificate
• Omnissa: modify the certificate friendly name
• Omnissa: troubleshooting certificate issues on Connection Server