証明書の検証
詳しくは、CA 証明を検証する方法をご覧ください。
SRXシリーズファイアウォールでデジタル証明書を検証する
IKE ネゴシエーション中、SRXシリーズ ファイアウォール上の PKI は、VPN ピアから受信した X509 証明書を検証します。実行される証明書の検証は、RFC 5280、 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile で指定されています。基本的な証明書と証明書チェーンの検証には、署名と日付の検証、および失効チェックが含まれます。このトピックでは、PKI によって実行される追加のデジタル証明書検証について説明します。
ポリシーの検証
X509 証明書には、オプションのポリシー検証フィールドを含めることができます。ポリシー検証フィールドが存在する場合、ポリシー検証は、エンドエンティティ (EE) 証明書と中間CA 証明を含む証明書チェーン全体に対して実行されます。ポリシー検証は、ルート証明書には適用されません。ポリシー検証では、EE と中間 CA 証明に共通のポリシーがあることを確認します。検証する証明書チェーンに共通ポリシーが存在しない場合、証明書の検証は失敗します。
ポリシー検証の前に、自己署名ルート証明書、中間 CA 証明、および EE 証明書を含む証明書チェーンを構築する必要があります。ポリシーの検証は、自己署名ルート証明書によって発行された中間 CA 証明書から始まり、EE 証明書まで続きます。
次のオプションの証明書フィールドは、ポリシー検証に使用されます。
ポリシー OID
requireExplicitPolicy
skipCerts
これらのフィールドについては、次のセクションで説明します。
SRXシリーズファイアウォールで設定されたポリシーOID
状況によっては、ピアからの既知のポリシーオブジェクト識別子(OID)を持つ証明書のみを受け入れることが望ましい場合があります。このオプションの設定では、ピアから受信した証明書チェーンに、SRXシリーズファイアウォールで設定されたポリシーOIDが少なくとも1つ含まれている場合にのみ、証明書の検証が成功します。
SRXシリーズファイアウォールでは、ポリシーOIDは[edit security ike policy policy-name certificate]階層レベルのpolicy-oids設定ステートメントを使用してIKEポリシーで設定されます。最大 5 つのポリシー OID を設定できます。ピアの証明書を正常に検証するには、ピアの証明書チェーンに、SRXシリーズファイアウォールで設定されたポリシーOIDの少なくとも1つが含まれている必要があります。証明書の policy-oids フィールドはオプションであることに注意してください。SRXシリーズファイアウォールでポリシーOIDを設定しても、ピアの証明書チェーンにポリシーOIDが含まれていない場合、証明書の検証は失敗します。
SRXシリーズファイアウォールにポリシーOIDが設定されていない
SRXシリーズファイアウォールでポリシーOIDが設定されていない場合、証明書チェーンで requireExplicitPolicy フィールドが検出されるたびにポリシーの検証が開始されます。証明書には、1 つ以上の証明書ポリシー OID を含めることができます。ポリシー検証を成功させるには、証明書チェーンに共通ポリシーOIDが存在する必要があります。
図 1 は、ルート CA、3 つの中間 CA、および EE の証明書で構成される証明書チェーンを示しています。Int-CA-2 の CA 証明書には requireExplicitPolicy フィールドが含まれています。したがって、ポリシー検証は Int-CA-2 で始まり、EE-1 まで続きます。Int-CA-2の証明書には、ポリシーOIDのP1、P2、およびP3が含まれています。Int-CA-3の証明書には、ポリシーOIDのP2、P3、およびP4が含まれています。EE-1 の証明書には、ポリシー OID P2 および P5 が含まれています。ポリシー OID P2 は検証対象の証明書と共通であるため、ポリシーの検証は成功します。
によるポリシー検証
中間 CA 証明書のオプションの skipCerts フィールドは、ポリシー検証から除外される証明書の数(現在の CA 証明書を含む)を示します。 skipCerts が 0 の場合、ポリシーの検証は現在の証明書から開始されます。 skipCerts が 1 の場合、現在の証明書はポリシー検証から除外されます。 skipCerts フィールドの値は、すべての中間 CA 証明書でチェックされます。除外される証明書の現在の数よりも少ない skipCerts 値が検出された場合は、小さい方の skipCerts 値が使用されます。
図 2 は、ルート CA、4 つの中間 CA、および EE で構成される証明書チェーンを示しています。Int-CA-1 の skipCerts 値は 12 であり、Int-CA-1 の証明書を含む 12 の証明書をスキップします。ただし、 skipCerts 値は、チェーン内のすべての中間 CA 証明書でチェックされます。Int-CA-2 の skipCerts 値は 2 で、12 より小さいため、2 つの証明書がスキップされます。Int-CA-4 の skipCerts 値は 5 であり、これは 2 より大きいため、Int-CA-4 の skipCerts 値は無視されます。
によるポリシー検証
SRXシリーズファイアウォールでポリシーOIDが設定されている場合、証明書フィールド requireExplicitPolicy と skipCerts は無視されます。
パス長の検証
証明書の検証には、ルート CA、1 つ以上のオプションの中間 CA、および EE 証明書を含む証明書チェーンを含めることができます。中間 CA の数は、展開シナリオに応じて増加する可能性があります。パス長の検証は、証明書の検証に関与する中間証明書の数を制限するメカニズムを提供します。 path-length は、X509 証明書のオプションのフィールドです。 path-length の値は、証明書の検証に許可される非自己署名中間 CA 証明の数を示します。最後の証明書 (通常は EE 証明書) は、パス制限に含まれません。ルート証明書に パス長 の値が 0 が含まれている場合、中間 CA 証明は許可されません。 path-length の値が 1 の場合、0 または 1 の中間 CA 証明が存在する可能性があります。
path-length は、証明書チェーン内の複数の CA 証明に存在できます。パス長の検証は、常に自己署名ルート証明書から始まります。パス制限は、チェーン中の中間証明書ごとに 1 ずつ減少します。中間証明書に現在のパス制限よりも小さい パス長 値が含まれている場合、新しい制限が適用されます。一方、 path-length の値が現在のパス制限よりも大きい場合は無視されます。
図 3 は、ルート CA、4 つの中間 CA、および EE で構成される証明書チェーンを示しています。Root-CA の path-length 値は 10 です。したがって、証明書の検証に許可される非自己署名中間CA 証明の初期パス制限は 10 です。Int-CA-1 では、パス制限は 10-1 または 9 です。Int-CA-1の path-length 値は4であり、パス制限の9より小さいため、新しいパス制限は4になります。Int-CA-2 では、パス制限は 4-1 または 3 です。Int-CA-2の path-length 値は5であり、パス制限の3よりも大きいため、無視されます。Int-CA-3 では、パス制限は 3-1 または 2 です。Int-CA-3 の path-length 値は 20 であり、パス制限の 2 よりも大きいため、これも無視されます。
主な使用法
EE または CA 証明書の鍵用途フィールドは、証明書に含まれる鍵の目的を定義します。
EE 証明書の場合、鍵用途フィールドは存在するが、証明書に digitalSignature または 否認防止 フラグが含まれていない場合、証明書は拒否されます。「鍵用途」フィールドが存在しない場合、鍵用途はチェックされません。
CA 証明の場合、証明書または CRL 署名の検証のためにキーを訴えることができます。PKI は X509 証明書の検証と CRL のダウンロードの両方を担当するため、証明書または CRL を検証する前にキーの使用状況を確認する必要があります。
証明書署名の検証では、 keyCertSign フラグは、CA 証明書を証明書署名の検証に使用できることを示します。このフラグが設定されていない場合、証明書の検証は終了します。
CRL 署名検証のフェーズ 1 ネゴシエーションでは、参加者は CRL をチェックして、IKE 交換中に受け取った証明書がまだ有効かどうかを確認します。CRL は、証明書失効チェックとして CRL で構成された CA プロファイルに対して定期的にダウンロードされます。デバイスにダウンロードする前に、ダウンロードした CRL ファイルを確認する必要があります。検証手順の 1 つは、CA 証明書を使用して CRL 署名を検証することです。ダウンロードした CRL に CA 証明書の秘密キーで署名し、デバイスに保存されている CA 証明書の公開キーを使用して秘密キーで検証する必要があります。ダウンロードした CRL を検証するには、CA 証明書のキー使用法フィールドに CRLSign フラグが含まれている必要があります。このフラグが存在しない場合、CRL は破棄されます。
発行者とサブジェクトのDN検証
署名検証は、ピアから受信した証明書、および CA サーバからダウンロードされた CRL ファイルに対して実行する必要があります。署名検証では、証明書内の発行者の DN または検証対象の CRL に基づいて、CA データベース内の CA 証明書を検索します。
図 4 は、発行者 DN に基づく CA 証明の検索を示しています。EE 証明書では、発行者 DN は CA-1 であり、これはチェーン内の中間 CA 証明書のサブジェクト DN です。中間 CA 証明書では、発行者 DN は CA-Root であり、これはチェーン内の自己署名 Root-CA 証明書のサブジェクト DN です。CRL では、発行者 DN は CA-Root であり、これは自己署名ルート CA 証明書のサブジェクト DN です。
発行者またはサブジェクトDNの検索は、属性値に関する次のルールに従う必要があります。
異なる ASN.1 型 (PrintableString や BMPString など) でエンコードされた属性値は、異なる文字列を表すと見なされます。
PrintableString 型でエンコードされた属性値では、大文字と小文字は区別されません。これらの属性値は、先頭と末尾の空白を削除し、1つ以上の連続する空白の内部部分文字列を1つのスペースに変換した後に、相互に比較されます。
PrintableString 以外の型でエンコードされた属性値では、大文字と小文字が区別されます。
MXシリーズデバイスでのデジタル証明書の検証
Junos OS リリース 16.1R3 以降、MXシリーズ デバイスはデジタル証明書の検証をサポートしています。IKE ネゴシエーション中、MXシリーズ デバイス上の PKI は、VPN ピアから受信した X509 証明書を検証します。実行される証明書の検証は、RFC 5280、 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile で指定されています。基本的な証明書と証明書チェーンの検証には、署名と日付の検証、および失効チェックが含まれます。このトピックでは、PKI によって実行される追加のデジタル証明書検証について説明します。
ポリシーの検証
X509 証明書には、オプションのポリシー検証フィールドを含めることができます。ポリシー検証フィールドが存在する場合は、EE 証明書と中間 CA 証明を含む証明書チェーン全体に対してポリシー検証を実行する必要があります。ポリシー検証は、ルート証明書には適用されません。ポリシー検証では、EE と中間 CA 証明に共通のポリシーがあることを確認します。検証対象の証明書チェーンに共通ポリシーが存在しない場合、証明書の検証は失敗します。
ポリシー検証を実行する前に、自己署名ルート証明書、中間 CA 証明書、および EE 証明書を含む証明書チェーンを構築する必要があります。ポリシーの検証は、自己署名ルート証明書によって発行された中間 CA 証明書から始まり、EE 証明書まで続きます。
次のオプションの証明書フィールドは、ポリシー検証に使用されます。
ポリシー OID
requireExplicitPolicy
skipCerts
これらのフィールドについては、次のセクションで説明します。
MXシリーズデバイス上で設定されたポリシーOID
状況によっては、ピアからの既知のポリシーオブジェクト識別子(OID)を持つ証明書のみを受け入れることが望ましい場合があります。このオプションの設定では、ピアから受信した証明書チェーンに、MXシリーズデバイスで設定されたポリシーOIDが少なくとも1つ含まれている場合にのみ、証明書検証が成功します。
MXシリーズデバイスでは、[edit security ike policy policy-name certificate]階層レベルでpolicy-oids設定ステートメントを使用してIKEポリシーでポリシーOIDを設定する必要があります。最大 5 つのポリシー OID を設定できます。ピアの証明書を正常に検証するには、ピアの証明書チェーンに、MXシリーズデバイスで設定されたポリシーOIDの少なくとも1つが含まれている必要があります。証明書の policy-oids フィールドはオプションであることに注意してください。MXシリーズデバイスでポリシーOIDを設定したが、ピアの証明書チェーンにポリシーOIDが含まれていない場合、証明書の検証は失敗します。
MXシリーズデバイスにポリシーOIDが設定されていません
MXシリーズデバイスでポリシーOIDが設定されていない場合、証明書チェーンで requireExplicitPolicy フィールドが検出されるたびに、ポリシーの検証が開始されます。証明書には、1 つ以上の証明書ポリシー OID が含まれる場合があります。ポリシー検証を成功させるには、証明書チェーンに共通ポリシーOIDが存在する必要があります。
図 5 は、ルート CA、3 つの中間 CA、および EE の証明書で構成される証明書チェーンを示しています。Int-CA-2 の CA 証明書には requireExplicitPolicy フィールドが含まれています。したがって、ポリシー検証は Int-CA-2 で始まり、EE-1 まで続きます。Int-CA-2の証明書には、ポリシーOIDのP1、P2、およびP3が含まれています。Int-CA-3の証明書には、ポリシーOIDのP2、P3、およびP4が含まれています。EE-1 の証明書には、ポリシー OID P2 および P5 が含まれています。ポリシー OID P2 は検証対象の証明書と共通であるため、ポリシーの検証は成功します。
によるポリシー検証
中間 CA 証明書のオプションの skipCerts フィールドは、ポリシー検証から除外される証明書の数(現在の CA 証明書を含む)を示します。 skipCerts が 0 の場合、ポリシーの検証は現在の証明書から開始されます。 skipCerts が 1 の場合、現在の証明書はポリシー検証から除外されます。 skipCerts フィールドの値は、すべての中間 CA 証明書でチェックされます。除外される証明書の現在の数よりも少ない skipCerts 値が検出された場合は、小さい方の skipCerts 値が使用されます。
図 6 は、ルート CA、4 つの中間 CA、および EE で構成される証明書チェーンを示しています。Int-CA-1 の skipCerts 値は 12 であり、Int-CA-1 の証明書を含む 12 の証明書をスキップします。ただし、 skipCerts 値は、チェーン内のすべての中間 CA 証明書でチェックされます。Int-CA-2 の skipCerts 値は 2 で、12 より小さいため、2 つの証明書がスキップされます。Int-CA-4 の skipCerts 値は 5 であり、これは 2 より大きいため、Int-CA-4 の skipCerts 値は無視されます。
によるポリシー検証
MXシリーズデバイスでポリシーOIDが設定されている場合、証明書フィールド requireExplicitPolicy と skipCerts は無視されます。
パス長の検証
証明書の検証には、ルート CA、1 つ以上のオプションの中間 CA、および EE 証明書を含む証明書チェーンを含めることができます。中間 CA の数は、展開シナリオに応じて増加する可能性があります。パス長の検証は、証明書の検証に関与する中間証明書の数を制限するメカニズムを提供します。 path-length は、X509 証明書のオプションのフィールドです。 path-length の値は、証明書の検証に許可される非自己署名中間 CA 証明の数を示します。最後の証明書 (通常は EE 証明書) は、パス制限に含まれません。ルート証明書に パス長 の値が 0 が含まれている場合、中間 CA 証明は許可されません。 path-length の値が 1 の場合、0 または 1 の中間 CA 証明が存在する可能性があります。
path-length は、証明書チェーン内の複数の CA 証明に存在できます。パス長の検証は、常に自己署名ルート証明書から始まります。パス制限は、チェーン中の中間証明書ごとに 1 ずつ減少します。中間証明書に現在のパス制限よりも小さい パス長 値が含まれている場合、新しい制限が適用されます。一方、 path-length の値が現在のパス制限よりも大きい場合は無視されます。
図 7 は、ルート CA、4 つの中間 CA、および EE で構成される証明書チェーンを示しています。Root-CA の path-length 値は 10 であるため、証明書の検証に許可される非自己署名中間 CA 証明の初期パス制限は 10 です。Int-CA-1 では、パス制限は 10-1 または 9 です。Int-CA-1の path-length 値は4であり、パス制限の9より小さいため、新しいパス制限は4になります。Int-CA-2 では、パス制限は 4-1 または 3 です。Int-CA-2の path-length 値は5であり、パス制限の3よりも大きいため、無視されます。Int-CA-3 では、パス制限は 3-1 または 2 です。Int-CA-3 の path-length 値は 20 であり、パス制限の 2 よりも大きいため、これも無視されます。
主な使用法
EE または CA 証明書の鍵用途フィールドは、証明書に含まれる鍵の目的を定義します。
EE 証明書
EE 証明書の場合、鍵用途フィールドは存在するが、証明書に digitalSignature または 否認防止 フラグが含まれていない場合、証明書は拒否されます。「鍵用途」フィールドが存在しない場合、鍵用途はチェックされません。
CA 証明
このキーは、証明書または CRL 署名の検証に使用できます。PKI は X509 証明書の検証と CRL のダウンロードの両方を担当するため、証明書または CRL を検証する前にキーの使用状況を確認する必要があります。
証明書署名の検証
keyCertSign フラグは、CA 証明書を証明書の署名の検証に使用できることを示します。このフラグが設定されていない場合、証明書の検証は終了します。
CRL 署名の検証
フェーズ 1 のネゴシエーションでは、参加者は CRL をチェックして、IKE 交換中に受信した証明書がまだ有効かどうかを確認します。CRL は、証明書失効チェックとして CRL で構成された CA プロファイルに対して定期的にダウンロードされます。ダウンロードした CRL ファイルは、デバイスにダウンロードする前に検証する必要があります。検証手順の 1 つは、CA 証明書を使用して CRL 署名を検証することです。ダウンロードした CRL は CA 証明書の秘密キーで署名されており、デバイスに保存されている CA 証明書の公開キーで検証する必要があります。ダウンロードした CRL を検証するには、CA 証明書のキー使用法フィールドに CRLSign フラグが含まれている必要があります。このフラグが存在しない場合、CRL は破棄されます。
発行者とサブジェクトの識別名の検証
署名の検証は、ピアから受信した証明書と、CA サーバからダウンロードされた CRL ファイルに対して実行されます。署名の検証では、証明書または検証対象の CRL 内の発行者の DN に基づいて、CA データベース内の CA 証明書を検索します。
図 8 は、発行者 DN に基づく CA 証明のルックアップを示しています。EE 証明書では、発行者 DN は CA-1 であり、これはチェーン内の中間 CA 証明書のサブジェクト DN です。中間 CA 証明書では、発行者 DN は CA-Root であり、これはチェーン内の自己署名 Root-CA 証明書のサブジェクト DN です。CRL では、発行者 DN は CA-Root であり、これは自己署名ルート CA 証明書のサブジェクト DN です。
発行者またはサブジェクトDNの検索は、属性値に関する次のルールに従う必要があります。
異なる ASN.1 型 (PrintableString や BMPString など) でエンコードされた属性値は、異なる文字列を表すと見なされます。
PrintableString 型でエンコードされた属性値では、大文字と小文字は区別されません。これらの属性値は、先頭と末尾の空白を削除し、1 つ以上の連続する空白の内部部分文字列を 1 つのスペースに変換した後に比較されます。
PrintableString 以外の型でエンコードされた属性値では、大文字と小文字が区別されます。
例:ポリシーOIDの設定によるデジタル証明書の検証
状況によっては、ピアからの既知のポリシーオブジェクト識別子(OID)を持つ証明書のみを受け入れることが望ましい場合があります。このオプションの設定では、ピアから受信した証明書チェーンに、SRXシリーズファイアウォールで設定されたポリシーOIDが少なくとも1つ含まれている場合にのみ、証明書の検証が成功します。この例では、SRXシリーズファイアウォールのIKEポリシーでポリシーOIDを設定する方法を示しています。
SRXシリーズファイアウォールで設定されたポリシーOIDの少なくとも1つが、ピアの証明書または証明書チェーンに含まれていることを確認する必要があります。ピアの証明書の policy-oids フィールドはオプションであることに注意してください。IKEポリシーでポリシーOIDを設定し、ピアの証明書チェーンにポリシーOIDが含まれていない場合、ピアの証明書検証は失敗します。
必要条件
開始する前に、以下を実行します。
SRXシリーズファイアウォールにJunos OS リリース 12.3X48-D10以降を使用していることを確認します。
IPSec VPN トンネルを構成します。 IPSec VPN 設定の概要を参照してください。この例では、IKE フェーズ 1 およびフェーズ 2 VPN トンネルの完全な構成は示されていません。
概要
この例では、ポリシー OID 2.16.840.1.101.3.1.48.2 および 5.16.40.1.101.3.1.55.2 が指定されている IKE ポリシーの構成を示しています。IKE ポリシーは、ike_cert_pol IKE の提案 ike_cert_propを参照していますが、このは示されていません。SRXシリーズファイアウォール上のローカル証明書は lc-igloo-rootです。
構成
プロシージャ
CLIクイック構成
この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから commit を入力します。
set security ike policy ike_cert_pol mode main set security ike policy ike_cert_pol proposals ike_cert_prop set security ike policy ike_cert_pol certificate local-certificate lc-igloo-root set security ike policy ike_cert_pol certificate policy-oids 2.16.840.1.101.3.1.48.2 set security ike policy ike_cert_pol certificate policy-oids 5.16.40.1.101.3.1.55.2
手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイドの 設定モードにおけるCLIエディターの使用を参照してください。
証明書検証用のポリシーOIDを設定するには、次の手順を実行します。
IKEポリシーを構成します。
[edit security ike policy ike_cert_pol] user@host# set mode main user@host# set proposals ike_cert_prop user@host# set certificate local-certificate lc-igloo-root user@host# set certificate policy-oids 2.16.840.1.101.3.1.48.2 user@host# set certificate policy-oids 5.16.40.1.101.3.1.55.2
業績
設定モードから、 show security ike policy ike_cert_pol コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@host# show security ike policy ike_cert_pol
mode main;
proposals ike_cert_prop;
certificate {
local-certificate lc-igloo-root;
policy-oids [ 2.16.840.1.101.3.1.48.2 5.16.40.1.101.3.1.55.2 ];
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
CA 証明書の検証
目的
デバイスに設定されているCA証明書を表示します。
アクション
動作モードから、 show security pki ca-certificate ca-profile ca-tmp コマンドを入力します。
user@host> show security pki ca-certificate ca-profile ca-tmp detail
Certificate identifier: ca-tmp
Certificate version: 3
Serial number: 00000047
Issuer:
Organization: U.S. Government,
Organizational unit: DoD, Organizational unit: Testing, Country: US,
Common name: Trust Anchor
Subject:
Organization: U.S. Government,
Organizational unit: Dod, Organizational unit: Testing, Country: US,
Common name: CA1-PP.01.03
Subject string:
C=US, O=U.S. Government, OU=Dod, OU=Testing, CN=CA1-PP.01.03
Validity:
Not before: 01- 1-1998 12:01 UTC
Not after: 01- 1-2048 12:01 UTC
?Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:cb:fd:78:0c:be:87:ac:cd:c0:33:66:a3:18
9e:fd:40:b7:9b:bc:dc:66:ff:08:45:f7:7e:fe:8e:d6:32:f8:5b:75
db:76:f0:4d:21:9a:6e:4f:04:21:4c:7e:08:a1:f9:3d:ac:8b:90:76
44:7b:c4:e9:9b:93:80:2a:64:83:6e:6a:cd:d8:d4:23:dd:ce:cb:3b
b5:ea:da:2b:40:8d:ad:a9:4d:97:58:cf:60:af:82:94:30:47:b7:7d
88:c3:76:c0:97:b4:6a:59:7e:f7:86:5d:d8:1f:af:fb:72:f1:b8:5c
2a:35:1e:a7:9e:14:51:d4:19:ae:c7:5c:65:ea:f5:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Certificate Policy:
Policy Identifier = 2.16.840.1.101.3.1.48.2
Use for key: CRL signing, Certificate signing
Fingerprint:
e0:b3:2f:2e:a1:c5:ee:ad:af:dd:96:85:f6:78:24:c5:89:ed:39:40 (sha1)
f3:47:6e:55:bc:9d:80:39:5a:40:70:8b:10:0e:93:c5 (md5)
ポリシー OID 検証の確認
目的
ピアの証明書の検証に成功すると、IKEとIPsec SAが確立されます。ピアの証明書の検証に失敗した場合、IKE SAは確立されません。
アクション
動作モードから、 show security ike security-associations コマンドと show security ipsec security-associations コマンドを入力します。
user@host> show security ike security-associations node0: -------------------------------------------------------------------------- Index State Initiator cookie Responder cookie Mode Remote Address 821765168 UP 88875c981252c1d8 b744ac9c21bde57e IKEv2 192.0.2.2 1106977837 UP 1a09e32d1e6f20f1 e008278091060acb IKEv2 198.51.100.202
user@host> show security ipsec security-associations node0: -------------------------------------------------------------------------- Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <213909506 ESP:aes-cbc-192/sha256 8cb9e40a 1295/ unlim - root 500 192.0.2.2 >213909506 ESP:aes-cbc-192/sha256 8271d2b2 1295/ unlim - root 500 192.0.2.2 <218365954 ESP:aes-cbc-192/sha256 d0153bc0 1726/ unlim - root 1495 198.51.100.202 >218365954 ESP:aes-cbc-192/sha256 97611813 1726/ unlim - root 1495 198.51.100.202
意味
show security ike security-associationsコマンドは、すべてのアクティブなIKEフェーズ1のSAを一覧表示します。SA が表示されない場合は、フェーズ 1 の確立に問題があったことになります。この場合、システムログでPKID_CERT_POLICY_CHECK_FAILメッセージを確認します。このメッセージは、ピアの証明書チェーンに、SRXシリーズファイアウォールで設定されたポリシーOIDが含まれていないことを示しています。ピアの証明書チェーン内のpolicy-oids値を、SRXシリーズファイアウォールで設定された値と照合します。
また、ピアの証明書チェーンに、オプションのフィールドである policy-oids フィールドが含まれていない可能性もあります。この場合、SRXシリーズファイアウォールでポリシーOIDが設定されていると、証明書の検証に失敗します。
例:MXシリーズデバイスでポリシーOIDを設定することによるデジタル証明書検証の向上
状況によっては、ピアからの既知のポリシーオブジェクト識別子(OID)を持つ証明書のみを受け入れることが望ましい場合があります。このオプションの設定では、ピアから受信した証明書チェーンに、MXシリーズデバイスで設定されたポリシーOIDが少なくとも1つ含まれている場合にのみ、証明書検証が成功します。この例では、MXシリーズデバイス上のIKEポリシーでポリシーOIDを設定する方法を示しています。
MXシリーズデバイスで設定されたポリシーOIDの少なくとも1つが、ピアの証明書または証明書チェーンに含まれていることを確認する必要があります。ピアの証明書の policy-oids フィールドはオプションであることに注意してください。IKEポリシーでポリシーOIDを設定し、ピアの証明書チェーンにポリシーOIDが含まれていない場合、ピアの証明書検証は失敗します。
必要条件
開始する前に、以下を実行します。
MXシリーズデバイスに Junos OS リリース 16.1 以降を使用していることを確認します。
IPSec VPN トンネルを構成します。
概要
この例では、ポリシー OID 2.16.840.1.101.3.1.48.2 および 5.16.40.1.101.3.1.55.2 が指定されている IKE ポリシーの構成を示しています。IKE ポリシーは、ike_cert_pol IKE の提案 ike_cert_propを参照していますが、このは示されていません。MXシリーズデバイス上のローカル証明書はlc-igloo-rootです。
構成
プロシージャ
CLIクイック構成
この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから commit を入力します。
set services ipsec-vpn ike policy ike_cert_pol mode main set services ipsec-vpn ike policy ike_cert_pol proposals ike_cert_prop set services ipsec-vpn ike policy ike_cert_pol certificate local-certificate lc-igloo-root set services ipsec-vpn ike policy ike_cert_pol certificate policy-oids 2.16.840.1.101.3.1.48.2 set services ipsec-vpn ike policy ike_cert_pol certificate policy-oids 5.16.40.1.101.3.1.55.2
手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイドの 設定モードにおけるCLIエディターの使用を参照してください。
証明書検証用のポリシーOIDを設定するには、次の手順を実行します。
IKEポリシーを設定します。
[edit services ipsec-vpn ike policy ike_cert_pol] user@host# set mode main user@host# set proposals ike_cert_prop user@host# set certificate local-certificate lc-igloo-root user@host# set certificate policy-oids 2.16.840.1.101.3.1.48.2 user@host# set certificate policy-oids 5.16.40.1.101.3.1.55.2
業績
設定モードから、 show services ipsec-vpn ike policy ike_cert_pol コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@host# show services ipsec-vpn ike policy ike_cert_pol
mode main;
proposals ike_cert_prop;
certificate {
local-certificate lc-igloo-root;
policy-oids [ 2.16.840.1.101.3.1.48.2 5.16.40.1.101.3.1.55.2 ];
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
CA 証明書の検証
目的
デバイスに設定されているCA証明書を表示します。
アクション
オペレーションモードから、 show security pki ca-certificate ca-profile ca-tmp コマンドを入力します。
user@host> show security pki ca-certificate ca-profile ca-tmp detail
Certificate identifier: ca-tmp
Certificate version: 3
Serial number: 00000047
Issuer:
Organization: U.S. Government,
Organizational unit: DoD, Organizational unit: Testing, Country: US,
Common name: Trust Anchor
Subject:
Organization: U.S. Government,
Organizational unit: Dod, Organizational unit: Testing, Country: US,
Common name: CA1-PP.01.03
Subject string:
C=US, O=U.S. Government, OU=Dod, OU=Testing, CN=CA1-PP.01.03
Validity:
Not before: 07- 3-2015 10:54 UTC
Not after: 07- 1-2020 10:54 UTC
?Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:cb:fd:78:0c:be:87:ac:cd:c0:33:66:a3:18
9e:fd:40:b7:9b:bc:dc:66:ff:08:45:f7:7e:fe:8e:d6:32:f8:5b:75
db:76:f0:4d:21:9a:6e:4f:04:21:4c:7e:08:a1:f9:3d:ac:8b:90:76
44:7b:c4:e9:9b:93:80:2a:64:83:6e:6a:cd:d8:d4:23:dd:ce:cb:3b
b5:ea:da:2b:40:8d:ad:a9:4d:97:58:cf:60:af:82:94:30:47:b7:7d
88:c3:76:c0:97:b4:6a:59:7e:f7:86:5d:d8:1f:af:fb:72:f1:b8:5c
2a:35:1e:a7:9e:14:51:d4:19:ae:c7:5c:65:ea:f5:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Certificate Policy:
Policy Identifier = 2.16.840.1.101.3.1.48.2
Use for key: CRL signing, Certificate signing
Fingerprint:
e0:b3:2f:2e:a1:c5:ee:ad:af:dd:96:85:f6:78:24:c5:89:ed:39:40 (sha1)
f3:47:6e:55:bc:9d:80:39:5a:40:70:8b:10:0e:93:c5 (md5)
ポリシー OID 検証の確認
目的
ピアの証明書の検証に成功すると、IKEとIPsec SAが確立されます。ピアの証明書の検証に失敗した場合、IKE SAは確立されません。
アクション
動作モードから、 show services ipsec-vpn ike security-associations コマンドと show services ipsec-vpn ipsec security-associations コマンドを入力します。
user@host> show services ipsec-vpn ike security-associations node0: -------------------------------------------------------------------------- Index State Initiator cookie Responder cookie Mode Remote Address 821765168 UP 88875c981252c1d8 b744ac9c21bde57e IKEv2 192.0.2.1 1106977837 UP 1a09e32d1e6f20f1 e008278091060acb IKEv2 198.51.100.0
user@host> show services ipsec-vpn ipsec security-associations node0: -------------------------------------------------------------------------- Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <213909506 ESP:aes-cbc-192/sha256 8cb9e40a 1295/ unlim - root 500 192.0.2.1 >213909506 ESP:aes-cbc-192/sha256 8271d2b2 1295/ unlim - root 500 192.0.2.1 <218365954 ESP:aes-cbc-192/sha256 d0153bc0 1726/ unlim - root 1495 198.51.100.0 >218365954 ESP:aes-cbc-192/sha256 97611813 1726/ unlim - root 1495 198.51.100.0
意味
show services ipsec-vpn ike security-associationsコマンドは、すべてのアクティブなIKEフェーズ1のSAを一覧表示します。SA が表示されない場合は、フェーズ 1 の確立に問題があったことになります。この場合、システムログでPKID_CERT_POLICY_CHECK_FAILメッセージを確認します。このメッセージは、ピアの証明書チェーンに、MXシリーズデバイスで設定されたポリシーOIDが含まれていないことを示しています。ピアの証明書チェーン内のpolicy-oids値を、MXシリーズデバイスで設定された値と照合します。
また、ピアの証明書チェーンに、オプションのフィールドである policy-oids フィールドが含まれていない可能性もあります。この場合、MXシリーズデバイスでポリシーOIDが設定されていると、証明書の検証は失敗します。
例:ピア証明書チェーン検証のためのデバイスの設定
この例では、IKE ネゴシエーション中にピアデバイスを検証するために使用される証明書チェーンのデバイスを設定する方法を示しています。
必要条件
開始する前に、CA のアドレスと、ローカル証明書の要求を送信するときに CA が必要とする情報 (チャレンジ パスワードなど) を取得します。
概要
この例では、証明書チェーン用のローカル デバイスの設定方法、CA 証明書とローカル証明書の登録方法、登録済み証明書の有効性の確認方法、ピア デバイスの失効ステータスの確認方法を示します。
位相幾何学
この例では、Host-A の設定と運用コマンドを示しています( 図 9 を参照)。動的 CA プロファイルが Host-A で自動的に作成され、Host-A が Sales-CA から CRL をダウンロードし、Host-B の証明書の失効ステータスを確認できるようになります。
フェーズ1およびフェーズ2ネゴシエーションのIPSec VPN設定は、この例ではHost-Aに対して示されています。フェーズ1とフェーズ2のオプションが正常にネゴシエートされ、SAが確立されるように、ピアデバイス(Host-B)が正しく設定されている必要があります。
構成
証明書チェーンのデバイスを設定するには、次の手順に従います。
CA プロファイルの設定
CLIクイック構成
この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから commit を入力します。
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://10.157.88.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check use-crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://10.157.88.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check use-crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://10.157.88.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check use-crl
手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイドの 設定モードにおけるCLIエディターの使用を参照してください。
CA プロファイルを設定するには:
Root-CA の CA プロファイルを作成します。
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://10.157.88.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check use-crl
Eng-CA の CA プロファイルを作成します。
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://10.157.88.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check use-crl
Dev-CA の CA プロファイルを作成します。
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://10.157.88.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check use-crl
業績
設定モードから、 show security pki コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Root/";
}
revocation-check {
use-crl;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Eng/";
}
revocation-check {
use-crl;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Dev/";
}
revocation-check {
use-crl;
}
}
デバイスの設定が完了したら、設定モードから commit を入力します。
証明書の登録
手順
証明書を登録するには、次の手順を実行します。
CA 証明を登録します。
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
プロンプトで yes と入力して、CA 証明書を読み込みます。
CA 証明がデバイスに登録されていることを確認します。
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = juniper, CN = Root-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = juniper, CN = Root-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = juniper, CN = Eng-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)登録された CA 証明の有効性を検証します。
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
ローカル証明書を登録します。
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password juniper domain-name host-a.company.net email host-a@company.net subject DC=juniper,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
ローカル証明書がデバイスに登録されていることを確認します。
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = juniper, CN = Dev-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(1024 bits)登録されたローカル証明書の有効性を確認します。
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
設定された CA プロファイルの CRL ダウンロードを確認します。
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Root-CA Effective date: 09- 9-2015 13:08 Next update: 09-21-2015 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Eng-CA Effective date: 08-22-2015 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Dev-CA Effective date: 09-14-2015 21:15 Next update: 09-26-2012 11:02
IPSec VPN オプションの設定
CLIクイック構成
IPSec VPN オプションをすばやく設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから commit を入力します。
set services ipsec-vpn ike proposal ike_cert_prop_01 authentication-method rsa-signatures set services ipsec-vpn ike proposal ike_cert_prop_01 dh-group group5 set services ipsec-vpn ike proposal ike_cert_prop_01 authentication-algorithm sha1 set services ipsec-vpn ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set services ipsec-vpn ike policy ike_cert_pol_01 mode main set services ipsec-vpn ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set services ipsec-vpn ike policy ike_cert_pol_01 certificate local-certificate Host-A set services ipsec-vpn ipsec proposal ipsec_prop_01 protocol esp set services ipsec-vpn ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set services ipsec-vpn ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set services ipsec-vpn ipsec proposal ipsec_prop_01 lifetime-seconds 300 set services ipsec-vpn ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set services ipsec-vpn ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイドの 設定モードにおけるCLIエディターの使用を参照してください。
IPSec VPNオプションを設定するには、次の手順に従います。
フェーズ1のオプションを設定します。
[edit services ipsec-vpn ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit services ipsec-vpn ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A
フェーズ2のオプションを設定します。
[edit services ipsec-vpn ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit services ipsec-vpn ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit services ipsec-vpn ipsec vpn ipsec_cert_vpn_01] user@host# set ike ipsec-policy ipsec_pol_01
業績
設定モードから、 show security ike コマンドと show security ipsec コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。
[edit]
user@host# show services ipsec-vpn ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
[edit]
user@host# show services ipsec-vpn ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
ピア デバイス間の IKE ネゴシエーション中に証明書の検証が成功すると、IKE と IPsec SA の両方が確立されます。
IKEフェーズ1ステータスの確認
目的
IKEフェーズ1ステータスを確認します。
アクション
動作モードから show services ipsec-vpn ike security-associations コマンドを入力します。
user@host> show services ipsec-vpn ike security-associations Remote Address State Initiator cookie Responder cookie Exchange type 192.0.2.0 Matured 63b3445edda507fb 2715ee5895ed244d Main
IPsecフェーズ2ステータスの確認
目的
IPsec フェーズ 2 のステータスを確認します。
アクション
動作モードから show services ipsec-vpn ipsec security-associations コマンドを入力します。
user@host> show services ipsec-vpn ipsec security-associations
Service set: ips_ss1, IKE Routing-instance: default
Rule: vpn_rule_ms_2_2_01, Term: term11, Tunnel index: 1
Local gateway: 10.0.1.2, Remote gateway: 172.16.0.0
IPSec inside interface: ms-2/2/0.1, Tunnel MTU: 1500
UDP encapsulate: Disabled, UDP Destination port: 0
Direction SPI AUX-SPI Mode Type Protocol
inbound 2151932129 0 tunnel dynamic ESP
outbound 4169263669 0 tunnel dynamic ESP
失効した証明書のIKEおよびIPsec SAの失敗
失効した証明書の確認
問題
ピアデバイス間のIKEネゴシエーション中に証明書の検証に失敗した場合は、ピアの証明書が失効していないことを確認してください。動的 CA プロファイルを使用すると、ローカル デバイスはピアの CA から CRL をダウンロードし、ピアの証明書の失効ステータスを確認できます。動的 CA プロファイルを有効にするには、親 CA プロファイルで revocation-check crl オプションを設定する必要があります。
解決
ピアの証明書の失効ステータスを確認するには、次の手順に従います。
動作モードから show security pki crl コマンドを入力して、ピア デバイスの CRL を表示する動的 CA プロファイルを識別します。
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02CA プロファイル
dynamic-001は Host-A で自動的に作成されるため、Host-A は Host-B の CA (Sales-CA) から CRL をダウンロードし、ピアの証明書の失効ステータスを確認できます。動作モードから show security pki crl ca-profile dynamic-001 detail コマンドを入力して、動的 CA プロファイルの CRL 情報を表示します。
入る
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCホスト B の証明書 (シリアル番号 10647084) が失効しました。
証明書有効期限トラップを設定する
開始する前に、以下を実行します。
VPN での証明書のしくみを理解します。 証明書チェーンの理解をお読みください。
このトピックでは、証明書有効期限トラップを設定し、トラップを生成するまでの日数を設定する方法について説明します。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。