Horizon 8 Wild card certificate import issue

[BMODAK]

i'm not able to import wild card certificate,  after providing the certificate path ( local drive) and password , it takes long tome and the one error appears on top of page .

i tried restarting the horizon connection service, even rebooting server , but no change . 

I'm using Horizon connection server 2406 

[Victor León]

Hello, 

As a workaround, you can import the certificate via MMC to the certificates 'Personal' store. Then, at last reboot the service 'VMware Horizon Security Gateway Component'. 

The friendly name of the new certificate must be 'vdm'. It must be lowercase. Also, you need to change the old certificate friendly name to something else. 

This KB might be helpful. https://kb.omnissa.com/s/article/2082408

 

 

[Dominik]

Hello,

@BMODAK this certificate have option for export private key? Without this option Horizon don't accept this cert. 

[CurtisB]

Might be worth looking at encryption cyphers - 2406 disables older cyphers and protocols (SSL 3, TLS 1.0 and 1.1). This could impact certs from older private CAs.

https://docs.omnissa.com/bundle/Horizon-Security/page/OlderProtocolsandCiphersDeactivatedinHorizon.html

[GoShen]

yes, you need to make the private key exportable. 

I just went through this two months ago. I had import the new CA signed wildcard cert into all connections servers, make the friendly name vdm, then install the same cert into the UAGs and also on the UAGs, update the thumbprint of the new cert. 

Test internnal and external cert in the browser to make sure the thumbprint matched.

[BMODAK]

Thank you all for responces,

@Victor León Yes I tried that but no luck,  The console it self does not work. i had to revert back to original settings.

@Dominik @GoShen  I imported the PFX certificate,  which required a password to be entered.  I've the private key for this certificate.   do I need to import this certificate on another server, export it with private key, and then import it to the Horizon connection server ?
 

@CurtisB this looks interesting ,  I'll take a look and update here.

 

Thanks again 

 

[BMODAK]

@Victor León@Dominik @GoShen @CurtisB

it worked, I removed certificate from the store, and imported certificate manually, only this time I Selected "Make this certificate exportable" , 
So for me solution is combination of @Victor León and @Dominik  answers 🙂  ...

Thanks again for your quick responses 

[GoShen]

BModak,

  I was told that after the certs are renewed like that, its recommended to go into the Horizon Universal Console and enter the credentials again to update it. I cannot find documentation on this yet so I have not done it myself.  Still looking myself.

[robryan]

also keep in mind that security teams tend to be hesitant to allow wildcards to be exportable  - one of the reasons you generally see different certificates used internally (usually free, internal trusted CA, all the connection servers, etc in the SAN lists) vs. externally (only contain any actual external URLs being accessed, possibly only one dns name, maybe with direct UAGs listed.. depends on what's being exposed)

[GoShen]

Robyan,

   Do you mean that the "issued to" name on the CA signed cert should be named view.url.com instead of  named *.domain.com that is imported into the CS severs and UAGs? 

[robryan]

correct - the security implications about wildcard certificates have been covered by people smarter than me at the NSA and many other places, but the crux of it is that if it gets out you can find yourself in a world of hurt across multiple fronts, least of which being that now you have to revoke/reissue that certificate everywhere you've used it.

usually what we see is that a "real" paid for publicly trusted certificate with a limited namespace will be used externally for the gslb/lb/UAGs that only cover the URLs users will be connecting to, and maybe the uag's themselves depending on how your setup is, so at most:

- Main issue to horizon.somewhere.url
- additional DNS entries for uag1.somewhere.url, uag2.somewhere.url, etc.

and then that cert is used on the various external components, load balancer, uag's..  if it needs to be revoked/replaced, it's only affecting your horizon environment and not other various web servers/components because it'd never be used there

internally, you use a private certificate that's trusted on your domain/workstations but isn't paid for, etc. this might be using some of the same namespace, but would have components in the cert that you generally would not want visible to the outside world like:

- Main issue to horizon.somewhere.url if you're using a split DNS setup like most people do, because we all know telling users to go to a different place depending on where they are just generates helpdesk calls
- additional DNS entries for all the various horizon servers themselves, possibly with shortnames that aren't allowed in "public" certificates: cs1.somewhere.url, cs2.somewhere.url, cs1, cs2 ...  since with the UAGs you're putting in the sha256 fingerprint to trust, there isn't a need from that side of the house to have a publicly trusted certificate since that's not a mechanism a user ever sees from their client perspective.

this internal cert would also go on any internal facing load balancers that aren't doing passthrough, etc as well.

the other big advantage of this setup is that when you need to add/change servers internally, you're not having to incur the costs/hassles of reissuing certificates with a public authority (which, i grant isn't necessarily an issue with a wildcard cert, but it still comes back to security and accountability)