Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

証明書の失効

デジタル証明書には有効期限がありますが、有効期限が切れる前に、多くの理由で証明書が無効になっている可能性があります。証明書の revocations と検証をローカルで管理したり、認証局 (CA) 証明書失効リスト (CRL) を参照したりすることができます。

オンライン証明書ステータスプロトコルと証明書失効リストについて

OCSP は、X509 証明書の失効ステータスを確認するために使用されます。OCSP では、証明書の失効ステータスをリアルタイムで提供します。これは、銀行トランザクションや株式取引などの時間的に影響のある状況で役に立ちます。

証明書の失効ステータスは、SRX シリーズデバイスの外部にある OCSP サーバーに要求を送信することでチェックされます。サーバーからの応答に基づいて、VPN 接続が許可または拒否されます。OCSP 応答は、SRX シリーズデバイスでキャッシュされません。

OCSP サーバーは、証明書を発行する証明機関 (CA)または指定された承認済みレスポンダーとすることができます。OCSP サーバーの場所は、手動で設定するか、または検証する証明書から抽出できます。最初に要求は、[ ocsp urledit security pki ca-profile profile-name revocation-check] 階層レベルのステートメントで CA プロファイルに手動で設定された OCSP サーバーロケーションに送信されます。各 CA プロファイルに対して、最大2つの場所を設定できます。最初に構成された OCSP サーバーにアクセスできない場合、その要求は2番目の OCSP サーバーに送信されます。2 番目の OCSP サーバーに到達できない場合は、証明書の AuthorityInfoInfo の拡張フィールド内の場所にリクエストが送信されます。このuse-ocspオプションは、証明書失効リスト (CRL)がデフォルトのチェック方法である場合にも設定する必要があります。

SRX シリーズデバイスは、CA または許可された応答側からの、署名済み OCSP 応答のみ受け付けます。受信した応答は、信頼された証明書を使用して検証されます。応答は次のように検証されます。

  1. 設定された CA プロファイル用に登録された CA 証明書を使用して、応答を検証します。

  2. 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されます。

リプレイ攻撃を阻止するために、 nonceペイロードを OCSP 要求で送信できます。デフォルトでは、Nonce ペイロードは明示的に無効になっていない限り送信されます。有効にした場合、SRX シリーズデバイスは OCSP の応答に nonce ペイロードを含めることを想定します。それ以外の場合、失効チェックは失敗します。OCSP レスポンダーが nonce ペイロードで応答できない場合は、SRX シリーズデバイスで nonce ペイロードを無効にする必要があります。

通常のビジネスでは、さまざまな理由で証明書が失効しています。たとえば、証明書が侵害された疑いがある場合、または証明書の所有者が退職した場合などには、認証を無効にすることをお勧めします。

証明書の revocations と検証は、次の2つの方法で管理できます。

  • ローカル: これは限定的なソリューションです。

  • 認証機関(CA)証明書失効リスト(CA)を参照することで、指定した間隔または認証機関によって設定されたデフォルトの間隔で、オンラインで自動的にこの権限を確認CA。

フェーズ 1 のネゴシエーションでは、参加者は、このリストでこのリストをオンにし、認証交換中に受けIKEを確認します。CRL が CA 証明書に付属しておらず、デバイスにロードされていない場合、デバイスはローカル証明書の CRL 配布ポイントから自動的にダウンロードを試みます。デバイスが証明書配布ポイント (CDP) 内の URL に接続できなかった場合は、CA プロファイルに設定されている URL から CRL を取得しようとします。

証明書に証明書配布ポイントの拡張機能が含まれておらず、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 を読み込む方法を示しています。

要件

開始する前に:

  1. パブリックおよび秘密鍵ペアを生成します。「 自己署名証明書 」を参照してください

  2. 証明書要求を生成します。例をご覧ください。CSR を手動でローカル証明書に生成し、それを CA サーバーに送信します。

  3. 認証機関 (CA) プロファイルを設定します。例をご覧ください。CA プロファイルを構成しています。

  4. 証明書をデバイスにロードします。例をご覧ください。CA とローカル証明書を手動で読み込みます。

概要

CRL を手動で読み込むか、または証明書の有効性を確認したときにデバイスが自動的にロードされるようにすることができます。CRL を手動でロードするには、CA から CRL を取得し、それをデバイスに転送します (たとえば、FTP を使用します)。

この例では、デバイスの/var/tmp ディレクトリからrevoke.crl呼び出される CRL 証明書をロードします。CA プロファイルが呼び出さca-profile-ipsecれます。(最大ファイルサイズは 5 MB です)

CRL が ca プロファイルにすでにロードされているclear security pki crl ca-profile ca-profile-ipsec場合、そのコマンドを最初に実行して古い crl をクリアする必要があります。

構成

手順

順を追った手順

CRL 証明書を手動でロードするには、次のようにします。

  1. CRL 証明書をロードします。

    Junos OS は、X509、PKCS #7、DER、または PEM 形式での CA 証明書の読み込みをサポートします。

検証

構成が正常に機能していることをshow security pki crl確認するには、運用モードコマンドを入力します。

動的 CRL のダウンロードとチェックについて

デジタル証明書は一定期間にわたって発行され、指定された有効期限の後は無効になります。CA は、発行された証明書を証明書失効リスト (CRL) に登録することで失効させることができます。ピア証明書の検証において、ピア証明書の失効ステータスは、CA サーバーからローカルデバイスに CRL をダウンロードすることでチェックされます。

VPN デバイスは、ピアの証明書の失効ステータスを確認できる必要があります。デバイスが証明書を使用CA

URLを抽出してそのピアから受信した情報CAのSNURLを動的にダウンロードし、ピアの証明書の失効ステータスを確認します。ダイナミック CA プロファイルは、ローカルデバイス上でフォーマットdynamic-nnnとともに自動的に作成されます。動的 CA プロファイルを使用すると、ローカル デバイスはピアの CA から THE をダウンロードし、ピアの証明書の失効ステータスを確認できます。では 図 1 、Host-A は、Host-B から受け取った Sales-CA 証明書と EE 証明書を使用して、Sales-CA 用にこの賞を動的にダウンロードし、ホスト B の証明書の失効ステータスを確認できます。

図 1: 証明書ベースの認証用のマルチレベル階層証明書ベースの認証用のマルチレベル階層

動的 CA プロファイルを有効にするrevocation-check crlには、このオプションを [edit security pki ca-profile profile-name] 階層レベルの親 CA プロファイルで設定する必要があります。

親 CA プロファイルの失効チェックのプロパティは、動的 CA プロファイルに対して継承されます。で図 1は、Host A for Root-CA の CA プロファイル構成により、動的な CA プロファイルが有効になります。以下の出力が表示されます。

動的 CA プロファイルは、販売 CA のために Host A 上に作成されます。失効チェックは、ルート CA からの CA ダイナミック CA プロファイルに対して継承されます。

revocation-check disableステートメントが親 CA プロファイルで構成されている場合、動的 CA プロファイルは作成されず、CRL の動的ダウンロードとチェックは実行されません。

ダイナミック CA プロファイルからダウンロードされた Crl のデータは、 show security pki crl設定した CA プロファイルによってダウンロードされた crl と同じようにコマンドとともに表示されるようになっています。動的 CA プロファイルの CRL は、デバイスに設定されている CA プロファイルのものと同じように定期的に更新されます。

CA 証明書は、CA サーバーから受信した CRL を検証するために必要です。そのため、ピアから受信した CA 証明書は、ローカルデバイスに格納されています。CA 証明書は管理者によって登録されていないため、CA サーバーから受信した CRL を検証するためだけに使用され、ピア証明書を検証するためのものではありません。

例:CRL の場所を使用して証明機関プロファイルを構成する

この例では、CRL の場所を使用して証明機関プロファイルを設定する方法を示します。

要件

開始する前に:

  1. デバイスに鍵ペアを生成します。デジタル 証明書を参照してください

  2. CA に固有の情報を含む CA プロファイルを作成します。例をご覧ください。CA プロファイルを構成しています。

  3. CA から個人証明書を取得します。例をご覧ください。CSR を手動でローカル証明書に生成し、それを CA サーバーに送信します。

  4. 証明書をデバイスに読み込みます。例をご覧ください。CA とローカル証明書を手動で読み込みます。

  5. 自動 reenrollment を構成します。例をご覧ください。SecurID ユーザー認証を構成します。

  6. 必要に応じて、デバイスに証明書の入ったSLファイルをロードします。例をご覧ください。デバイスに手動で CRL をロードします。

概要

フェーズ1ネゴシエーションでは、CRL リストをチェックして、IKE 交換中に受信した証明書が有効かどうかを確認します。CRL が CA 証明書に付属しておらず、デバイスにロードされていない場合、Junos OS は、CA 証明書自体に定義されている LDAP または HTTP CRL の場所を使用して CRL を取得しようとします。CA 証明書で URL アドレスが定義されていない場合、デバイスはその CA 証明書用に定義したサーバーの URL を使用します。特定の CA 証明書の CRL URL が定義されていない場合、デバイスは CA プロファイル構成の URL から CRL を取得します。

X509 証明書に含まれる CRL 配布ポイント拡張 (cdp) は、HTTP URL または LDAP URL に追加できます。

この例では、デバイスを使用して、呼び出されmy_profileた CA プロファイルを確認し、CRL が URL http://abc/abc-crl.crlから crl を取得するために、CA の証明書に含まれていない場合、デバイスにロードされていない場合には、それを検証します。

構成

手順

順を追った手順

CRL を使用して証明書を設定するには

  1. CA プロファイルと URL を指定します。

  2. デバイスの設定が完了したら、構成をコミットします。

検証

構成が正常に機能していることをshow security pki確認するには、運用モードコマンドを入力します。

例:証明書の有効性の検証

この例では、証明書の有効性を検証する方法について説明します。

要件

この機能を設定する前に、デバイス初期化以外の特別な設定は不要です。

概要

この例では、証明書を手動で検証して、証明書が失効しているかどうか、またはローカル証明書の作成に使用された CA 証明書がデバイス上に存在しないかどうかを確認します。

証明書を手動で検証すると、デバイスは CA 証明ca-cert書 () を使用してlocal.certローカル証明書 () を検証します。ローカル証明書が有効で、CA プロファイルrevocation-checkで有効になっている場合、デバイスは CRL がロードされて有効であることを確認します。CRL がロードされていない場合、有効な場合、デバイスは新しい CRL をダウンロードします。

サーバー CA発行された証明書または証明書CA、デバイスの設定で DNS を設定する必要があります。DNS は、配布 CRL の中でホストを解決でき、CA プロファイル構成の CA cert/失効リスト url に含まれている必要があります。さらに、チェックを受信するには、同じホストにネットワークに到達する必要があります。

構成

手順

順を追った手順

証明書の有効性を手動で確認するには、次のようにします。

  1. ローカルの証明書が有効であることを確認します。

  2. CA 証明書の有効性を検証します。

    関連付けられている秘密キーと署名も検証されます。

検証

構成が正常に機能していることをshow security pki ca-profile確認するには、コマンドを入力します。

正の検証ではなくエラーが返された場合、エラーは pkid に記録されます。

ロードされた CRL (CLI プロシージャ) の削除

ロードされた CRL を使用して証明書の revocations と検証を管理する必要がなくなった場合は、それを削除することもできます。

次のコマンドを使用して、ロードされた証明書失効リストを削除します。

CA プロファイルを指定して、プロファイルによって識別される CA に関連付けらallれている crl を削除するか、すべての crl を削除するために使用します。