For production systems that are configured for the single-pod brokering type, a key use case for configuring an SSL certificate on the Horizon Cloud pod's manager VMs is that of integrating Workspace ONE Access with the pod. The Workspace ONE Access connector has to be able to trust SSL connections to the pod manager VMs. That is how integration of these pods with Workspace ONE Access works. For this specific use case of integrating with the Workspace ONE Access connector, the pod needs SSL certificates to be set directly on the pod's manager VMs.
When your pods are in a single-pod brokering environment, a key part of integrating Workspace ONE Access with a Horizon Cloud pod in Microsoft Azure is configuring the Workspace ONE Access connector to synchronize the Horizon Cloud Virtual Apps Collection that you set up in Workspace ONE Access to use the pod-provisioned desktops and remote applications. The Workspace ONE Access connector needs to communicate with the pod manager VMs to do that synchronization. Therefore the pod needs to present a valid SSL certificate so that the Workspace ONE Access connector will trust it. For more information about this integration, see A Horizon Cloud Environment with Single-Pod Brokering — Integrating the Environment's Horizon Cloud Pods in Microsoft Azure with Workspace ONE Access.
Relationship of the Pod Detail Page's Pod Manager Load Balancer IP Address Field to the Workspace ONE Access Connector's SSL Certificate Requirements
A key piece of information that you will need to create a valid trusted SSL certificate that can be configured on the pod manager VMs is the numerical IP address displayed in the pod detail page next to the label Pod Manager Load Balancer IP. The following screenshot is an illustration of where the Pod Manager Load Balancer IP label is displayed in the deployed pod's details page.
The trusted SSL certificate must be based on the fully qualified domain name (FQDN) that you map in your DNS server to the IP address that is displayed in that field. This mapping is needed so that an end user's client that is configured to use that FQDN can get a trusted connection to the pod.
Now, what is that numerical IP address related to? It is a private IP address from the pod's tenant subnet. The pod resource that IP address is associated with depends on whether the pod has manifest version 1600 or later, or has a manifest version earlier than 1600.
Pods of manifest version 1600 or later
For pods of manifest 1600 of later, the displayed numerical IP address shown for the label Pod Manager Load Balancer IP is the numerical private IP address for the pod's Azure load balancer resource. The pod architecture for pods of manifest 1600 or later includes a pod Azure load balancer with a private IP address from the pod's tenant subnet. That pod Azure load balancer is the point for the SSL communication to the pod manager VMs. As described in , when the high availability feature is enabled for that pod, it has two manager VMs behind that Azure load balancer. In this case, when you click Upload Certificate in the administrative console to upload the SSL certificate files, Horizon Cloud performs the configuration on the active manager VM and then copies the certificate configuration to the other manager VM. When the high availability feature is not enabled for the pod, it has a single manager VM behind that Azure load balancer. When you click Upload Certificate in the console, Horizon Cloud configures the certificate on that manager VM.
The following screenshot depicts how the private IP address of the pod's Azure load balancer is the same IP address that is displayed next to that Pod Manager Load Balancer IP label in the pod's details page in the console for the preceding example.
Pods of earlier manifest versions than 1600
For pods of manifests earlier than 1600, the displayed numerical tenant IP address shown for the label Pod Manager Load Balancer IP is the numerical private IP address from the pod's tenant subnet that is associated with the tenant NIC on the pod manager VM. The pod architecture for earlier manifest versions have a single pod manager VM. The manager VM's private IP address on the tenant subnet is the point for the SSL communication to that manager VM. When you click Upload Certificate in the console, Horizon Cloud configures the certificate on that manager VM.
How to Configure SSL Certificates on the Pod's Manager VMs
You use the administrative console to configure the SSL certificates on the pod manager VMs. For the detailed steps, see Configure SSL Certificates Directly on the Pod Manager VMs, Such as When Integrating the Workspace ONE Access Connector Appliance with the Horizon Cloud Pod in Microsoft Azure, So that Connector Can Trust Connections to the Pod Manager VMs. For the prerequisites before running those steps, see Prerequisites for Running the Horizon Universal Console's Upload Pod Certificate Workflow to Configure SSL Certificates on the Horizon Cloud Pod's Manager VMs.
Atypical Scenarios That Would Need SSL Certificates Configured on the Pod's Manager VMs
Although these scenarios might be appropriate for proof-of-concepts, they are discouraged for production use. For production systems, you should leverage the Horizon Cloud features of internal and external gateway configurations that support end-user connections to their pod-provisioned resources. For end-user connections internal to your corporate network, such as over a VPN, you should have an internal Unified Access Gateway configuration on the pod. For end-user connections over the Internet, you should have an external Unified Access Gateway configuration on the pod. For steps on adding those configurations to your pod, see Add a Gateway Configuration to a Deployed Horizon Cloud Pod.
|Pod deployed with only the external gateway configuration, and no internal Unified Access Gateway configuration||In this scenario, while your end users over the Internet reach their pod-provisioned resources through the deployed external gateway configuration, there is no parallel internal gateway configuration for your users internal to your corporate network to use to reach their pod-provisioned resources. Without an internal Unified Access Gateway configuration, those internal users would have to point their client connections to reach the pod directly. To reach the pod directly means to point the client to the IP address displayed next to the Pod Manager Load Balancer IP label in the pod's details page, or to an FQDN that you map to that displayed IP address in your DNS.|
|Pod deployed without any gateway configuration whatsoever (zero Unified Access Gateway VMs)||
In this scenario, all end user connections to pod-provisioned resources would have to use one of the operating-system-specific Horizon Clients to reach the pod directly. To reach the pod directly means to point the client to the IP address displayed next to the Pod Manager Load Balancer IP label in the pod's details page, or to an FQDN that you map to that displayed IP address in your DNS.
Attention: Unlike when using one of the operating-system-specific Horizon Clients, when you point a browser to the pod directly, that browser connection will behave as an untrusted connection even when you have configured an SSL certificate on the pod's manager VMs using the Upload Certificate action in the console. Typing the pod's FQDN directly into a browser makes the browser connect using the HTML Access (Blast) connection type, and due to the way HTML Access (Blast) works, the browser will display the typical untrusted certificate error when it makes the connection direct to the pod. To avoid that displayed untrusted certificate error, the pod would need gateways configured so that you can have those browser connections go through the appropriate gateway configuration: an external gateway configuration for your end users sitting outside of your corporate network and an internal gateway configuration for your end users sitting inside your corporate network. If you do not want to expose your FQDN to the Internet, use an internal gateway configuration. The internal gateway configuration uses a Microsoft internal load balancer to which end users who are internal to your corporate network can point their connections. See Add a Gateway Configuration to a Deployed Horizon Cloud Pod.