ハッシュおよび URL の証明書エンコード・タイプの使用

IKE フローの間に、セキュリティー・エンドポイントは証明書ペイロードの証明書情報を交換し、その証明書情報によってデジタル署名操作を実行することで互いを認証し合うことができます。IKED が、ネットワーク・セキュリティー・クライアントに代わって IKEv2 フェーズ 1 セキュリティー・アソシエーションのネゴシエーションを行う場合、IKED はこれらのデジタル署名操作用にネットワーク・セキュリティー・サーバーを使用します。リモート・セキュリティー・エンドポイントから受け取ったエンコードされた証明書情報が、ネットワーク・セキュリティー・サーバーに転送されます。IKED によってリモート・セキュリティー・エンドポイントに送信されるエンコードされた証明書情報は、ネットワーク・セキュリティー・サーバーから取得されます。

IKEv1 で使用するために定義されているエンコード・タイプはいくつかありますが、IKEv1 実装によってサポートされる必要のある唯一のエンコード・タイプは、X.509 証明書の署名です。IKEv2 実装では、2 つの追加証明書エンコード・タイプがサポートされる必要があります。

一般に証明書または証明書バンドルのハッシュおよび URL は、提示される証明書または証明書バンドルよりもかなり小さくなります。IKE ピア間および IKED とネットワーク・セキュリティー・サーバーの間で交換されるデータはわずかです。メッセージ・サイズが小さいとネットワーク・リソースの効率は高くなりますが、ハッシュおよび URL のエンコードを使用することはより多くの処理を必要とします。NSSD は HTTP サーバーと通信し、URL を使用して証明書を取得する必要があり、またハッシュを使用して証明書を検査する必要があります。必要な場合、この通信によって IKEv2 フェーズ 1 ネゴシエーションを完了するのにかかる時間が増大します。

ピアに送信するハッシュおよび URL を NSSD で作成するようにしたい場合は、証明書および証明書バンドルを含むファイルを HTTP サーバー上に作成する必要があります。また、これらのファイルの URL を NSSD 構成ファイルに組み込む必要があります。NSSD でハッシュおよび URL 証明書エンコードを生成できるようにする を参照してください。

規則: 証明書または証明書バンドルを HTTP サーバー上に配置し、URL を NSSD 構成ファイルに追加したとしても、その証明書を NSSD の鍵リングに保管する必要があります。

NSSD は、ピアから受け取るハッシュおよび URL エンコード証明書を受け入れることができます。その場合、NSSD はピアによって送信された URL を使用して証明書を見つけます。NSSD は、URL を使用して HTTP サーバーから取得するデータをキャッシュに入れます。NSSD で受信したハッシュおよび URL 証明書エンコードを処理できるようにするを参照してください。

URL 情報が NSSD に対して構成されている場合でも、ネットワーク・セキュリティー・サーバーでハッシュおよび URL エンコードを使用すべきかどうかを判断するのは、最終的にはネットワーク・セキュリティー・クライアントの責任です。ハッシュおよび URL 証明書エンコード使用の制御を参照してください。