Let’s be honest: certificates are not the most exciting thing in IT. They don’t sparkle, they don’t blink, and they rarely impress your CIO in a slide deck. But if you’re running an Omnissa Horizon environment (also with Omnissa Access integration), SSL certificates are the unsung heroes that make your infrastructure secure, trusted, and usable.
In this post, let’s break down why certificates matter, where they should live in your Horizon world, and how they unlock some pretty cool features like True SSO.
.
.
The Basics: Why SSL Certificates?
At their core, SSL/TLS certificates do three things:
1.Encrypt traffic – so that nobody can sniff your users’ RDP or Blast traffic.
2.Prove identity – so your clients know they’re talking to the real Horizon server, not some sneaky impostor.
3.Build trust – because “untrusted certificate” pop-ups are the fastest way to kill user confidence.
In Horizon, these are not “nice to haves”—they’re essential.
.
Public vs Internal CA: Which Flavor Do You Need?
In most deployments, you’ll be juggling two kinds of certificates:
•Public CA Certificates: Perfect for components exposed to the internet—like your Unified Access Gateways (UAGs). Public certs ensure that external clients (home users, contractors, BYOD devices) connect without scary warnings.
•Internal Microsoft CA Certificates: Handy for internal components—like Connection Servers—especially if all your clients are domain-joined and trust your Microsoft enterprise CA. They’re cheaper (sometimes free) and give you tighter control.
Pro tip: You don’t have to pick one or the other. Most production environments mix both.
.
Certificates in the Horizon Architecture (The Big Picture)
.
.
Think of the certificates as passports:
•The UAG needs a passport recognized globally (public CA).
•The Connection Servers can survive with a local passport (internal CA).
•True SSO hands out temporary passports at the border (short-lived certs) so users don’t need to fumble with passwords.
.
Certificates on Connection Servers
Your Horizon Connection Servers are the brains of the operation. By default, they come with a self-signed certificate. That’s fine for a lab, but in production it’s a recipe for distrust and compatibility issues.
means your Horizon Clients and web browsers connect seamlessly and securely. Bonus: no frantic helpdesk calls about “why does Horizon keep saying untrusted connection?”
The UAG is your secure doorway to Horizon from the outside world (more time behind a load balancer). And here, public CA certs are king. Imagine asking a remote contractor to install your company’s internal root CA certificate just to connect—that’s not going to fly.
With a trusted public certificate:
•Users get smooth experience from the get-go.
•Browsers, Horizon Clients, and even thin clients connect without any fuss.
•You avoid troubleshooting nightmares tied to certificate trust chains.
Now, let’s talk about one of Horizon’s coolest features: True SSO.
True SSO lets users log into Horizon desktops and apps with their identity from Omnissa Access—no extra password prompts or integrate with other SAML idP. Behind the scenes, Horizon uses short-lived, smart card-like certificates to authenticate the user to the desktop.
Guess what makes this magic possible? Certificates.
•A trusted internal CA (usually Microsoft AD CS) issues these ephemeral certificates.
•The Horizon infrastructure validates them and grants access seamlessly.
•The user just experiences fast, passwordless login.
So, without properly set up certificates, True SSO doesn’t fly.
Here are more details on how to install the certificates (coming soon)
.
.
Wrapping It Up
Certificates might not be glamorous, but in an Omnissa Horizon + Omnissa Access environment they are foundational:
•They secure Connection Servers for internal trust.
•They harden UAGs with public-facing credibility.
•They power True SSO, giving users a smooth, passwordless experience.
Think of them as the quiet guardians of your virtual desktops: invisible when done right, but disastrous if ignored.
So next time you see a certificate renewal reminder, don’t sigh. Smile. Because your Horizon users—and your future self—will thank you.
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:
1. Open Services.msc
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 ThingsClean
•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.
So you’ve installed Horizon (2503is last version) and got your Event Database humming along on a shiny SQL Server. But hold on a sec — did you remember to lock down that traffic with TLS encryption? Or are you letting your eventlogsfloat around in plain text like it’s still 1999?
Let’s fix that.
Here’s how to set up SSL/TLS encryption between Horizon and your SQL Server, with a proper certificate from your Microsoft CA, and make sure your event data isn’t the low-hanging fruit on your network.
.
Whybother?
Because:
•Anyone with Wireshark can eavesdrop on your events and see user logins, VM power actions, etc.
•Your security team will buy you more coffee if you’re nice to them.
.
The Plan
1.Request & issue a certificate from your Microsoft CA infrastructure.
2.Install the certificate on your SQL Server.
3.Configure SQL Server to force encryption using that cert.
4.Enable Horizon to use SSL for SQL connection
5.Test it and sleep better.
.
1. Request a certificate from your Microsoft CA
On your SQL Server, create a certificate request:
Use certreq or just the MMC GUI.
Here’s the quick-and-dirty via MMC:
1.Open mmc.exe ➔ Add the Certificates snap-in for Computer account.
2.Right-click Personal ➔ Certificates ➔ All Tasks ➔ Request New Certificate.
3.Select your Active Directory Enrollment Policy.
4.Choose a template that includes “Server Authentication” EKU (typically Web Server template).
5.Fill in the common name (CN) with your SQL Server’s FQDN (must match exactly what clients connect to).
(Example: sql01.contoso.local)
6.Enable that private Key is exportable
7.Finish and you’re done. Your cert should show up in Personal ➔ Certificates.
.
2. Install, verify and assign right permission to the cert
Technically it’s already installed, but verify:
•It’s underComputer -> Personal ➔ Certificates on your SQL Server.
•It has Server Authentication (1.3.6.1.5.5.7.3.1) EKU.
•The private key is present (little key icon when you look at the cert).
.
Now we need to assign to the user that starts the SQL server service the permissions to read the private key.
.
.
3. Tell SQL Server to use it
Configure SQL Server
1.Open SQL Server Configuration Manager.
2.Go to SQL Server Network Configuration ➔ Protocols for MSSQLSERVER ➔ Properties ➔ Certificate tab.
3.Select your cert from the dropdown.
.
If it doesn’t show up:
•Check that CN matches the machine’s FQDN.
•Make sure it has Server Authentication EKU.
•Ensure it’s in LocalMachine\My (Personal store).
Force encryption (optional but recommended)
Still in Protocols for MSSQLSERVER ➔ Flags tab➔ Set Force Encryption = Yes.
.
Restart SQL Service
You knew this was coming:
Restart-Service MSSQLSERVER
.
Testing time
Use SQL Server Management Studio (SSMS) to connect, then run:
SELECT session_id, encrypt_option
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
If encrypt_option says TRUE, congrats! 🎉
.
What about Horizon?
Enable SSL with modification in the ADAM DB pae-enableDbSSL and set it to 1
1. Start ADSI Edit
2.Connect to the ADAM DB
Remember that the Distinguished Name is different if you use the OLD ADAM Schema or the new Schema (the DN indicated in the image is the new schema with the rebranding Omnissa)
3.Go to OU=Properties > OU=Global > CN=Common and set the pae-enableDbSSL flag to 1 .
4. Restart the omnissa Horizon Connection Server Service
.
When you configure your Event Database settings in Horizon Administrator, it’ll negotiate TLS automatically if your SQL Server is set up for it.
Just make sure:
•Horizon connects via the FQDN matching the cert CN.
•The client OS trusts your CA (install the CA root cert if needed).
.
Done! Enjoy encrypted peace of mind.
Now your Horizon events are zipped up nice and secure in transit.
No more plain-text passwords, no more nosey packet sniffers. You can go brag to your security team and earn those extra donuts.
.
.
Bonus topic!
Now I check the traffic from Horizon Connection Server and SQL Server
With Wireshark, we can check if the traffic is encrypted:
1. Install Wiresharkand Npcapon the Windows server of one of your connection servers
In the various activities carried out in the year that is ending, load balancing and the other availability of Horizon solutions for both access from the Internet and from the company LAN were among the activities that required multi-handed work between the teams that deal with IT technologies within the company (Security, Network, EUC, Servers …).
While these synergies are easy to manage in the context of small companies, when working with large companies, timely planning and design become very important to avoid infrastructural changes (even minimal) that can convert into delays in the delivery of the infrastructure due to the need to re-engage a different team.
One of solutions used to balance access to Omnissa Horizon services is NSX Advanced Load Balancer.
Normally, the publication of Omnissa VDI solutions is carried out using the virtual appliances Unified Access Gateway (UAG) where “Omnissa Unified Access Gateway enables secure remote access from an external network to a variety of internal resources provided by Omnissa Workspace ONE and Horizon deployments.”
Natively UAGs have their own HA solution, but it has the requirement of having 3 Public IP Addresses and creating three public FQDNs.
The use of NSX Advanced Load balancer allows various UAG balancing solutions:
Single VIP with Two Virtual Services
Single L4 Virtual Service
(n+1) VIP
In my HomeLab I have tested the various solutions indicated above,
the most interesting is the one that I propose you try for the following reasons:
• Robust enough to handle the persistence issues
• Works well in environments where users come behind the NAT
• Ease of configuration
• Better visibility and logs
Additionally, the standard ports of the Blast and PCo protocols will not be used, as this can easily expose the solutions to potentially malicious individuals.
The infrastructure that I will propose also requires a change to the “classic” UAG configurations on the URLs used for the Blast and PCOIP protocols.
In the implementation that we will do, we will take as an example only the part of the Blast protocol
The following flow explains the step when a user tries to access Omnissa VDI, the flow has two ports opened for primary and secondary traffic:
Port 443 – This is for XML API traffic
Ports 5001 to 5002 – Horizon internal ports opened for L7 primary XML traffic to handle redirected traffic
Ports 30001 to 30002 – Blast
Where:
Client L7 request comes to AVI LB https://horizon.pollaio.site/
AVI LB chooses 1 pool member (say UAG1) and send back to client a 307 redirect Location https://horizon.pollaio.site:5001
Client sends request on redirected port https:// horizon.pollaio.site:5001
AVI LB (L7) sends requests to UAG1 https:// horizon.pollaio.site:5001 (Port Traslation)*
UAG1 responds back with XML payload
AVI LB parses the XML response and replace the L4 ports (to client) https:// horizon.pollaio.site:30001 (blast)
Client sends L4 request for Blast to AVI LB
AVI LB sends request to UAG https:// horizon.pollaio.site:30001*
UAG1 responds back to AVI LB
AVI LB responds back to client
The main aspect is the correct configuration of TCP and UDP ports between the various corporate network segments:
Source
Destination
Protocol
Port
Unified Access Gateway
Horizon Agent
UDP
22443
Unified Access Gateway
Horizon Agent
TCP
22443
Unified Access Gateway
Horizon Connection Server
TCP
443
Horizon Client
Virtual Service AVI
TCP
443
Horizon Client
Virtual Service AVI
UDP
443
Horizon Client
Virtual Service AVI
TCP
5001
Horizon Client
Virtual Service AVI
UDP
5001
Horizon Client
Virtual Service AVI
TCP
5002
Horizon Client
Virtual Service AVI
UDP
5002
Horizon Client
Virtual Service AVI
TCP
30001
Horizon Client
Virtual Service AVI
UDP
30001
Horizon Client
Virtual Service AVI
TCP
30002
Horizon Client
Virtual Service AVI
UDP
30002
Configurazione NSX ALB
Create a Virtual IP
Create a Custom Health Monitor for UAG
Create a UAG Pool
Install the SSL certificate Required for L7 VIP
Create a Virtual Service for UAG
Binding DataScripts to the Virtual Service
Create a Virtual IP
To create a custom health monitor, navigate to Applications > VS VIPs.
Click Create.
Create a Custome Health Monitor
To create a custom health monitor, navigate to Templates > Profiles > Health Monitors.
Click Create.
Select the VMware Cloud that was created for Horizon.
Enter the following details in the New Health Monitor screen
Create UAG Pool
Navigate to Applications > Pools.
Select the cloud from the SelectCloud window.
Click Next.
Click Create Pool.
In the CREATE POOL screen, update the details as shown below:
In the Servers tab, add the Server IP Address of the UAG servers.
In Health Monitor tab, select the appropriate Health profile as shown below:
Installing the SSL certificate Required for L7 VIP
The public certificate must be imported into AVI LB it need the same imported in to UAG.
The certificate to be imported must be in PEM format.
Once imported, ensure that the CA certificate is properly linked.
Here are the steps to import the certificate
To import a CA Certificate, navigate to Templates > Security > SSL/TLS Certificates.
Click Create.
Select Root/Intermediate CA Certificate.
Provide a name to identify the certificate later
Upload or Paste Certificate File
VALIDATE and SAVE
Creating Virtual Service for UAG
To create the new virtual service,
Navigate to Applications > Virtual Services.
Click CREATE VIRTUAL SERVICE > Advanced Setup.
Bind the virtual service VIP.
Use the System-HTTP-Horizon-UAG as the Application Profile.
Configure the virtual service as shown below:
In the Service Port section, click Switch to Advanced and configure the service ports.
Bind the pool and the SSL certificate added,
Click Next.
Click Next and Save the configuration.
NOTE:
Two ports are opened for primary and secondary traffic:
Port 443 – This is for XML API traffic
Ports 5001 to 5002 – Horizon internal ports opened for L7 primary XML traffic to handle redirected traffic
Ports 30001 to 30002 – Blast
Configure DataScript
Binding the Horizon DataScript on the Virtual Service
From the UI, navigate to Applications > Virtual Services.
Edit the virtual service that was created.
Go to Policies > DataScripts.
Click Add DataScripts.
Under Script To Execute, select System-Standard-Horizon-UAG.
Click Save DataScript and click Save.
System-Standard-Horizon-UAG is embedded AVI Load Balancer Datascript
UAG Configuration
Modify each UAG’s Blast and PCoIP external URL fields to use the custom ports added in the NSX Advanced Load Balancer port map (From the UI, Edit Pool > Servers tab under New Pool or Edit Pool page).
Modify the Blast external URL to include the custom port for UDP.
For example, https://<ENAV_PUBLIC_FQDN>.com:<BLAST-CUSTOM-PORT>/?UDPPort=<BLAST-CUSTOM-PORT>.
Let’s be honest: certificates are not the most exciting thing in IT. They don’t sparkle, they don’t blink, and they rarely impress your CIO in a slide deck. But if you’re running an Omnissa Horizon environment (also with Omnissa Access integration), SSL certificates are the unsung heroes that make your infrastructure secure, trusted, and usable.
