Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

証明書の失効

さまざまな PKI 証明書を取り消す方法について説明します。

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

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

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

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

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

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 証明書を使用して検証されます。

リプレイ攻撃を防ぐために、 OCSP 要求で nonce ペイロードを送信できます。Nonce ペイロードは、明示的に無効にしない限り、デフォルトで送信されます。有効にすると、SRXシリーズファイアウォールはOCSP応答にnonceペイロードが含まれると予測し、そうでない場合は失効チェックが失敗します。OCSPレスポンダがnonceペイロードで応答できない場合、SRXシリーズファイアウォールでnonceペイロードを無効にする必要があります。

通常の業務では、証明書はさまざまな理由で失効します。証明書が侵害された疑いがある場合や、証明書所有者が退職した場合などは、証明書を失効させることができます。

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

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

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

フェーズ1のネゴシエーションでは、SRXシリーズファイアウォールはIKE交換中にピアから受信したEE証明書を検証し、CRLを使用してEE証明書がCAによって取り消されていないことを確認します。

CRL がデバイスに読み込まれておらず、ピア証明書の発行者が信頼できる CA である場合:

  1. Junos OS は、設定された LDAP または HTTP CRL の場所(つまり、CRL 配布ポイント(CDP))を介して CRL を取得します(CA プロファイルで定義されている場合)。
  2. CRL 配布ポイントが CA プロファイルで設定されていない場合、デバイスは CA が発行した証明書の CDP 拡張を使用します(存在する場合)。CA によって発行される証明書は、管理者によって登録された証明書、またはフェーズ 1 ネゴシエーション中に受信された証明書です。

EE 証明書がルート CA によって発行されていない場合、各中間 CA の証明書は、同じ検証および失効検査を受けます。ルート CA の CRL は、ルート CA によって発行された証明書が失効しているかどうかを確認するために使用されます。ルート CA プロファイルで CDP が設定されていない場合、デバイスは 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 をデバイスに手動で読み込む方法を示しています。

必要条件

開始する前に、以下を実行します。

  1. 公開鍵と秘密鍵のペアを生成します。 「自己署名デジタル証明書」を参照してください。

  2. 証明書要求を生成します。 例:CA プロファイルの設定を参照してください。

  3. 認証局(CA)プロファイルを設定します。 例:CA プロファイルの設定を参照してください。

  4. 証明書をデバイスに読み込みます。 「例: CA 証明書とローカル証明書を手動で読み込む」を参照してください。

概要

証明書の有効性を検証するときに、CRL を手動で読み込むことも、デバイスに自動的に読み込ませることもできます。CRL を手動で読み込むには、CA から CRL を取得し、デバイスに転送します(たとえば、FTP を使用)。

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

CRL がすでに ca-profile にロードされている場合、古い CRL をクリアするには、まず clear security pki crl ca-profile ca-profile-ipsec コマンドを実行する必要があります。

構成

プロシージャ

手順

CRL 証明書を手動で読み込むには、次のようにします。

  1. CRL 証明書を読み込みます。

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

検証

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

動的CRLのダウンロードと検証

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

CA プロファイルが設定されていない場合に証明書の CRL チェックを容易にするために、動的 CA プロファイルが作成されます。動的CAプロファイルは、 dynamic-nnnの形式でローカルデバイス上に自動的に作成されます。

動的 CA プロファイル:

  • ローカル デバイスが、ピアの localcert 発行者ごとに動的 CA と動的 CRL(対応する CA 用)をダウンロードすることを許可します
  • ピアの証明書の失効ステータスを確認します

VPN デバイスは、ピアの EE 証明書の失効状況を確認します。VPN デバイスは、ピアから受信した証明書を使用して、次のことを行います。

  • URL を抽出して、CA の CRL を動的にダウンロードする
  • ピアの EE 証明書の失効状況を確認します

図 1 では、Host-A は、Host-B から受信した Sales-CA 証明書と EE 証明書を使用して、Sales-CA の CRL を動的にダウンロードし、Host-B の証明書の失効状況を確認できます。

図 1: 証明書ベースの認証Multilevel Hierarchy for Certificate-Based Authenticationのマルチレベル階層

単一階層の CA サーバーまたは CA 証明書チェーンの場合、ローカル EE 証明書と受信したピア EE 証明書は、同じ CA サーバーから発行されます。

以下に、さまざまな構成に基づくSRXシリーズファイアウォールの動作の一部を示します。

  • trusted-caまたはtrusted-ca-groupでSRXシリーズファイアウォールを設定した場合、デバイスは他のCAを検証または信頼しません。
  • SRXシリーズファイアウォールがルートCAのみを信頼するCAのチェーンを持つCAプロファイルを定義し、ピアにこのルートへのサブCAによって署名された証明書がある場合、動的CAとCRLがデバイスに追加されます。

表 1 に、動的 CA または CRL が作成されないいくつかのサンプル シナリオを示します。

表 1: サンプル シナリオ

シナリオ

条件

サンプル シナリオ 1

CA プロファイルで、ca-profile-name に信頼できる CA を定義しており、CA プロファイルで信頼できる CA として定義されていない別の CA によって署名された証明書を持つデバイスから接続を受信します。

サンプル シナリオ 2

SRXシリーズファイアウォールがサブCAのみを信頼するCAのチェーンを持つCAプロファイルを定義し、ピアにこのサブCAより上位のレベルによって署名された証明書がある。

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

ルート CA プロファイルの失効チェック プロパティは、動的 CA プロファイルに継承されます。 図 1 では、Root-CA の Host-A の CA プロファイル設定により、以下の出力に示すように動的 CA プロファイルが有効になっています。

Sales-CA の動的 CA プロファイルが Host-A に作成されます。失効チェックは、Sales-CA 動的 CA プロファイルの Root-CA から継承されます。

revocation-check disable ステートメントがルート 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 の場所を使用して認証局プロファイルを構成する方法を示します。

必要条件

開始する前に、以下を実行します。

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

  2. CA プロファイルまたは CA に固有の情報を含むプロファイルを作成します。 例:CA プロファイルの設定を参照してください。

  3. CA から個人証明書を取得します。 例:ローカル証明書の CSR を手動で生成して CA サーバに送信するを参照してください。

  4. 証明書をデバイスに読み込みます。 「例: CA 証明書とローカル証明書を手動で読み込む」を参照してください。

  5. 自動再登録を構成します。 「例:SecurIDユーザー認証の設定」を参照してください。

  6. 必要に応じて、証明書の CRL をデバイスに読み込みます。 例: CRL をデバイスに手動で読み込むを参照してください。

概要

この例では、 my_profile と呼ばれる CA プロファイルの有効性をチェックするようにデバイスに指示し、CRL が CA 証明書に付随しておらず、デバイスにロードされていない場合は、URL http://abc/abc-crl.crl から CRL を取得するように指示します。

構成

プロシージャ

手順

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-profile 設定の CA 証明書/失効リスト URL でホストを解決できる必要があります。さらに、チェックを受信するためには、同じホストにネットワーク到達可能である必要があります。

構成

プロシージャ

手順

証明書の有効性を手動で確認するには、次の手順に従います。

  1. ローカル証明書の有効性を検証します。

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

    関連付けられた秘密鍵と署名も検証されます。

検証

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

肯定的な検証の代わりにエラーが返された場合、その失敗は pkid に記録されます。

読み込まれたCRLの削除(CLI手順)

読み込まれた CRL を証明書の失効と検証の管理に使用する必要がなくなった場合は、その CRL を削除することを選択できます。

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

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