証明書の失効
デジタル証明書には有効期限がありますが、有効期限が切れる前に、さまざまな理由で証明書が無効になる場合があります。証明書の失効と検証は、ローカルで管理することも、認証局 (CA) 証明書失効リスト (CRL) を参照することによって管理することもできます。
オンライン証明書ステータスプロトコルと証明書失効リストについて
OCSP は、X509 証明書の失効状態を確認するために使用されます。OCSP は、証明書の失効状態をリアルタイムで提供し、銀行取引や株式取引などの時間的制約のある状況で役立ちます。
証明書の失効ステータスは、SRXシリーズファイアウォールの外側にあるOCSPサーバーにリクエストを送信することでチェックされます。サーバーからの応答に基づいて、VPN 接続が許可または拒否されます。OCSP応答は、SRXシリーズファイアウォールにはキャッシュされません。
OCSP サーバーは、証明書を発行する 認証局 (CA) または指定された許可レスポンダーにすることができます。OCSP サーバーの場所は、手動で構成することも、検証対象の証明書から抽出することもできます。要求は、最初に [edit security pki ca-profile profile-name revocation-check] 階層レベルの ocsp url ステートメントを使用して CA プロファイルで手動で構成された OCSP サーバーの場所に送信されます。CA プロファイルごとに最大 2 つの場所を構成できます。最初に構成された OCSP サーバーに到達できない場合、要求は 2 番目の OCSP サーバーに送信されます。2 番目の OCSP サーバーに到達できない場合、要求は証明書の AuthorityInfoAccess 拡張フィールド内の場所に送信されます。証明書失効リスト(CRL)がデフォルトのチェック方法であるため、use-ocspオプションも設定する必要があります。
SRXシリーズファイアウォールは、CAまたは承認されたレスポンダーからの署名付きOCSP応答のみを受け入れます。受信した応答は、信頼できる証明書を使用して検証されます。応答は次のように検証されます。
-
構成された CA プロファイルに登録されている CA 証明書は、応答を検証するために使用されます。
-
OCSP 応答には、OCSP 応答を検証するための証明書が含まれている場合があります。受信した証明書は、SRXシリーズファイアウォールに登録されているCA証明書によって署名されている必要があります。受信した証明書が CA 証明書によって検証された後、OCSP 応答の検証に使用されます。
OCSP サーバーからの応答は、異なる CA によって署名される場合があります。次のシナリオがサポートされています。
-
デバイスのエンドエンティティ証明書を発行する CA サーバーも、OCSP 失効ステータス応答に署名します。SRXシリーズファイアウォールは、SRXシリーズファイアウォールに登録されているCA証明書を使用してOCSP応答署名を検証します。OCSP 応答が検証されると、証明書失効状態がチェックされます。
-
承認されたレスポンダーは、OCSP 失効状態応答に署名します。認定レスポンダの証明書と検証対象のエンドエンティティ証明書は、同じCAによって発行されている必要があります。承認されたレスポンダーは、まずSRXシリーズファイアウォールに登録されているCA証明書を使用して検証されます。OCSP 応答は、レスポンダの CA 証明書を使用して検証されます。次に、SRXシリーズファイアウォールは、OCSPレスポンスを使用して、エンドエンティティ証明書の失効ステータスを確認します。
-
検証対象のエンドエンティティ証明書と OCSP 応答には、異なる CA 署名者がいます。OCSP 応答は、検証対象のエンドエンティティ証明書の証明書チェーン内の CA によって署名されます。(IKE ネゴシエーションに参加するすべてのピアは、それぞれの証明書チェーンに少なくとも 1 つの共通の信頼できる CA を持っている必要があります)。OCSP レスポンダーの CA は、証明書チェーン内の CA を使用して検証されます。レスポンダ CA 証明書を検証した後、OCSP 応答はレスポンダの CA 証明書を使用して検証されます。
リプレイ攻撃を防ぐために、OCSPリクエストで ノンス ペイロードを送信することができます。Nonce ペイロードは、明示的に無効にされていない限り、デフォルトで送信されます。有効にすると、SRXシリーズファイアウォールはOCSP応答にノンスペイロードが含まれることを期待し、そうでない場合、失効チェックは失敗します。OCSPレスポンダーがノンスペイロードで応答できない場合は、SRXシリーズファイアウォールでノンスペイロードを無効にする必要があります。
通常の業務では、証明書はさまざまな理由で取り消されます。たとえば、証明書が侵害された疑いがある場合や、証明書所有者が退職した場合などは、証明書を取り消すことができます。
証明書の失効と検証は、次の 2 つの方法で管理できます。
-
ローカル:これは限定的なソリューションです。
-
認証局(CA)証明書失効リスト(CRL)を参照する:指定した間隔で、またはCAが設定したデフォルトの間隔で、CRLにオンラインで自動的にアクセスできます。
フェーズ1のネゴシエーションでは、SRXシリーズファイアウォールは、IKE交換中にピアから受信したEE証明書を検証し、CRLを使用してEE証明書がCAによって取り消されていないことを確認します。
CRL がデバイスに読み込まれておらず、ピア証明書の発行者が信頼できる CA である場合:
- Junos OS は、CA プロファイルで定義されている場合、設定された LDAP または HTTP CRL の場所(つまり、CRL 配布ポイント(CDP))を介して CRL を取得します。
- CRL 配布ポイントが CA プロファイルで設定されていない場合、デバイスは CA によって発行された証明書(存在する場合)で CDP 拡張を使用します。CA によって発行される証明書は、管理者が登録した証明書でも、フェーズ 1 のネゴシエーション中に受け取った証明書でもかまいません。
EE 証明書がルート CA によって発行されていない場合、各中間 CA の証明書は同じ検証および失効チェックを受けます。ルート CA の CRL は、ルート CA によって発行された証明書が失効しているかどうかを確認するために使用されます。CDP がルート CA プロファイルで設定されていない場合、デバイスは CA によって発行された証明書(存在する場合)で CDP 拡張を使用します。
X509 証明書の CRL 配布ポイント拡張機能 (.cdp) は、HTTP URL または LDAP URL に追加できます。
証明書に証明書配布ポイント拡張機能が含まれておらず、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) またはハイパーテキスト転送プロトコル (HTTP) を使用して CRL を自動的に取得できない場合は、CRL を手動で取得してデバイスに読み込むことができます。
ローカル証明書は、CRL チェックが無効になっている場合でも、証明書失効リスト (CRL) に対して検証されています。これは、公開キー基盤 (PKI) 構成を使用して CRL チェックを無効にすることで停止できます。CRL チェックが無効になっている場合、PKI はローカル証明書を CRL に対して検証しません。
オンライン証明書ステータスプロトコルと証明書失効リストの比較
オンライン証明書状態プロトコル (OCSP) と証明書失効リスト (CRL) の両方を使用して、証明書の失効状態を確認できます。それぞれの方法には長所と短所があります。
-
OCSP は証明書の状態をリアルタイムで提供し、CRL はキャッシュされたデータを使用します。時間に敏感なアプリケーションには、OCSP が推奨されるアプローチです。
-
証明書の状態の検索は VPN デバイスにキャッシュされた情報に対して実行されるため、CRL チェックが高速になります。OCSP は、外部サーバーから失効状態を取得するのに時間がかかります。
-
CRL には、CRL サーバーから受信した失効リストを格納するために追加のメモリが必要です。OCSP では、証明書の失効状態を保存するために追加のメモリは必要ありません。
-
OCSP では、OCSP サーバーが常に使用可能である必要があります。CRL は、キャッシュされたデータを使用して、サーバーに到達できない場合に証明書の失効状態を確認できます。
MXシリーズおよびSRXシリーズのファイアウォールでは、CRLが証明書の失効ステータスの確認に使用されるデフォルトの方法です。
関連項目
例：デバイスへの CRL の手動読み込み
この例では、CRL をデバイスに手動でロードする方法を示しています。
要件
開始する前に、以下を実行します。
公開キーと秘密キーのペアを生成します。自己署名デジタル証明書を参照してください。
証明書要求を生成します。「例 ：ローカル証明書の CSR を手動で生成し、CA Serverに送信します。
認証局(CA)プロファイルを設定します。「例 ：CA プロファイルの設定.
証明書をデバイスに読み込みます。「例 ：CA 証明書とローカル証明書を手動で読み込む。
概要
CRL は手動で読み込むことも、証明書の有効性を確認するときにデバイスに自動で読み込ませることもできます。CRL を手動で読み込むには、CA から CRL を取得し、デバイスに転送します(FTP などを使用)。
この例では、デバイスの /var/tmp ディレクトリから revoke.crl という CRL 証明書を読み込みます。CA プロファイルは ca-profile-ipsec と呼ばれます。(最大ファイル サイズは 5 MB です)。
CRL が既に ca-profile にロードされている場合は、最初にコマンド clear security pki crl ca-profile ca-profile-ipsec を実行して古い CRL をクリアする必要があります。
設定
手順
ステップバイステップでの手順
CRL 証明書を手動で読み込むには:
CRL 証明書を読み込みます。
[edit] user@host> request security pki crl load ca-profile ca-profile-ipsec filename /var/tmp/revoke.crl
Junos OSは、X509、PKCS #7、DER、またはPEM形式のCA証明書の読み込みをサポートしています。
検証
設定が正常に機能していることを確認するには、 show security pki crl operational mode コマンドを入力します。
ダイナミック CRL のダウンロードとチェックについて
デジタル証明書は一定期間発行され、指定された有効期限を過ぎると無効になります。CA は、発行された証明書を証明書失効リスト (CRL) にリストすることで、その証明書を取り消すことができます。ピア証明書の検証中に、CA サーバからローカル デバイスに CRL をダウンロードして、ピア証明書の失効ステータスをチェックします。
CA プロファイルが設定されていない場合の証明書の CRL チェックを容易にするために、動的 CA プロファイルが作成されます。動的 CA プロファイルは、 dynamic-nnn の形式でローカルデバイス上に自動的に作成されます。
動的 CA プロファイル:
- ローカルデバイスが、ピアのlocalcert発行者に従って、動的CAおよび動的CRL(対応するCA用)をダウンロードできるようにします
- ピアの証明書の失効ステータスを確認します。
VPN デバイスは、ピアの EE 証明書の失効ステータスをチェックします。VPN デバイスは、ピアから受け取った証明書を使用して 次のことを行います。
- URL を抽出して、CA の CRL を動的にダウンロードします。
- ピアの EE 証明書の失効状況を確認する
図 1 では、ホスト A はホスト B から受け取った Sales-CA 証明書と EE 証明書を使用して、Sales-CA の CRL を動的にダウンロードし、ホスト B の証明書の失効ステータスを確認できます。
単一階層 CA サーバまたは CA 証明書チェーンの場合、ローカル EE 証明書と受信したピア EE 証明書は同じ CA サーバから発行されます。
以下は、異なる構成に基づくSRXシリーズファイアウォールの動作の一部です。
- trusted-caまたはtrusted-ca-groupを使用してSRXシリーズファイアウォールを設定した場合、デバイスは他のCAを検証または信頼しません。
- SRXシリーズファイアウォールがルートCAのみを信頼し、ピアがこのルートへのサブCAによって署名された証明書を持っているCAのチェーンを持つCAプロファイルを定義している場合、動的CAとCRLがデバイスに追加されます。
表 1 に、動的 CA または CRL が作成されないシナリオ例をいくつか示します。
|
シナリオ |
条件 |
|---|---|
|
サンプル シナリオ 1 |
CA プロファイルで、ca-profile-name の信頼できる CA を定義しており、CA プロファイルで信頼できる CA として定義されていない別の CA によって署名された証明書を持つデバイスから接続を受信します。 |
|
サンプル シナリオ 2 |
SRXシリーズファイアウォールがサブCAのみを信頼し、ピアがこのサブCAより上のレベルで署名された証明書を持つCAのチェーンを持つCAプロファイルを定義していること。 |
動的 CA プロファイルを有効にするには、ルート CA プロファイルの [edit security pki ca-profile profile-name] 階層レベルで revocation-check crl オプションを設定する必要があります。
Root-CA プロファイルの失効検査プロパティーは、動的 CA プロファイルに継承されます。図 1 では、ルート CA のホスト A の CA プロファイル構成により、次の出力に示すように動的 CA プロファイルが有効になります。
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
revocation-check {
crl;
}
}
}動的 CA プロファイルは、Sales-CA のホスト A に作成されます。失効確認は、ルート CA から Sales-CA 動的 CA プロファイルに継承されます。
revocation-check disable ステートメントが Root-CA プロファイルで構成されている場合、動的 CA プロファイルは作成されず、動的 CRL のダウンロードおよびチェックは実行されません。
動的 CA プロファイルからダウンロードされた CRL のデータは、設定された CA プロファイルによってダウンロードされた CRL と同じ方法で show security pki crl コマンドで表示されます。動的 CA プロファイルからの CRL は、デバイスで設定された CA プロファイルの CRL と同様に定期的に更新されます。ピア CA 証明書は、CA サーバからダウンロードした CRL の署名検証にも必要です。
CA 証明書は、CA サーバーから受信した CRL を検証するために必要です。そのため、ピアから受信した CA 証明書は、ローカル デバイスに保存されます。ピアから受信した CA 証明書は、CRL とそれが発行した証明書を検証するために使用されます。受信した CA 証明書は管理者によって登録されていないため、ルート CA までの証明書チェーン全体が検証されるまで、証明書検証の成功結果は決定的ではありません。ルート CA の証明書は、管理者が登録する必要があります。
関連項目
例：CRL ロケーションを使用した認証局プロファイルの設定
この例では、CRL ロケーションを使用して認証局プロファイルを設定する方法を示します。
要件
開始する前に、以下を実行します。
デバイスでキーペアを生成します。デジタル証明書を参照してください。
CA に固有の情報を含む CA プロファイルを作成します。「例 ：CA プロファイルの設定.
CA から個人証明書を取得します。「例 ：ローカル証明書の CSR を手動で生成し、CA Serverに送信します。
証明書をデバイスに読み込みます。「例 ：CA 証明書とローカル証明書を手動で読み込む。
自動再登録を構成します。変更された手順については、「例：SecurIDユーザー認証の設定
必要に応じて、証明書の CRL をデバイスに読み込みます。「例 ：CRL をデバイスに手動でロードする。
概要
この例では、 my_profile と呼ばれる CA プロファイルの有効性を確認し、CRL が CA 証明書に添付されておらず、デバイスに読み込まれていない場合は、URL http://abc/abc-crl.crl から CRL を取得するようにデバイスに指示します。
設定
手順
ステップバイステップでの手順
CRL を使用して証明書を構成するには:
CA プロファイルと URL を指定します。
[edit] user@host# set security pki ca-profile my_profile revocation-check crl url http://abc/abc-crl.crl
デバイスの設定が完了したら、設定をコミットします。
[edit] user@host# commit
検証
設定が正常に機能していることを確認するには、 show security pki operational mode コマンドを入力します。
例：証明書の有効性の確認
この例では、証明書の有効性を確認する方法を示します。
要件
この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。
概要
この例では、証明書を手動で検証して、証明書が失効していないかどうか、またはローカル証明書の作成に使用されたCA証明書がデバイスに存在しないかどうかを確認します。
証明書を手動で検証する場合、デバイスは CA 証明書(ca-cert)を使用してローカル証明書( local.cert)を検証します。ローカル証明書が有効で、CA プロファイルで revocation-check が有効になっている場合、デバイスは CRL が読み込まれて有効であることを確認します。CRL が読み込まれておらず、有効な場合、デバイスは新しい CRL をダウンロードします。
CA 発行の証明書または CA 証明書の場合、デバイスの設定で DNS を設定する必要があります。DNS は、配布 CRL および CA プロファイル構成の CA 証明書/失効リスト URL でホストを解決できる必要があります。さらに、チェックを受信するためには、同じホストへのネットワーク到達可能性が必要です。
設定
手順
ステップバイステップでの手順
証明書の有効性を手動で確認するには:
ローカル証明書の有効性を検証します。
[edit] user@host> request security pki local-certificate verify certificate-id local.cert
CA 証明書の有効性を確認します。
[edit] user@host> request security pki ca-certificate verify ca-profile ca-profile-ipsec
関連付けられた秘密キーと署名も検証されます。
検証
設定が正常に機能していることを確認するには、 show security pki ca-profile コマンドを入力します。
肯定的な検証ではなくエラーが返された場合、その失敗は pkid に記録されます。
ロードされたCRLの削除(CLIプロシージャ)
読み込まれた CRL を、証明書の失効と検証の管理に使用する必要がなくなった場合は、削除することを選択できます。
次のコマンドを使用して、読み込まれた証明書失効リストを削除します。
user@host> clear security pki crl ca-profile (ca-profile all)
CA プロファイルを指定して、プロファイルによって識別される CA に関連付けられている CRL を削除するか、 all を使用してすべての CRL を削除します。