VMware Horizon uses many Public-Key Certificates. Some of these certificates are verified using mechanisms that involve a trusted third party but such mechanisms do not always provide the required precision, speed, or flexibility. VMware Horizon uses an alternative mechanism known as thumbprint verification in several situations.
Rather than validating individual certificate fields or building a chain of trust, thumbprint verification treats the certificate as a token, matching the entire byte sequence (or a cryptographic hash of this) to a pre-shared byte sequence or hash. Typically, this is shared just-in-time over a separate trusted channel and means that the certificate presented by a service can be verified to be the exact certificate that was expected.
Horizon Message Bus communicates between connection brokers, and also between Horizon Agents and connection broker instances. Setup channels use per-message signatures and payload encryption, whereas main channels are protected using TLS with mutual authentication. When using TLS to protect a channel, authentication of both client and server involves TLS certificates and thumbprint validation. For Horizon Message Bus channels, the server is always a message router. It is possible for the client to be a message router too since this is how message routers share messages. However, clients are either connection broker instances or Horizon Agents.
The initial certificate thumbprints and setup message signing keys are provided in different ways. On connection brokers, certificate thumbprints are stored in LDAP, so that Horizon Agents can communicate with any connection broker, and all connection brokers can communicate with each other. Horizon Message Bus server and client certificates are automatically generated and exchanged on a periodic basis, and stale certificates are automatically deleted, so no manual intervention is necessary, or indeed possible. Certificates at each end of the main channels are auto-generated on a scheduled basis and exchanged over the setup channels. It is not possible to replace these certificates yourself. Expired certificates are removed automatically.
A similar mechanism applies to the inter-pod communication.
Other communication channels can use customer-provided certificates but default to auto-generating certificates. These include Secure Tunnel, Enrollment Server, and vCenter connections, and display protocol and auxiliary channels. For more information on how to replace these certificates, see the Horizon Administration document. Default certificates are generated at install time and are not automatically renewed, except for PCoIP. If a PKI-generated certificate is not available for PCoIP to use, it auto-generates a new certificate at each startup. Thumbprint verification is used for most of these channels, even if a PKI-generated certificate is used.
Verification of vCenter certificates uses a combination of techniques. Connection broker instances always attempt to validate the received certificate using PKI. If this validation fails, then after reviewing the certificate the VMware Horizon administrator can allow the connection to proceed, and the connection broker remembers the cryptographic hash of the certificate for subsequent unattended acceptance using thumbprint verification.
