Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

デジタル証明書

詳しくは、デジタル証明書についての記事をご覧ください。詳しくは、デジタル証明書の設定方法をご覧ください。

デジタル証明書は、認証局(CA)と呼ばれる信頼できるサードパーティを通じて本人確認を行うための電子的な手段です。または、自己署名証明書を使用して ID を証明することもできます。

証明書の手動処理には、PKCS10 リクエストの生成、CA への送信、署名付き証明書の取得、ジュニパーネットワークス デバイスへの証明書の手動読み込みが含まれます。展開環境に基づいて、オンライン証明書登録に SCEP または CMPv2 を使用できます。

セキュアな VPN 接続を確立する際にデジタル証明書を使用して ID を認証するには、まず次のことを行う必要があります。

  • ローカル証明書を取得する CA 証明書を取得し、その CA 証明書をデバイスにロードします。CA 証明書には、無効な証明書を識別するための CRL を含めることができます。

  • 以前に CA 証明書を読み込んだ CA からローカル証明書を取得し、そのローカル証明書をデバイスに読み込みます。ローカル証明書は、各トンネル接続でジュニパーネットワークスデバイスのIDを確立します。

デジタル証明書の手動生成:設定の概要

デジタル証明書を手動で取得するには、次の手順を実行します。

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

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

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

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

  5. 自動再登録を構成します。 「例:SCEP を使用したローカル証明書の自動更新」を参照してください。

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

  7. 必要に応じて、CRL の場所を使用して CA プロファイルを設定します。 例:CRLロケーションを使用した認証局プロファイルの設定を参照してください。

Junos OSのデジタル証明書

小規模なネットワークでは、多くの場合、IPSec 構成で事前共有キーを使用するだけで十分です。しかし、ネットワークが拡大するにつれて、ローカルルーターやすべての新規および既存のIPSecピアに新しい事前共有キーを追加することが困難になることがあります。IPSec ネットワークを拡張するための解決策の 1 つは、デジタル証明書を使用することです。

デジタル証明書の実装では、公開鍵基盤 (PKI) を使用するため、公開鍵と秘密鍵で構成される鍵ペアを生成する必要があります。キーは乱数ジェネレーターで作成され、データの暗号化と復号化に使用されます。デジタル証明書を使用しないネットワークでは、IPSec 対応デバイスが秘密キーでデータを暗号化し、IPSec ピアが公開キーでデータを復号化します。

デジタル証明書を使用すると、鍵共有プロセスにさらに複雑なレベルが必要になります。まず、ユーザーと IPSec ピアは、CA の公開キーを含む CA 証明書を送信するよう、認証局 (CA) に要求します。次に、公開鍵と追加情報を含むローカルのデジタル証明書を登録するよう CA に要求します。CA は、要求を処理するときに、CA の秘密キーを使用してローカル証明書に署名します。次に、CA 証明書とローカル証明書をローカル ルーターにインストールし、CA 証明書をリモート デバイスにロードしてから、ピアとの IPSec トンネルを確立します。

IPSec ピアとのピアリング関係を要求すると、ピアはローカル証明書のコピーを受け取ります。ピアにはすでに CA 証明書がロードされているため、CA 証明書に含まれる CA の公開キーを使用して、CA の秘密キーによって署名されたローカル証明書を復号化できます。その結果、ピアに公開鍵のコピーが保持されます。ピアは、データを送信する前に公開鍵でデータを暗号化します。ローカルルーターがデータを受信すると、プライベートキーでデータを復号化します。

Junos OS では、デジタル証明書を最初に使用するには、次の手順を実装する必要があります。

  • CA およびローカルのデジタル証明書を要求する CA プロファイルを構成する—プロファイルには、CA または RA(登録機関)の名前と URL、および再試行タイマーの設定が含まれています。

  • 証明書失効リストのサポートを構成する - 証明書失効リスト(CRL)には、有効期限前にキャンセルされた証明書のリストが含まれています。参加ピアが CRL を使用する場合、CA は最後に発行された CRL を取得し、ピアのデジタル証明書の署名と有効性をチェックします。CRL を手動で要求してロードしたり、CRL 処理を自動的に処理するように LDAP サーバーを構成したり、デフォルトで有効になっている CRL 処理を無効にしたりできます。

  • CA にデジタル証明書を要求する—要求は、オンラインまたは手動で行うことができます。オンライン CA デジタル証明書要求は、Simple Certificate Enrollment Protocol (SCEP) 形式を使用します。CA 証明書を手動で要求する場合は、証明書も手動で読み込む必要があります。

  • 秘密鍵と公開鍵のペアを生成—公開鍵はローカルデジタル証明書に含まれており、秘密鍵はピアから受信したデータの復号に使用されます。

  • ローカル デジタル証明書の生成と登録 - ローカル証明書は、SCEP を使用してオンラインで処理するか、PKCS-10(公開鍵暗号標準 #10)形式で手動で生成できます。ローカル証明書要求を手動で作成する場合は、証明書も手動で読み込む必要があります。

  • IPSec 設定へのデジタル証明書の適用—ローカル デジタル証明書をアクティブ化するには、事前共有キーの代わりにデジタル証明書を使用するように IKE の提案 を設定し、IKE ポリシーでローカル証明書を参照し、サービス セットで CA を識別します。

必要に応じて、次の操作を実行できます。

  • 自動的に再登録するようにデジタル証明書を構成する—Junos OS リリース 8.5 以降、デジタル証明書の自動再登録を設定できるようになりました。

  • デジタル証明書イベントを監視し、証明書と要求を削除する—動作モードコマンドを発行して、デジタル証明書を使用して確立されたIPSecトンネルを監視し、証明書または要求を削除できます。

ルート CA 証明書の生成

CLIで自己署名証明書を定義するには、次の詳細を指定する必要があります。

  • 証明書識別子 (前の手順で生成)

  • 証明書の完全修飾ドメイン名 (FQDN)

  • 証明書を所有するエンティティの電子メール アドレス

  • 通称と関係する組織

Junos OS CLIを使用して、ルートCA証明書を生成します。

  1. 運用モードから、ローカルデジタル証明書のPKI公開キー/プライベートキーペアを生成します。

    ここでは、次の組み合わせのいずれかを選択できます。

    • 1024 ビット(RSA/DSA のみ)

    • 2048 ビット (RSA/DSA のみ)

    • 256 ビット(ECDSA のみ)

    • 384 ビット(ECDSA のみ)

    • 4096 ビット(RSA/DSA のみ)

    • 521ビット(ECDSAのみ)

    例：

    または
  2. 自己署名証明書を定義します。

    例：

    add-ca-constraint オプションを設定することで、その証明書を他の証明書の署名に使用できるようにします。

  3. 設定モードから、読み込んだ証明書を SSLプロキシプロファイルのroot-caとして適用します。

    例：

  4. ルート CA を信頼できる CA としてクライアント ブラウザにインポートします。ルートCA証明書は、クライアントブラウザがSRXシリーズファイアウォールによって署名された証明書を信頼するために必要です。

自己署名SSL証明書の手動生成

デバイスの自己署名 SSL 証明を手動で生成するには:

  1. 基本的な接続性を確立します。
  2. rootログインアクセス権がある場合は、次のコマンドを使用して自己署名証明書を手動で生成できます。

    証明書を生成するときは、件名、電子メール アドレス、および domain-name または ip-address を指定する必要があります。

  3. 証明書が正しく生成され、読み込まれたことを確認するには、 show security pki local-certificate 運用コマンドを入力し、HTTPS Web 管理で local-certificate を指定します。

指定した場所への証明書のエクスポート

PKI コマンドを使用して自己署名証明書を生成すると、新しく生成された証明書は事前定義された場所 (var/db/certs/common/local) に保存されます。

次のコマンドを使用して、証明書を特定の場所(デバイス内)にエクスポートします。証明書ID、ファイル名、およびファイル形式のタイプ(DER/PEM)を指定できます。

ルート CA 証明書を構成する

CA は、ツリー構造の形式で複数の証明書を発行できます。ルート証明書はツリーの最上位の証明書であり、その秘密鍵は他の証明書 sign ために使用されます。ルート証明書のすぐ下にあるすべての証明書は、ルート証明書の署名または信頼性を継承します。これは、アイデンティティの notarizing にいくらか似ています。

ルート CA 証明書を設定するには、次のことを行う必要があります。

  1. ルート CA 証明書の取得 (またはインポート)

    • SRXシリーズファイアウォールでJunos OS CLIを使用して、ルートCA証明書を生成できます。

    • 外部 CA から証明書を取得します (このトピックでは説明しません)。

  2. SSL プロキシ プロファイルへのルート CA の適用。

証明書チェーンの実装

Junos OS リリース 15.1X49-D30 以降、SSL フォワード プロキシは証明書チェーンの実装をサポートします。証明書チェーンの概念の理解と、SRXシリーズファイアウォールでの設定方法について説明します。

  • Certificate Authority (CA)— CAは、エンティティ(Webサイト、電子メールアドレス、企業、個人など)のIDの検証を担当する信頼できるサードパーティであり、暗号化キーをバインドしてデジタル証明書を発行します。組織が CA サーバーを所有している場合は、独自の CA になり、自己署名証明書を使用します。

  • Root Certificate- ルート証明書は、信頼できる認証局(CA)によって発行された証明書です。ルート証明書はツリーの最上位の証明書であり、その秘密鍵は他の証明書に署名するために使用されます。ルート証明書のすぐ下にあるすべての証明書は、ルート証明書の署名または信頼性を継承します。これらの証明書は、2 つのエンドポイント間の接続を確立するために使用されます。

  • Intermediate CA Certificate—中間 CA 証明書は、特にエンドエンティティ証明書を検証するために信頼されたルートによって署名された下位証明書です。

  • Certificate Chain - 証明書チェーンは、SSL 証明、中間証明書、およびルート証明書を含む証明書の順序付きリストです。一部の認証局 (CA) は、ルート証明書で署名せず、代わりに中間証明書を使用します。中間 CA は、ルート CA 証明書の代わりに証明書に署名できます。ルート CA は中間証明書に署名し、信頼チェーンを形成します。

    中間証明書は、接続するデバイス(ブラウザー、アプリケーション、モバイルデバイスなど)が信頼できるように、SSL 証明と同じサーバーにインストールする必要があります。

接続を開始すると、接続デバイス(ブラウザーなど)は、証明書が本物であり、ブラウザーの信頼できるストアに埋め込まれている信頼できる証明機関によって発行されているかどうかを確認します。

SSL 証明が信頼できる CA からのものではない場合、接続デバイスは、SSL 証明が中間 CA によって発行され、この中間 CA がルート CA によって署名されているかどうかを引き続き確認します。チェックは、ルート CA が見つかるまで続行されます。ルートCAが見つかると、安全な接続が確立されます。ルート CA が見つからない場合、接続は切断され、Web ブラウザーには、無効な証明書または信頼されていない証明書に関するエラー メッセージが表示されます。

SSL 開始をサポートする証明書チェーン

SSL プロキシー・モードでは、サーバーは証明書チェーンの検証のために、中間証明書を含む完全な証明書チェーンをクライアントに送信します。

非プロキシー・モードでは、SSL 開始フェーズ中に、クライアントは要求に応じてクライアント証明書のみをサーバーに送信します。次に、サーバーは、信頼できる認証局 (CA) のリストをインポートして、クライアント証明書を認証する必要があります。

24.2R1以降、SSLの開始時に、SRXシリーズデバイスは証明書チェーンを生成し、クライアント証明書とともにサーバーに送信します。SSL 開始の証明書チェーンにより、サーバーはチェーンの中間 CA をインポートしなくても、証明書チェーンを検証できます。

この例では、証明書チェーンをインストールして、ブラウザーが証明書を信頼できるようにする方法を示します。

必要条件

この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。

概要

この例では、example.domain-1 というドメインがあり、ドメインの証明書を XYZ-Authority から購入します。ただし、XYZ -Authority は Root-CA ではなく、アクセス先のブラウザは Root-CA 証明書のみを信頼します。つまり、その証明書はブラウザに直接埋め込まれていないため、明示的に信頼されていません。

この場合、(中間証明書の)証明書チェーンを使用して、次の方法で信頼が確立されます。

位相幾何学

図 1 でこの連鎖を視覚化してみましょう。この図は、ルートCA証明書からエンドユーザー証明書までの完全な証明書チェーンを示しています。チェーンは、エンド ユーザー証明書で終了します。

図 1: 証明書の所有者からルート CA Certification Path from the Certificate Owner to the Root CAへの証明書パス
表 1: 証明書チェーンの詳細

利用者

証明書を使用

署名者

種類

example.domain-1 (英語)

エンドユーザー証明書

XYZ機関

エンドユーザー証明書。CAから購入したものです。

XYZ機関

証明書-1

中間CA-1

中間証明書

中間CA-1

証明書-2

中間体 CA-2

中間証明書

中間体 CA-2

証明書-3

中間CA-3

中間証明書

中間CA-3

証明書-4

root-example-authorityです。これはルート CA です。

ルート証明書

その証明書はブラウザに直接埋め込まれています。したがって、明示的に信頼できます。

サーバー example.domain-1 のエンドユーザ証明書をインストールする場合は、すべての中間証明書をバンドルし、エンドユーザ証明書と一緒にインストールする必要があります。証明書チェーンには、証明書 1 からルート CA 証明書までのすべての証明書が含まれます。Web ブラウザはルート CA を信頼するため、すべての中間証明書も暗黙的に信頼します。SSL 証明チェーンが無効または破損している場合、証明書は一部のデバイスで信頼されません。

すべての証明書は、Privacy-Enhanced Mail(PEM)形式である必要があります。

連結された証明書ファイルをデバイスにインポートすると、CA は、署名されたサーバー証明書に追加する必要があるチェーン証明書のバンドルを提供します。サーバー証明書は、結合されたファイル内でチェーンされた証明書の前に表示する必要があります。

構成

SSL 証明チェーンの構成には、次のタスクが含まれます。

  • 署名証明書とそれぞれのキーを含む SSL 証明を CA から購入します。

  • 信頼できる CA プロファイル グループを設定します。

  • 署名証明書とキーをデバイスに読み込みます。

  • 中間 CA とルート CA を公開鍵基盤(PKI)メモリに読み込みます。この証明書ファイルには、必要なすべての CA 証明が PEM 形式で 1 つずつ含まれています。

  • 中間 CA 証明書またはルート CA 証明書の信頼できる CA プロファイルを作成します。

  • SSL プロキシ プロファイルを構成し、セキュリティ ポリシーに適用することで、CA から受信した署名証明書を使用するようにデバイスを設定します。SSL フォワード プロキシは、この証明書チェーン情報(CA 証明書プロファイル名)をそれぞれの SSL プロファイルに格納します。セキュリティ ポリシーの実装の一環として、証明書チェーン情報と CA 証明を持つ SSL プロファイルが使用されます。

証明書チェーン処理には、次のコンポーネントが含まれます。

  • 管理者は、証明書チェーンとローカル証明書(署名証明書)をPKI証明書キャッシュにロードします。

  • ネットワーク セキュリティ (nsd) は、SSL プロキシ プロファイルで構成された署名証明書の証明書チェーン情報を提供する要求を PKI に送信します。

この例では、すでに CA から SSL 証明を購入していることを前提としています。

デバイスでの証明書チェーンの設定

手順

証明書チェーンを設定するには:

  • ローカル証明書を PKI メモリにロードします。

    次のメッセージが表示されます。

    この証明書IDは、SSL プロキシ プロファイルの root-ca セクションで使用されることに注意してください。

  • 中間 CA 証明書またはルート CA 証明書を PKI メモリに読み込みます。

    CA プロファイルには、認証に使用される証明書情報が含まれています。これには、SSLプロキシが新しい証明書を生成するときに使用する公開キーが含まれています。

    この証明書は、証明書チェーンとして添付されます。

  • CA プロファイル グループを SSL プロキシ プロファイルにアタッチします。信頼できる CA を一度に 1 つずつアタッチすることも、すべてを 1 つのアクションで読み込むこともできます。

  • SSL プロキシ プロファイルで署名証明書を root-ca として適用します。

  • セキュリティ ポリシーを作成し、ポリシーの一致条件を指定します。一致条件として、SSLプロキシーを有効にするトラフィックを指定します。この例では、要件に基づいてセキュリティ ゾーンがすでに作成されていることを前提としています。

    SSL フォワード プロキシは、この証明書チェーン情報(CA 証明書プロファイル名)をそれぞれの SSL プロファイルに格納します。セキュリティ ポリシーの実装の一環として、証明書チェーン情報と CA 証明を持つ SSL プロファイルが使用されます。

    証明書チェーンは、接続しているブラウザ(つまりクライアント)で表示できます。

デジタル証明書の設定

デジタル証明書の概要

デジタル証明書は、認証局 (CA) と呼ばれる信頼できる第三者を通じてユーザーを認証する方法を提供します。CA は、証明書所有者の ID を検証し、証明書が偽造または変更されていないことを証明するために証明書に「署名」します。

証明書には、次の情報が含まれています。

  • 所有者の識別名(DN)。DNは意の識別子であり、所有者の共通名(CN)、所有者の組織、およびその他の識別情報を含む完全修飾名で構成されます。

  • 所有者の公開キー。

  • 証明書が発行された日付。

  • 証明書の有効期限が切れる日付。

  • 発行元 CA の識別名。

  • 発行元 CA のデジタル署名。

証明書の追加情報により、受信者は証明書を受け入れるかどうかを決定できます。受信者は、有効期限に基づいて、証明書がまだ有効かどうかを判断できます。受信者は、発行元の CA に基づいて、CA がサイトによって信頼されているかどうかを確認できます。

証明書では、CA は所有者の公開キーを取得し、その公開キーに独自の秘密キーで署名し、これを証明書として所有者に返します。受信者は、所有者の公開キーを使用して証明書(CAの署名を含む)を抽出できます。CA の公開キーと抽出された証明書の CA の署名を使用して、受信者は CA の署名と証明書の所有者を検証できます。

デジタル証明書を使用する場合、最初に CA から証明書を取得する要求を送信します。次に、デジタル証明書とデジタル証明書IKEポリシーを設定します。最後に、CA からデジタル署名された証明書を取得します。

手記：

代替サブジェクト名のない証明書は、IPsec サービスには適していません。

ES PIC の認証局からの証明書の取得

認証局(CA)は、証明書の要求を管理し、参加する IPsec ネットワークデバイスに証明書を発行します。証明書要求を作成するときは、証明書の所有者に関する情報を提供する必要があります。必要な情報とその形式は、認証局によって異なります。

証明書は、読み取りアクセスと更新アクセスの両方を提供するディレクトリ アクセス プロトコルである X.500 形式の名前を使用します。名前全体をDN(識別名)と呼びます。これは一連のコンポーネントで構成されており、多くの場合、CN (共通名)、組織 (O)、組織単位 (OU)、国 (C)、地域 (L) などが含まれます。

手記：

デジタル証明書の動的登録については、Junos OS は SCEP(Simple Certificate Enrollment Protocol)のみをサポートします。

M Series または T Series ルーター上の ES PIC の CA デジタル証明書の要求

M SeriesまたはT Seriesルーター上の 暗号化 インターフェイスの場合、次のコマンドを発行して CAから公開鍵証明書を取得します。結果は、 /var/etc/ikecert ディレクトリ内の指定されたファイルに保存されます。CA 公開鍵は、リモート ピアからの証明書を検証します。

例: CA デジタル証明書の要求

SCEP サーバーへの URL と、証明書が必要な証明機関の名前 (mycompany.com) を指定します。filename 1 は、結果を格納するファイルの名前です。出力「Received CA certificate:」は、証明書の署名を提供し、証明書が本物であることを(オフラインで)検証できます。

手記：

各ルータは、最初に認証局に手動で登録されます。

ES PICのデジタル証明書の秘密鍵と公開鍵のペアの生成

秘密鍵と公開 鍵を生成するには、次のコマンドを発行します。

name 公開鍵と秘密鍵を格納するファイル名を指定します。

key-size 512、1024、1596、または 2048 バイトを指定できます。デフォルトの鍵サイズは 1024 バイトです。

typersaまたはdsaにすることができます。デフォルトはRSAです。

手記：

SCEP を使用する場合、Junos OS は RSA のみをサポートします。

次の例は、秘密キーと公開キーのペアを生成する方法を示しています。

CA デジタル証明書の要求

CA デジタル証明書の要求

CA デジタル証明書は、オンラインまたは手動で要求できます。SCEP を使用して CA または RA にオンラインでデジタル証明書を要求するには、 request security pki ca-certificate enroll ca-profile ca-profile-name コマンドを発行します。

CA デジタル証明書を電子メールまたはその他の帯域外メカニズムで手動で取得した場合は、手動でロードする必要があります。ルーターに証明書を手動でインストールするには、 request security pki ca-certificate load ca-profile profile_name filename /path/filename.cert コマンドを発行します。

秘密鍵と公開鍵のペアの生成

鍵ペアは、デジタル証明書実装の重要な要素です。公開キーはローカルデジタル証明書に含まれており、秘密キーはピアから受信したデータの復号化に使用されます。秘密鍵と公開鍵のペアを生成するには、 request security pki generate-key-pair certificate-id certificate-id-name コマンドを発行します。

ローカルデジタル証明書の生成と登録

ローカルのデジタル証明書は、オンラインまたは手動で生成して登録できます。SCEP を使用してローカル証明書をオンラインで生成および登録するには、 request security pki local-certificate enroll コマンドを発行します。ローカル証明書要求を PKCS-10 形式で手動で生成するには、 request security pki generate-certificate-request コマンドを発行します。

ローカル証明書要求を手動で作成する場合は、証明書も手動で読み込む必要があります。ルーターに証明書を手動でインストールするには、 request security pki local-certificate load コマンドを発行します。

ローカルデジタル証明書のIPsec設定への適用

ローカルデジタル証明書をアクティブ化するには、事前共有キーの代わりにデジタル証明書を使用するようにIKE の提案を設定し、IKEポリシーでローカル証明書を参照し、サービスセットでCAまたはRAを識別します。デジタル証明書のIKE の提案を有効にするには、[edit services ipsec-vpn ike proposal proposal-name authentication-method]階層レベルでrsa-signaturesステートメントを含めます。IKEポリシーでローカル証明書を参照するには、[edit services ipsec-vpn ike policy policy-name]階層レベルでlocal-certificateステートメントを含めます。サービス セット内の CA または RA を識別するために、[edit services service-set service-set-name ipsec-vpn-options] 階層レベルで trusted-ca ステートメントを含めます。

デジタル証明書の自動再登録の設定

デジタル証明書の自動再登録を設定できます。この機能は、デフォルトでは有効になっていません。デジタル証明書の自動再登録を設定するには、階層レベルに auto-re-enrollment ステートメントを [edit security pki] 含めます。

ES PIC のデジタル証明書の設定

デジタル証明書は、認証局 (CA)と呼ばれる信頼できるサードパーティーを介してユーザーを認証する方法を提供します。CA は、証明書所有者の ID を検証し、証明書が偽造または変更されていないことを証明するために証明書に「署名」します。

暗号化サービスインターフェイスのデジタル証明書設定を定義するには、 [edit security certificates] および [edit security ike] 階層レベルで以下のステートメントを含めます。

ES PICのデジタル証明書を設定するタスクは次のとおりです。

ES PICの認証局プロパティの設定

CA は、デジタル証明書の作成、登録、検証、および失効を行う信頼できる第三者組織です。

ES PICの認証局とそのプロパティを設定するには、 [edit security certificates] 階層レベルで以下のステートメントを含めます。

ca-profile-name は CA プロファイル名です。

CA プロパティを設定するためのタスクは、以下のとおりです。

認証局名の指定

簡易証明書登録プロトコル (SCEP) を使用して CA に登録する場合は、SCEP サーバーの URL に加えて、証明書の要求で使用される CA 名 (CA ID) を指定する必要があります。

CA ID の名前を指定するには、[edit security certificates certification-authority ca-profile-name] 階層レベルで ca-name ステートメントを含めます。

ca-identity 証明書要求で使用する CA ID を指定します。これは通常、CA ドメイン名です。

証明書失効リストの設定

証明書失効リスト (CRL) には、有効期限が切れる前に取り消されたデジタル証明書のリストが含まれています。参加ピアがデジタル証明書を使用する場合、証明書の署名と有効性をチェックします。また、最後に発行された CRL を取得し、証明書のシリアル番号がその CRL にないことを確認します。

CA 証明書失効リストを設定するには、 crl ステートメントをインクルードし、CRL を読み取るファイルを [edit security certificates certification-authority ca-profile-name] 階層レベルで指定します。

CA がサポートするエンコードの種類の設定

既定では、エンコードはバイナリに設定されています。エンコーディングは、 local-certificate および local-key-pair ステートメントに使用するファイル形式を指定します。既定では、バイナリ (識別エンコード規則) 形式が有効になっています。プライバシ拡張メール(PEM)は、ASCII Base 64エンコードフォーマットです。CA に問い合わせて、サポートされているファイル形式を確認してください。

CA がサポートするファイル形式を設定するには、 encoding ステートメントを含め、 [edit security certificates certification-authority ca-profile-name] 階層レベルでバイナリまたは PEM 形式を指定します。

登録 URL の指定

ルーターまたはスイッチが SCEP ベースの証明書登録要求を送信する CA の場所を指定します。CA URLに名前を付けてCAの場所を指定するには、[edit security certificates certification-authority ca-profile-name]階層レベルでenrollment-urlステートメントを含めます。

url-name は CA の場所です。形式は http://ca-name で、 ca-name は CA ホスト DNS名または IP アドレスです。

デジタル証明書を読み取るファイルの指定

デジタル証明書を読み取るファイルを指定するには、 file ステートメントを含め、 [edit security certificates certification-authority ca-profile-name] 階層レベルで証明書のファイル名を指定します。

LDAP URL の指定

CA が現在の CRL をライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーに格納している場合は、デジタル証明書を使用する前に、オプションで CA CRL リストを確認できます。デジタル証明書が CA CRL に表示されている場合、ルーターまたはスイッチはそれを使用できません。CA CRL にアクセスするには、[edit security certificates certification-authority ca-profile-name] 階層レベルに ldap-url ステートメントを含めます。

url-name は、証明機関の LDAP サーバー名です。形式は ldap://server-name, で、 server-name は CA ホスト DNS名または IP アドレスです。

キャッシュ サイズの構成

既定では、キャッシュ サイズは 2 メガバイト (MB) です。デジタル証明書の合計キャッシュサイズを設定するには、[edit security certificates]階層レベルでcache-sizeステートメントを含めます。

bytes は、デジタル証明書のキャッシュ・サイズです。範囲は 64 から 4,294,967,295 バイトです。

手記：

キャッシュ サイズを 4 MB に制限することをお勧めします。

ネガティブ キャッシュの構成

ネガティブ キャッシュは、ネガティブな結果を格納し、ネガティブな回答に対する応答時間を短縮します。また、リモートサーバーに送信されるメッセージの数も減ります。負のキャッシュ状態を維持すると、ルックアップの試行が再試行されたときに、システムがエラー状態をすばやく返すことができます。負のキャッシュ状態がない場合、リモートサーバーが応答していないことをシステムが既に「認識」している場合でも、再試行ではリモートサーバーが応答しないのを待つ必要があります。

デフォルトでは、負のキャッシュは 20 秒です。ネガティブ キャッシュを設定するには、[edit security certificates]階層レベルで cache-timeout-negative ステートメントを含めます。

seconds は、失敗した CA またはルーター証明書がネガティブ キャッシュに存在する時間です。一致する CA ID (証明書の場合はドメイン名、CRL の場合は CA ドメイン名とシリアル) を持つ証明書を検索するときに、ネガティブ キャッシュが最初に検索されます。ネガティブ キャッシュでエントリが見つかった場合、検索はただちに失敗します。

手記：

大きな負のキャッシュ値を設定すると、サービス拒否(DoS)攻撃を受けやすくなります。

登録の再試行回数の設定

デフォルトでは、登録の再試行回数は 0 に設定されており、再試行回数は無限です。ルーターまたはスイッチが証明書要求を再送する回数を指定するには、[edit security certificates]階層レベルでenrollment-retryステートメントを含めます。

attempts は、登録の再試行回数 (0 から 100) です。

ピア証明書の最大枚数の設定

デフォルトでは、キャッシュされるピア証明書の最大数は 1024 です。キャッシュされるピア証明書の最大数を設定するには、[edit security certificates]階層ステートメントレベルでmaximum-certificatesステートメントを含めます。

number は、キャッシュされるピア証明書の最大数です。範囲は 64 から 4,294,967,295 ピア証明書からです。

証明書階層のパス長の設定

証明機関は、他の CA に証明書を発行できます。これにより、ツリー状の認定階層が作成されます。階層内で最も信頼された CA は、 トラストアンカーと呼ばれます。トラストアンカーは、ルート CA である場合もあり、これは、通常、それ自体によって署名されます。この階層では、すべての証明書は、そのすぐ上の CA によって署名されます。ただし、ルート CA 証明書は例外で、通常はルート CA 自体によって署名されています。一般に、1 つの CA によって署名された公開鍵所有者(エンドエンティティ)の証明書と、他の CA によって署名された CA の 0 個以上の追加証明書で構成される、複数の証明書のチェーンが必要になる場合があります。このようなチェーンは、認証パスと呼ばれ、公開鍵ユーザは、限られた数の保証された CA 公開鍵でしか初期化されないために必要です。

パスの長さは、CA とその「子」の関係に基づいて、ある証明書から別の証明書への証明書のパスを指します。 path-length ステートメントを設定する場合、信頼されたルート CA 証明書から対象の証明書までの証明書を検証するための階層の最大深度を指定します。証明書階層の詳細については、「RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」を参照してください。

既定では、証明書パスの最大長は 15 に設定されています。ルートアンカーは 1 です。

パス長を設定するには、[edit security certificates]階層レベルでpath-lengthステートメントを含めます。

certificate-path-length は、証明書パス長の証明書の最大数です。範囲は 2 から 15 の証明書からです。