Horizon Certificate Update Fails with Domain Authentication Error

August 4, 2026 3 answers
Asked by MellowCedar42
I'm trying to replace a Horizon certificate that expires in about 48 hours. The production environment is Horizon 8, but I still have an older Horizon 7 environment available for testing. After installing the new certificate in the older environment, domain authentication fails with the error "authentication cannot proceed, domain name is invalid." Authentication from off-domain clients through Okta still works. There are three Unified Access Gateways pointing to two Connection Servers for on-premises access, and both Connection Servers are configured the same way. The new GoDaddy root and intermediate certificates have also been distributed to client machines through Workspace ONE. I believe I followed the installation guides, but I may be overlooking a simple Horizon-specific certificate requirement. Has anyone run into this error or know what I should verify?

Answers

CopperLynx88
Donโ€™t overlook the Unified Access Gateway versions. Some older UAG releases have trouble with certificates created using newer algorithms or extensions, even when the same certificate works on the Connection Servers. Check the UAG compatibility matrix and certificate requirements, and consider upgrading the UAG appliances in a test window if they are significantly older than the Connection Servers.
Reply to this answer
QuartzPanda7
The first thing Iโ€™d verify is the certificate alias in the Windows certificate store. Horizon expects the certificate to use a specific nameโ€”commonly โ€œvdmโ€โ€”and it may not use the new certificate if the friendly name is different. Also confirm that the private key is present and that the full certificate chain is installed in the correct stores.

BlueHarbor19: Yes, I remember the same requirement. The certificate generally has to be renamed to the expected โ€œvdmโ€ alias in the certificate store before Horizon will use it.

Reply to this answer
NimbleCactus31
Check the certificate directly from the Horizon server as well. Binding the new certificate to IIS on a temporary alternate port can help confirm whether the server presents the expected certificate, hostname, SANs, and complete intermediate chain. That can separate a certificate problem from a Horizon configuration problem.
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions