Android 証明書認証の場合、証明書プロキシ サービスは独立したサービスとして Omnissa Access ノード上で実行され、ポート 5262 で接続を受信して、認証のために接続をポート 443 の Omnissa Access サービスにプロキシします。
Omnissa Access の HTTPS 443 トラフィックは、ロード バランサ/リバース プロキシでレイヤー 7 SSL オフロードに設定するか、レイヤー 4 TCP としてバックエンド サーバに SSL パススルーすることができます。443 トラフィックに SSL パススルーが構成されている場合、公的に信頼されている証明書はポート 443 の Omnissa Access サービスとポート 5262 の CertProxy サービスで共有されます。その他の構成は必要ありません。
HTTPS トラフィックがロード バランサ/リバース プロキシで SSL オフロードされている場合、Omnissa Access サービスはアプリケーションのインストール中に生成された自己署名証明書を信頼して使用します。5262 は公的に信頼された SSL 証明書を必要とする SSL パススルーを使用する SSL レイヤー 4 TCP に設定する必要があるため、ホスト上で実行されている 2 つのサービス間で証明書の不一致が発生します。この問題を回避するため、CertProxy サービスではサーバ上にセカンダリ ポート 5263 が構成されている必要があります。ポート 5263 は、Omnissa Access サービスで実行されているのと同じ自己署名証明書を共有します。追加のポート 5263 を構成することで、Androids のモバイル SSO プロセス全体で通信が保護され、信頼できるようになります。また、ロード バランサで HTTPS トラフィックの復号化も可能になります。
HTTP 443 トラフィックに対して SSL 再暗号化を行うか SSL オフロードを行うかの判断
以下の判断マトリックス表は、Omnissa Access サービスで証明書プロキシ サービスを設定するのに役立ちます。
この表では、SAN 証明書は Omnissa Access VIP FQDN と各ノード マシンの FQDN を含む証明書として定義されます。FQDN は、ルーティング不可能なドメイン/サブドメインの形式です。Workspace ONE の設計に基づき、表を使用してポート 5263 が構成されているかどうかを確認します。
証明書プロキシ構成の判断マトリックス表
| 公開された名前空間 | DMZ 名前空間 | 証明書タイプ | ロード バランサの要件 | 証明書プロキシ ポート 5263 が必要 |
|---|---|---|---|---|
| 共有名前空間 (.com / .com) | ||||
| example.com | example.com | ワイルドカード、SAN | SSL の再暗号化が必要 | いいえ |
| example.com | example.com | 単一ホスト CN | SSL の再暗号化が必要 | はい |
| example.com | example.com | ワイルドカード、SAN | SSL パススルーが必要 | いいえ |
| 不整合な名前空間 (.com / .dmz) | ||||
| example.com | example.dmz | ワイルドカード、単一ホスト CN | SSL の再暗号化が必要 | はい |
| example.com | example.dmz | SAN | SSL の再暗号化が必要 | いいえ |
| example.com | example.dmz | SAN | SSL パススルーが必要 | いいえ |
ポート 5262 のみが構成された DMZ の Omnissa Access プロキシ ポート構成
ポート 5262 および 5263 が構成された DMZ の Omnissa Access プロキシ ポート構成
このページは役に立ちましたか?