# Cisco ISE Host Header の制限
Cisco ISE および Aruba ClearPass の両方とも（以下まで、かつそれを含めてのみ **ClearPass 6.9.5**）は、OCSP を照会する際に HTTP 1.1 をサポートしておらず、OCSP リクエストで Host ヘッダーを送信しません。これは、おそらくバックエンドで使用されているように見える OpenSSL の 1.0.2 までのバージョンでは [OCSP リクエストで Host ヘッダーを送信するために追加のパラメーターが必要だった](https://github.com/openssl/openssl/issues/1986)一方、2016 年 8 月にリリースされた OpenSSL 1.1.0 ではそれが自動的に行われるためです。そのため、Azure App Services 上で実行される一般的な SCEPman インスタンスには接続できません。エラーメッセージは次のようになる場合があります:
%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media)
Cisco は現在、将来の機能拡張を調査中ですが、当面は [Azure Application Gateway](https://azure.microsoft.com/en-us/services/application-gateway/) を使用して、Host ヘッダーを必要としない SCEPman のインスタンスを提供できます。
以下の手順では、SCEPman 用の Azure Application Gateway を作成するために必要なステップを示します:
## 1) 新しい Application Gateway を作成する
%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)
## 2) 必要な基本情報を入力する
%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)
## 3) 新しい静的パブリック IP アドレスを作成する
%20\(4\)%20\(5\)%20\(5\)%20\(5\)%20\(2\)%20\(1\).png?alt=media)
## 4) 新しいバックエンド プールを作成し、それを SCEPman App Service に向ける
%20\(4\)%20\(5\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(2\)%20\(6\).png?alt=media)
{% hint style="info" %}
Geo-Redundant シナリオでは、両方の SCEPman アプリ サービスをバックエンド プールに追加する必要があります。
{% endhint %}
## 5) HTTP 用のルーティング ルールを追加する
%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(2\)%20\(1\).png?alt=media)
## 5b) Host ヘッダー（公開 SCEPman FQDN）付きの新しい HTTP 設定を追加する
{% hint style="warning" %}
6 月初め頃、Microsoft は Azure Application Gateway にバグを導入し、「バックエンド ターゲットからホスト名を選択」が選ばれている場合に、Host ヘッダーのないリクエストへ Host ヘッダーを追加できなくなりました。このドキュメントの以前の版では「バックエンド ターゲットからホスト名を選択」を推奨していましたが、これはもはや機能しません。回避策として、下図のように「特定のドメイン名で上書き」を選択し、SCEPman App Service の名前、たとえば *contoso-scepman.azurewebsites.net*.
{% endhint %}
%20\(1\)%20\(2\)%20\(4\)%20\(3\)%20\(1\).png?alt=media)
## 6) オプション: HTTPS 用のルーティング ルールを追加する
{% hint style="warning" %}
この手順には HTTPS Web サーバー証明書が必要です。
{% endhint %}
{% hint style="info" %}
TLS を使用しない HTTP の利用はセキュリティ上の脆弱性ではありません。PKI ベースのリソースは、TLS ハンドシェイクでこれらのリソースへのアクセスが必要になる可能性があるため、通常は TLS なしの HTTP で公開されます。TLS を使用すると、TLS ハンドシェイクが PKI リソースへのアクセスを必要とし、PKI リソースへのアクセスが TLS ハンドシェイクを必要とするという、鶏と卵の問題が発生します。そのため、SCEP や OCSP といったプロトコルを含むこれらの PKI リソースでは、必要な箇所で独自の暗号化および/または署名を使用します。
{% endhint %}
%20\(4\)%20\(3\).png?alt=media)
## 6b) Host ヘッダー（公開 SCEPman FQDN）付きの新しい HTTPS 設定を追加する
## 7) ルーティング ルールを確認する
%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)
## 8) Application Gateway の構成を完了する
%20\(4\)%20\(3\)%20\(1\).png?alt=media)
## 9) IP の DNS 名を構成する
次に、Gateway に DNS 名を追加します:
1. IP アドレス リソースを開く
2. 任意の名前を DNS 名ラベルとして追加する
オプション: 自分の DNS サーバーに、その DNS 名の CNAME エントリを追加できます。
{% hint style="info" %}
Geo-Redundant シナリオでは、Cisco ISE で OCSP レスポンダーとして、SCEPman のカスタム ドメイン URL（traffic manager を指す）と Application Gateway の URL の両方を引き続き使用できます。
{% endhint %}
{% hint style="info" %}
OCSP レスポンダーの URL は次のようになります: `http:///ocsp`
**注意:** OCSP レスポンダーの URL は HTTPS ではなく HTTP である必要があります。 [こちら](https://docs.scepman.com/ja/security-faq#id-21.-can-https-only-be-enabled)
{% endhint %}
## Intune/JAMF の構成
Intune の構成では、Azure Application Gateway の URL の代わりに App Service の URL を引き続き使用できます。この場合、クライアントは App Service と直接通信します。Cisco ISE では Azure Application Gateway の URL を構成する必要があります。HTTP 1.0 リクエストをサポートするのはこの URL のみだからです。