このワークフローを使用して、ポッドにデプロイされているいずれかのタイプのゲートウェイ構成に配置されている SSL 証明書を置き換えます。必要に応じて、このワークフローを使用して、ゲートウェイで構成されている完全修飾ドメイン名 (FQDN) を置き換えることもできます。SSL 証明書を置き換える理由の 1 つとして、ゲートウェイ構成に現在配置されている SSL 証明書の有効期限が近づいていることが考えられます。これらの手順は、Horizon Universal Console のポッドの編集ウィザードを使用して実行します。
重要: このユースケースの場合:
- 環境は、[ブローカ] ページに示されている Microsoft Azure のポッドのシングルポッド仲介で構成されています。
- また、ポッドは、シングルポッド仲介を使用した Horizon Cloud 環境 — Microsoft Azure 内の環境の Horizon Cloud ポッドと Access の統合で説明されているように、Access と統合されています
- 目標は、ポッドとの通信時に Access Connector によって使用される SSL 証明書を置き換えることです
その場合、そのユースケースに対して実行するさまざまな手順があります。Access Connector とポッドの統合に関するユースケースの場合は、以下の手順を実行しないでください。これらの手順は、以下の手順とはまったく異なります。Access Connector の統合とそのニーズの概要については、 シングルポッド仲介を使用した Horizon Cloud 環境 — 関連するアクセス テナント情報を使用して Microsoft Azure で Horizon Cloud ポッドを構成する手順を参照してください。また、デプロイが、エンド ユーザーのクライアントとブラウザをポッド マネージャ アプライアンスに直接接続するまれで一般的ではないシナリオである場合は、以下の手順に従って、これらのまれなシナリオで使用される SSL 証明書を置き換えないでください。Access Connector の使用事例および一般的ではないまれなシナリオの使用事例に適用される証明書構成の説明については、 代わりに、Horizon Cloud ポッドのマネージャ仮想マシンでの SSL 証明書の構成の概要(主にシングルポッド ブローカ環境のポッドを備えた Access Connector によって使用)を参照してください。
ポッドのゲートウェイが最初にポッドにデプロイされてから時間が経過すると、ポッドのゲートウェイで構成されている SSL 証明書の置き換え、またはゲートウェイで構成されている FQDN の置き換え、またはその両方が必要になる場合があります。通常は、ポッドでプロビジョニングされたリソースにアクセスするために Horizon Client またはブラウザで使用する FQDN をエンド ユーザーに提供します。ブラウザを使用したデスクトップおよび RDS ベースのリモート アプリケーションへのログインおよびHorizon Client を使用したデスクトップまたは RDS ベースのリモート アプリケーションへのログインのトピックで説明するように、一部のエンド ユーザーはブラウザを開いてその FQDN を入力します。他のエンド ユーザーはいずれかの Horizon Client を使用する場合があります。エンド ユーザーにクライアントとブラウザを指定するように指示するゲートウェイに構成された SSL 証明書により、それらのクライアントとブラウザはそのゲートウェイへの接続を信頼できるようになります。デプロイされた Horizon Cloud ポッドで説明されているように、ポッドには外部 Unified Access Gateway 構成、内部タイプ、またはその両方を含めることができます。いずれのタイプの Unified Gateway 構成でも、Unified Access Gateway インスタンスは FQDN および SSL 証明書情報で構成されます。
さまざまな理由で、ポッドのゲートウェイで構成されている SSL 証明書と FQDN を置き換えることが必要になる場合があります。理由の 1 つは、ゲートウェイで構成されたインプレース SSL 証明書の証明書チェーンに有効期限があり、そのカレンダーの日付と時刻が間もなく近づいているためである可能性があります。そのような状況では、現在の有効期限に達する前に SSL 証明書を置き換えて、エンド ユーザーのクライアントまたはブラウザがゲートウェイに接続しようとするときに証明書の信頼の問題が発生しないようにする必要があります。SSL 証明書を置き換えるもう 1 つの理由は、エンド ユーザーがクライアントとブラウザで別の FQDN の使用を開始する場合です。SSL 証明書は FQDN と連携するため、FQDN を別の FQDN に変更する場合は、通常、SSL 証明書を新しい FQDN に基づく証明書に置き換えます。
メモ: システムが構成を変更している間、ポッドによってサービスが提供されるセッションを接続しているエンド ユーザーのアクティブなセッションは切断されます。データの損失は発生しません。構成の変更が完了すると、これらのユーザーは再接続できます。
前提条件
このワークフローを完了するには、以下が必要です。
-
次の条件を満たす置き換え用 SSL 証明書。この証明書では、エンド ユーザーがクライアントとブラウザで使用する FQDN を使用して、使用資格が付与されたリソースにアクセスするためにポッドのゲートウェイに接続する必要があります。
-
その FQDN に基づいた署名付き SSL サーバ証明書(PEM 形式)。Unified Access Gateway 製品ドキュメントで説明されているように、Unified Access Gateway 機能ではクライアント接続に SSL が必要です。証明書は、信頼できる認証局 (CA) によって署名されている必要があります。1 つの PEM ファイルに完全な証明書チェーンとプライベート キーが含まれている必要があります。たとえば、単一の PEM ファイルに SSL サーバ証明書、必要な中間 CA 証明書、ルート CA 証明書、およびプライベート キーが含まれている必要があります。OpenSSL は、PEM ファイルの作成に使用できるツールです。
重要: 証明書チェーン内のすべての証明書には、有効期間が設定されている必要があります。Unified Access Gateway 仮想マシンでは、中間証明書を含むチェーン内のすべての証明書の有効期間が設定されている必要があります。チェーン内のいずれかの証明書が期限切れの場合、後で証明書が Unified Access Gateway 構成にアップロードされるときに予期しない障害が発生する可能性があります。
-
その SSL 証明書に対応する FQDN。この FQDN は、ポッドのゲートウェイに接続するためにエンド ユーザーのクライアントとブラウザで使用されるものです。SSL 証明書を置き換える理由が、ユーザーのクライアントの有効期限の問題を回避することである場合は、ゲートウェイですでに構成されているのと同じ FQDN を保持している可能性があります。これは、ウィザードに表示されます。また、FQDN を新しいものに変更する場合は、このポッドに固有の FQDN を使用する必要があります。他のポッドにすでに構成されている FQDN を再使用することはできません。
重要: この FQDN にアンダースコアを含めることはできません。このリリースでは、FQDN にアンダースコアが含まれていると、Unified Access Gateway インスタンスへの接続に失敗します。
手順
-
コンソールで、 設定 > キャパシティ に移動し、ポッドの名前をクリックしてその詳細ページを開きます。
-
ポッドの詳細ページで、 編集 をクリックします。
-
[ポッドを編集] ウィンドウで、 次へ をクリックして ゲートウェイ設定 の手順に移動します。
-
ゲートウェイ構成で実行する必要がある変更に応じて、 外部 UAG セクションまたは 内部 UAG セクションのいずれかで、関連する手順を完了します。
-
FQDN の値を新しい値に置き換えます。
-
変更 をクリックして新しい証明書をアップロードし、SSL 証明書を置き換えます。
Microsoft Azure で実行されている Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするために Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、指定した FQDN に基づいており、信頼できる CA によって署名されている必要があります。
-
-
保存して終了 をクリックします。
FQDN または証明書を更新すると既存のユーザー接続が切断されることを示す確認メッセージが表示され、ワークフローの開始を確認するように求められます。
-
はい をクリックしてワークフローを開始します。
重要: 証明書チェーン内のいずれかの証明書の有効期限が切れている場合、 更新ステータス には 更新に失敗しました と表示されます。このメッセージが表示された場合は、証明書ファイルを確認し、すべての証明書の有効期間が過ぎていないか確認してください。
次のタスク
どの Unified Access Gateway 構成を変更したかにかかわらず、以前のものとは異なる FQDN に変更した場合は、DNS サーバの CNAME レコードを更新して、構成のロード バランサの FQDN を新しい FQDN にマッピングするようにしてください。詳細については 、DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法 を参照してください。
このページは役に立ちましたか?