Use this workflow to replace the SSL certificate that is in place on either type of gateway configuration that is deployed on your pod. You can also use this workflow to replace the fully-qualified domain name (FQDN) that is configured on the gateway, if you need to do that. One likely reason for replacing the SSL certificate is when the SSL certificate currently in place in the gateway configuration is nearing its expiration date. You perform these steps using the Edit Pod wizard in the Horizon Universal Console.

Important: If you are in this use case:

Then there is a different set of steps to follow for that use case. Do not follow the steps below if your use case is about the Workspace ONE Access Connector integration with your pods. Those steps are completely different than the ones below. For an overview of Workspace ONE Access Connector integration and its needs, see Horizon Cloud Environment with Single-Pod Brokering — Steps for Configuring a Horizon Cloud Pod in Microsoft Azure with the Relevant Workspace ONE Access Tenant Information. Also, if your deployment is a rare, atypical scenario where you are having your end users' clients and browser connect directly to the pod manager appliances, do not follow the steps below to replace the SSL certificate that is used in those rare scenarios. For a description of certificate configuration that applies in the Workspace ONE Access connector use case and the atypical, rare scenario use case, instead read Overview of Configuring SSL Certificates on the Horizon Cloud Pod's Manager VMs, Primarily For Use By the Workspace ONE Access Connector with Pods in a Single-Pod Broker Environment.

After time has passed since the pod's gateways were first deployed for the pod, you might find that you need to replace the SSL certificates that are configured on the pod's gateways or replace the FQDN that is configured on the gateways, or both. Typically, you give your end users an FQDN to use in their Horizon client or browser to access their pod-provisioned resources. As described in the topics Log In to Desktops and RDS-Based Remote Applications Using a Browser and Log In to Desktops or RDS-Based Remote Applications Using the Horizon Client, some end users open a browser and type in that FQDN while others might use one of the Horizon Clients. The SSL certificate that is configured on the gateway to which you tell end users to point their clients and browsers allows those clients and browser to trust connections to that gateway. As described in Horizon Cloud Pod Deployed in Microsoft Azure, the pod can have an external Unified Access Gateway configuration, an internal type, or both. In either type of Unified Gateway configuration, the Unified Access Gateway instances are configured with FQDN and SSL certificate information.

You might want to replace the SSL certificate and FQDN that are configured on the pod's gateways for various reasons. One reason might be because the in-place SSL certificate configured on a gateway has an expiration date in its certificate chain and that calendar date and time is approaching soon. In that situation, you would want to replace the SSL certificate prior to reaching the current one's expiration date, to prevent certificate trust issues in the end users' clients or browsers as they try to connect to the gateway. Another reason for replacing the SSL certificate is when you want your end users to begin using a different FQDN in their clients and browsers. Because the SSL certificate goes in tandem with an FQDN, when you want to change the FQDN to another one, you usually replace the SSL certificate with one that is based on the new FQDN.

Note: During the time the system is changing the configuration, end users who have connected sessions served by the pod will have those active sessions disconnected. No data loss will occur. After the configuration changes are complete, those users can reconnect.

Prerequisites

To complete this workflow, you must have:

  • The replacement SSL certificate that meets the following criteria. That certificate should use the FQDN that you are having your end users use in their clients and browsers to connect to the pod's gateway for access to their entitled resources.
  • A signed SSL server certificate (in PEM format) based on that FQDN. The Unified Access Gateway capabilities require SSL for client connections, as described in the Unified Access Gateway product documentation. The certificate must be signed by a trusted Certificate Authority (CA). The single PEM file must contain the full entire certificate chain with the private key. For example, the single PEM file must contain the SSL server certificate, any necessary intermediate CA certificates, the root CA certificate, and private key. OpenSSL is a tool you can use to create the PEM file.
    Important: All certificates in the certificate chain must have valid time frames. The Unified Access Gateway VMs require that all of the certificates in the chain, including any intermediate certificates, have valid time frames. If any certificate in the chain is expired, unexpected failures can occur later as the certificate is uploaded to the Unified Access Gateway configuration.
  • The FQDN that corresponds to that SSL certificate. This FQDN is the one used in your end users' clients and browsers to connect to the pod's gateway. If your reason for replacing the SSL certificate is to avoid expiration date issues in your users' clients, you will likely be retaining the same FQDN that is already configured on the gateway, which will be displayed in the wizard. If you are also changing the FQDN to a new one, you must have one that is unique to this pod. You cannot reuse an FQDN that is already configured for your other pods.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.

Procedure

  1. In the console, navigate to Settings > Capacity and click the pod's name to open its details page.
  2. In the pod's details page, click Edit.
  3. In the Edit Pod window, click Next to move to the Gateway Settings step.
  4. Depending on the changes you need to make in the gateway configuration, complete the relevant step, in either the External UAG section or Internal UAG section.
    1. Replace the FQDN value with a new one.
    2. Replace the SSL certificate by clicking Change to upload the new certificate.
      Upload the certificate in PEM format that Unified Access Gateway will use to allow clients to trust connections to the Unified Access Gateway instances running in Microsoft Azure. The certificate must be based on the specified FQDN and be signed by a trusted CA.
  5. Click Save & Exit.
    A confirmation message appears stating that updating the FQDN or certificate disconnects existing user connections and asking you to confirm the start of the workflow.
  6. Click Yes to start the workflow.
    Important: If any of the certificates in the certificate chain has expired, the Update status will display Update has failed. If you see this, check the certificate file and verify that the certificates all have valid time frames.

What to do next

For whichever Unified Access Gateway configuration you changed, if you changed to an FQDN that is different from the previous one, ensure you update the CNAME record in your DNS server to map the FQDN of the configuration's load balancer to the new FQDN. See How to Obtain the Horizon Cloud Pod Gateway's Load Balancer Information to Map in Your DNS Server for details.