Omnissa Horizon Connection Server
Copy link to the page “Omnissa Horizon Connection Server”
Renews the Connection Server machine certificate through the Windows service agent with TLS checks and recovery.
What happens
- The service agent on the server fetches the task from the appliance over outbound HTTPS, port 443.
- Discovery matches local TLS fingerprints to one certificate with the exact lowercase friendly name vdm and a private key. Installed version and services scope broker or broker_and_blast. Ambiguous state is left unchanged.
- The Windows basics first import the certificate into the Windows certificate store (LocalMachine\My). The old certificate and key are retained. Backup records certificate names, key ACL, selected services, accounts and running state after Windows base import. The agent checks the new key and grants the necessary service accounts read access.
- The imported Thumbprint is bound by moving the exact vdm name; the certificate is not imported again. The agent takes over this binding automatically and restarts only the selected broker/Blast services.
- Fresh TLS handshakes with SNI must show the new identity on the selected endpoints. Failure triggers automatic restoration of names, ACL and service state; recovery requires the old identity to be served again. If it fails: Foreign changes are not overwritten. If recovery cannot be confirmed, a recovery failure is reported with a protected packet and a log without secrets.
Technical details
- Connection
- The package runs through the service agent on the server. The agent connects over outbound HTTPS to the appliance, port 443 by default. You open no port into the server.
- Service ports
- 443, 8443
- You need
- The service agent installed on the server. The service agent needs access to read and change LocalMachine\My, key read permissions and the selected Horizon services. TLS checks connect directly to the local server using the clients’ DNS/SNI name on 443 and, when selected, 8443; a load balancer identity cannot replace this check. VerifyHostname must contain a client name from the issued certificate; empty uses the server’s own FQDN. The old local certificate is proved against the vdm store fingerprint, including self-signed or expired identities.
- Platform
- Connection Server on a Windows version supported by the installed Horizon release; ECDSA from Server 8.19 (2606)
- Actions
- Discovery, Installation, Verification, Rollback
- Packages
-
vmware-horizon-connection-server - Note
-
- Only the machine identity changes. vdm.ec, vdm.es, LDAP/VDMDS, Enrollment, Script Host and peers are separate. Replacing the vdm binding does not disable an external writer; no documented pause control is established.
- Recovery restores serving identity and changed product configuration. Additive certificate, chain and truststore objects from a completed Windows base import are retained; this is not a full restoration of the pre-import store.
- Package vmware-horizon-connection-server 1.0.0 requires signing and installation through the sslbrain catalogue before use.
Certificate requirements
The agent’s accepted_key_types are RSA 2048/3072/4096 bits and ECDSA P-256/P-384. ECDSA requires discovered Server 8.19 (2606) or later; older/unknown versions use RSA. Usual RSA sizes in the CSR guide are not an exclusive list or manufacturer maximum. RSA minimum for this public profile is 2048; manufacturer-wide maximum and exact ECC curve boundaries are not stated.
Names must cover client FQDNs and relevant load balancer names. CN appears in the manufacturer’s CSR example; that does not prove CN is mandatory. SAN-only profiles without CN, such as Let’s Encrypt tlsserver and Google minimal, have no explicit acceptance rule in the checked manufacturer sources.
The publicly trusted machine TLS certificate is for serverAuth. The 2606 guide says it must not include clientAuth and warns about browser trust after 15 March 2026. keyEncipherment KU in a CSR example does not prove a universal requirement; an additional keyEncipherment requirement is not stated in the checked sources. Cluster clientAuth is a separate purpose.
A single-level DNS wildcard is documented. The manufacturer recommends FQDNs over IP addresses and simple names; the recommendation does not prove structural rejection of IP SANs. IP SAN acceptance and maximum SAN count are not stated. Unknown does not mean unlimited.
Windows base import supplies PFX/PKCS#12 with a matching private key and exportable machine key to LocalMachine\My. The product agent receives only the same run’s Thumbprint. Horizon Console accepts PEM/PFX, but its limits are not automatically Windows store limits. DER without a key is insufficient; JKS is not a direct vdm binding format.
Checked Horizon sources do not state acceptance of PFX ciphers AES, 3DES or RC2. Use the Windows base import’s existing OS/version-aware preparation; an old example does not prove AES rejection.
Intermediates belong in Intermediate Certification Authorities and the root in Trusted Root Certification Authorities. Windows base import does not add new root trust anchors: send PFX without its root, or add the necessary root separately before the run. Supply the chain from the nearest issuer upwards; separate Windows stores are not one PEM chain file. Additive imported objects are retained during product recovery.
The friendly name must be unique and exactly lowercase vdm in LocalMachine\My. vdm.ec and vdm.es are separate certificates and are left unchanged. The old identity retains its key and recorded names for recovery.
The certificate must be valid at activation. Manufacturer minimum/maximum lifetimes for issued certificates are not stated; Horizon’s six-month default certificate is not a CA certificate lifetime limit. Recovery must also be able to restore a known previously expired identity.