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)

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)