.
Let’s be honest — that shiny self-signed certificate your Omnissa Connection Server came with is fine… until your browser or Horizon client starts screaming “Untrusted!” at every login. 😅
It’s time to fix that properly — by replacing it with a trusted certificate issued by your internal Microsoft CA.
In this guide, we’ll walk through the process step-by-step, ending up with a PFX certificate you can deploy to all your Connection Servers.
.
Why One Certificate for All Connection Servers?
Because simplicity is beautiful.
Maintaining a single certificate across all your Connection Servers reduces management overhead and avoids those awkward “name mismatch” warnings.
In the certificate, we’ll include all relevant hostnames as Subject Alternative Names (SANs):
• The hostname and FQDN of each Connection Server
• The VIP name (if you’re using a load balancer for internal access)
Example SAN list (2 Connection Servers and 1 VIP):
connection01.company.local
connection02.company.local
horizon-vip.company.local
connection01
connection02
horizon-vip
.
.
Step 1: Require the certificate as a PFX File
1. The certificate will be exported into a PFX file with:
◦ Exporting the private key
◦ Protect it with a strong password
◦ Save it somewhere safe (seriously, treat it like a password)
.
Step 2: Deploy the Certificate on All Connection Servers
Now that you have your shiny, trusted .pfx file, it’s time to put it to work.
Repeat the following steps on each Connection Server:
1.Open MMC → Certificates (Local Computer) again.
In Personal, there is a self-signed certificate (or an old certificate) installed by the Connection Server installation process
2. Import the .pfx file under:
Personal > Certificates
.
3. When prompted, provide the password you used during export and select “Mark this key as exportable….”
4. Verify that the certificate appears in the list with the private key (the certificate icon has a key)
5. Remove the friendly name VDM from the self-signed certificate or the old certificate
6.Add friendly name VDM to new certificate
.
.
Step 3: Restart the Horizon Connection Server Service
To make the change effective:
2 . Restart the VMware Horizon Connection Server service.
3 . Alternatively, you can simply reboot the server if you’re feeling extra cautious.
Once restarted, the Connection Server should automatically pick up the new certificate.
You can confirm by opening the Horizon Administrator Console in your browser and checking that your connection is now secure and trusted ✅
We need to repeat steps 4 and 5 on all Omnissa Connection servers
.
Bonus: Keeping Things Clean
• Make sure all old or expired certificates are removed from the Personal store.
• Keep a note of the certificate expiration date and plan your next renewal ahead of time (trust me, future-you will thank you).
• If the Horizon is behind the Unified Access Gateway (for external connection and network segmentation, remember to change the Thumbprint on the UAG configuration)
IMPORTANT: Once you’ve changed the certificate, always verify that it works. Especially if you have thin clients, make sure they have loaded the necessary certificates (RootCA and SubCA) to validate the new certificate.
.
Done!
You’ve successfully banished the self-signed gremlin and brought your Horizon environment into the trusted world of PKI.
From now on, your users will enjoy clean, warning-free connections — and your security team will silently thank you for doing things the right way.
.
