2.4. PKI (Certificate System あり)

Certificate System はサブシステムで設定されており、各サブシステムが公開鍵インフラストラクチャーのさまざまな機能を提供します。PKI 環境は、サブシステムにさまざまな機能を実装することで、個々のニーズに合わせてカスタマイズできます。
注記
従来の PKI 環境は、ソフトウェアデータベースに保存されている証明書を管理する基本的なフレームワークを提供します。これは、スマートカードで証明書を管理しないため、TMS 以外 の環境です。TMS 環境では、スマートカードで証明書を管理します。
少なくとも、TMS 以外の環境では CA のみが必要ですが、TMS 以外の環境では OCSP レスポンダーと KRA インスタンスも使用できます。

2.4.1. 証明書の発行

通常、Certificate Manager は Certificate System の中核となります。リクエストから登録 (発行)、更新、失効まで、あらゆる段階で証明書を管理します。
Certificate System は、証明書の登録と発行、および Web ブラウザー、サーバー、仮想プライベートネットワーク (VPN) クライアントなどのさまざまなエンドエンティティーからの証明書要求の処理をサポートします。発行した証明書は X.509 バージョン 3 標準仕様に準拠します。
詳細は、『Red Hat Certificate System 管理ガイド』の『証明書の登録および更新について』セクションを参照してください。

2.4.1.1. 登録プロセス

エンドエンティティーは、エンドエンティティーインターフェイスを介して登録要求を送信することにより、PKI 環境に登録します。さまざまな登録方法を使用したり、さまざまな認証方法を必要とする多くの種類の登録があります。異なるインターフェイスが、異なるタイプの証明書署名要求 (CSR) を受け入れることもできます。
Certificate Manager は、グラフィカルインターフェイスやコマンドラインツールの使用など、CSR を送信するさまざまな方法をサポートします。
2.4.1.1.1. ユーザーインターフェイスを使用した登録
ユーザーインターフェイスを介した登録ごとに、登録の種類、認証の種類、および証明書の種類に関連付けられた証明書プロファイルに固有の個別の登録ページが作成されます。登録に関連するフォームは、外観とコンテンツの両方でカスタマイズできます。または、登録タイプごとに証明書プロファイルを作成することにより、登録プロセスをカスタマイズできます。証明書プロファイルは、証明書プロファイルに関連付けられた入力を設定することによってカスタマイズされたフォームを動的に生成します。異なるインターフェイスが、異なるタイプの証明書署名要求 (CSR) を受け入れることもできます。
エンドエンティティーが証明書を要求して PKI に登録すると、PKI の設定とインストールされているサブシステムに応じて、次のイベントが発生する可能性があります。
  1. エンドエンティティーは、登録フォームの 1 つに情報を提供し、リクエストを送信します。
    エンドエンティティーから収集された情報は、収集された情報に応じてフォームでカスタマイズ可能であり、証明書に保存したり、フォームに関連付けられた認証方法に対して認証したりできます。このフォームは、Certificate Manager に送信される要求を作成します。
  2. 登録フォームは、リクエストの公開鍵と秘密鍵、またはデュアルキーペアの作成をトリガーします。
  3. エンドエンティティーは、認証タイプに応じて、リクエストの送信前に認証情報を提供します。LDAP 認証、PIN ベースの認証、または証明書ベースの認証を指定できます。
  4. リクエストは、エージェントの承認登録プロセスまたは自動プロセスのいずれかに送信されます。
    • エンドエンティティー認証を含まないエージェント承認プロセスは、エージェントが要求を処理する必要があるエージェントサービスインターフェイスの要求キューに要求を送信します。その後、エージェントはリクエストの一部を変更したり、リクエストのステータスを変更したり、リクエストを拒否したり、リクエストを承認することができます。
      自動通知を設定して、リクエストがキューに表示されるたびにエージェントにメールが送信されるようにすることができます。また、自動化されたジョブを設定して、事前に設定されたスケジュールでキューの内容のリストをエージェントに送信することもできます。
    • エンドエンティティー認証を含む自動化されたプロセスは、エンドエンティティーが正常に認証されるとすぐに証明書要求を処理します。
  5. フォームの送信時に LDAP ディレクトリーからエンドエンティティーに関する情報を収集します。証明書プロファイルベースの登録では、フォームのデフォルト値を使用して、ユーザーの LDAP ID およびパスワードを収集します。
  6. フォームに関連付けられた証明書プロファイルは、発行する証明書の要素を決定します。証明書プロファイルに応じて、リクエストは、要求が制約セットを満たすか、必要な情報が提供されているか、および新しい証明書の内容を決定するために評価されます。
  7. フォームは、ユーザーが秘密鍵をエクスポートするようにリクエストすることもできます。KRA サブシステムがこの CA で設定されている場合は、エンドエンティティーのキーが要求され、アーカイブされた要求が KRA に送信されます。このプロセスは通常、エンドエンティティーからの対話を必要としません。
  8. 証明書要求は、証明書プロファイルまたは認証要件を満たしていないために拒否されるか、証明書が発行されます。
  9. 証明書はエンドエンティティーに配信されます。
    • 自動登録では、証明書は即座にユーザーに配信されます。通常、登録は HTML ページを介して行われるため、証明書は別の HTML ページの応答として返されます。
    • エージェントが承認した登録では、証明書はシリアル番号またはエンドエンティティーインターフェイスのリクエスト ID で取得できます。
    • 通知機能が設定されている場合は、証明書の取得先のリンクがエンドユーザーに送信されます。
  10. 証明書が発行または拒否されると、自動通知をエンドエンティティーに送信できます。
  11. 新しい証明書は Certificate Manager の内部データベースに保存されます。
  12. Certificate Manager に公開が設定されている場合、証明書はファイルまたは LDAP ディレクトリーに公開されます。
  13. 内部 OCSP サービスは、証明書ステータス要求を受け取る際に内部データベースの証明書のステータスを確認します。
エンドエンティティーインターフェイスには、発行された証明書および CA 証明書チェーンを検索するフォームがあります。
デフォルトでは、ユーザーインターフェイスは PKCS #10 および Certificate Request Message Format (CRMF) の CSR に対応しています。
2.4.1.1.2. コマンドラインを使用した登録
本セクションでは、コマンドラインを使用して証明書を登録する際の一般的なワークフローを説明します。
2.4.1.1.2.1. pki ユーティリティーを使用した登録
詳細は、以下を参照してください。
2.4.1.1.2.2. CMC を使用した登録
CMC に証明書を登録するには、次の手順に従います。
  1. PKCS10Client、CRMFPopClient などのユーティリティーを使用して、PKCS #10 または CRMF 証明書署名要求 (CSR) を生成します。
    注記
    Key Recovery Agent (KRA) で鍵のアーカイブが有効になっている場合は、kra.transport ファイルに設定されている Privacy Enhanced Mail (PEM) 形式の KRA のトランスポート証明書とともに、CRMFPopClient ユーティリティーを使用します。
  2. CMCRequest ユーティリティーを使用して、CSR を CMC 要求に変換します。CMCRequest ユーティリティーは、設定ファイルを入力として使用します。このファイルには、CSR へのパスや CSR の形式などが含まれます。
    詳細および例は、CMCRequest(1) の man ページを参照してください。
  3. HttpClient ユーティリティーを使用して、CMC 要求を CA に送信します。HttpClient は、CMC 要求ファイルやサーブレットへのパスなどの設定を含む設定ファイルを使用します。
    HttpClient コマンドが成功すると、ユーティリティーは CA から CMC ステータス制御を備えた PKCS #7 チェーンを受け取ります。
    ユーティリティーが提供するパラメーターの詳細は、パラメーターを指定せずに HttpClient コマンドを入力します。
  4. CMCResponse ユーティリティーを使用して、HttpClient で生成された PKCS #7 ファイルの発行結果を確認します。リクエストが正常に行われると、CMCResponse は証明書チェーンを読み取り可能な形式で表示します。
    詳細は、CMCResponse(1) の man ページを参照してください。
  5. 新しい証明書をアプリケーションにインポートします。詳細は、証明書をインポートするアプリケーションの手順に従います。
    注記
    HttpClient が取得した証明書は、PKCS #7 形式になります。アプリケーションが Base64 でエンコードされた証明書のみに対応している場合は、BtoA ユーティリティーを使用して証明書を変換します。
    また、一部のアプリケーションでは、PEM (Privacy Enhanced Mail) 形式の証明書にヘッダーとフッターが必要です。必要な場合は、証明書を変換した後に PEM ファイルに手動で追加します。
2.4.1.1.2.2.1. POP なしの CMC 登録
POP (Proof Of Possession) がない場合、HttpClient ユーティリティーは、EncryptedPOP CMC ステータスを受け取ります。これは、CMCResponse コマンドにより表示されます。この場合は、設定ファイルに異なるパラメーターを指定して CMCRequest コマンドを再び入力します。
詳細は、『Red Hat Certificate System 管理ガイド』 の 『CMC 登録プロセス』 セクションを参照してください。
2.4.1.1.2.2.2. 署名付き CMC 要求
CMC 要求は、ユーザーまたは CA エージェントのいずれかによって署名できます。
  • エージェントが要求に署名する場合は、プロファイルの認証方法を CMCAuth に設定します。
  • ユーザーがリクエストに署名する場合は、プロファイルの認証方法を CMCUserSignedAuth に設定します。
詳細は、『Red Hat Certificate System 管理ガイド』 の 『CMC 認証プラグイン』 セクションを参照してください。
2.4.1.1.2.2.3. 署名なしの CMC 要求
CMCUserSignedAuth 認証プラグインはプロファイルで設定されているため、共有秘密認証メカニズムと組み合わせて署名されていない CMC 要求を使用する必要があります。
注記
署名なしで要求は 自己署名 CMC 要求 とも呼ばれます。
詳細は、『Red Hat Certificate System 管理ガイド』 の 『Firewall Authentication Plug-ins』 セクションおよび 「CMC 共有シークレット機能の有効化」 を参照してください。
2.4.1.1.2.2.4. 共有シークレットのワークフロー
Certificate System は、RFC 5272 に従って、CMC リクエストの共有シークレット認証メカニズムを提供します。パスフレーズを保護するには、CMCSharedToken コマンドの使用時に、発行保護証明書を提供する必要があります。保証保護証明書は、KRA トランスポート証明書と同じように機能します。詳細は、CMCSharedToken(1) の man ページおよび 「CMC 共有シークレット機能の有効化」 を参照してください。

エンドエンティティーユーザーによって作成された共有シークレット (推奨)

以下に、ユーザーが共有の秘密を生成する場合にワークフローを説明します。
  1. エンドエンティティーユーザーは、CA 管理者から発行保護証明書を取得します。
  2. エンドエンティティーユーザーは CMCSharedToken ユーティリティーを使用して共有シークレットトークンを生成します。
    注記
    -p オプションは、トークンのパスワードではなく、CA とユーザー間で共有されるパスフレーズを設定します。
  3. エンドエンティティーユーザーは、CMCSharedToken ユーティリティーによって生成された暗号化された共有トークンを管理者に送信します。
  4. 管理者は、ユーザーの LDAP エントリーの shrTok 属性に共有トークンを追加します。
  5. エンドエンティティーユーザーはパスフレーズを使用して、CMCRequest ユーティリティーに渡される設定ファイルの witness.sharedSecret パラメーターを設定します。

CA 管理者によって作成された共有シークレット

以下では、CA 管理者がユーザーの共有のシークレットを生成する場合にワークフローを説明します。
  1. 管理者は CMCSharedToken ユーティリティーを使用して、ユーザーの共有シークレットトークンを生成します。
    注記
    -p オプションは、トークンのパスワードではなく、CA とユーザー間で共有されるパスフレーズを設定します。
  2. 管理者は、ユーザーの LDAP エントリーの shrTok 属性に共有トークンを追加します。
  3. 管理者は、パスフレーズをユーザーと共有します。
  4. エンドエンティティーユーザーはパスフレーズを使用して、CMCRequest ユーティリティーに渡される設定ファイルの witness.sharedSecret パラメーターを設定します。
2.4.1.1.2.2.5. 単純な CMC 要求
Certificate System は、シンプルな CMC 要求を許可します。ただし、このプロセスは完全な CMC 要求と同じレベルのセキュリティー要件をサポートしていないため、安全な環境でのみ使用する必要があります。
簡単な CMC 要求を使用する場合は、HttpClient ユーティリティーの設定ファイルで以下を設定します。 
servlet=/ca/ee/ca/profileSubmitCMCSimple?profileId=caECSimpleCMCUserCert

2.4.1.2. 証明書プロファイル

Certificate System は証明書プロファイルを使用して、証明書の内容、証明書を発行する制約、使用する登録方法、およびその登録方法の入力フォームおよび出力フォームを設定します。1 つの証明書プロファイルが、特定の証明書の発行に関連付けられます。
最も一般的な証明書プロファイルのセットは、最も一般的な証明書タイプに含まれます。プロファイル設定は変更できます。証明書プロファイルは管理者が設定し、エージェントの承認のためにエージェントサービスページに送信されます。証明書プロファイルが承認されると、使用が有効になっています。UI の登録の場合、証明書プロファイルに対して動的に生成される HTML フォームは、証明書プロファイルで呼び出す証明書登録のエンドエンティティーページで使用されます。コマンドラインベースの登録の場合は、認証、認可、入力、出力、デフォルト、制約などの同じ処理を実行するために証明書プロファイルが呼び出されます。サーバーは、要求に対応する前に、証明書プロファイルに設定されているデフォルトと制約が満たされていることを確認し、証明書プロファイルを使用して発行された証明書の内容を判別します。
Certificate Manager は、プロファイルや送信の証明書要求の設定に応じて、以下のいずれかの特徴で証明書を発行できます。
  • X.509 バージョン 3 に準拠する証明書
  • 証明書サブジェクト名と発行者名に対する Unicode サポート
  • 空の証明書のサブジェクト名のサポート
  • カスタマイズされたサブジェクト名コンポーネントのサポート
  • カスタマイズされた拡張機能のサポート
デフォルトでは、証明書登録プロファイルは <instance directory>/ca/profiles/ca に保存され、その名前は <profile id>.cfg の形式になります。適切な pkispawn 設定パラメーターを使用すると、LDAP ベースのプロファイルが可能です。

2.4.1.3. 証明書登録の認証

Certificate System は、証明書登録の認証オプションを提供します。これには、エージェントが要求を処理するエージェント承認済み登録と、エンドエンティティーを認証する認証方法をが使用され、CA が自動的に証明書を発行する自動登録があります。エージェントによって承認されたリクエストを自動的に処理する CMC 登録もサポートされています。

2.4.1.4. クロスペアの証明書

これら 2 つの CA 間でクロス署名証明書を発行および格納することにより、2 つの異なる CA 間で信頼される関係を作成できます。クロス署名証明書ペアを使用すると、組織の PKI 以外で発行された証明書は、システム内で信頼できます。

2.4.2. 証明書の更新

証明書が有効期限に達すると、失効を許可するか、更新することができます。
更新 は、その証明書の既存の鍵ペアを使用して証明書要求を再生成し、要求を Certificate Manager に再送信します。更新された証明書は、1 つの例外を除いて、元の証明書と同じです (同じプロファイルから同じキーマテリアルを使用して作成されたため)。有効期限は異なり、遅くなります。
更新された証明書は古い証明書とまったく同じように機能するため、更新により、証明書の管理とユーザーとサーバー間の関係がはるかにスムーズになります。ユーザー証明書の更新により、暗号化されたデータには失われなくてもアクセスすることができます。

2.4.3. 証明書および CRL の公開

証明書はファイルおよび LDAP ディレクトリー、CRL をファイル、LDAP ディレクトリー、および OCSP レスポンダーに公開できます。公開フレームワークは、3 つのすべての場所に公開するための堅牢なツールセットを提供し、証明書や CRL を公開する場所をより詳細に定義するルールを設定します。

2.4.4. 証明書の取り消しとステータスの確認

エンドエンティティーは、独自の証明書が取り消されることを要求できます。エンドエンティティーが要求を行うとき、証明書を CA に提示する必要があります。証明書とキーが使用可能な場合、要求は処理されて Certificate Manager に送信され、証明書は取り消されます。Certificate Manager は、証明書をデータベースで取り消されたとマークし、該当する CRL に追加します。
エージェントは、エージェントサービスインターフェイスで証明書を検索し、取り消しにすることにより、Certificate Manager が発行する証明書をすべて取り消すことができます。証明書が取り消されると、証明書が公開用に設定されている場合は、データベースと公開ディレクトリーで取り消されたとマークされます。
内部の OCSP サービスが設定されている場合、サービスは内部データベースで証明書のステータスを判断します。
自動通知は、証明書失効通知メッセージを有効にして設定すると、証明書が取り消された時にエンドエンティティーに電子メールメッセージを送信するように、自動通知を設定することができます。

2.4.4.1. 証明書の取り消し

ユーザーは、以下を使用して証明書を取り消すことができます。
  • エンドエンティティーページ。詳細は、『Red Hat Certificate System 管理ガイド』 の 『証明書取り消しページ』 セクションを参照してください。
  • コマンドラインでの CMCRequest ユーティリティー。詳細は、『Red Hat Certificate System 管理ガイド』 の 『CMC 取り消しの実行』 セクションを参照してください。
  • コマンドラインの pki ユーティリティー詳細は、pki-cert(1) の man ページを参照してください。

2.4.4.2. 証明書の状態

2.4.4.2.1. CRL
Certificate System は、設定可能なフレームワークから証明書失効リスト (CRL) を作成できます。これにより、ユーザー定義の発行ポイントが可能になり、発行する各ポイントに CRL を作成できます。デルタ CRL は、定義した発行ポイントにも作成できます。CRL は、証明書の各タイプ、証明書のタイプの特定のサブセット、またはプロファイルまたはプロファイルのリストに従って生成された証明書に対して発行できます。CRL を公開する際の頻度と間隔がすべて設定できます。
Certificate Manager は X.509 標準 CRL を発行します。CRL は、証明書が取り消されたり、指定した間隔で毎回更新される可能性があります。
2.4.4.2.2. OCSP サービス
Certificate System CA は、PKIX 標準 RFC 2560 で定義されている Online Certificate Status Protocol (OCSP) をサポートします。OCSP プロトコルを使用すると、OCSP 準拠のアプリケーションは、CA から検証機関に公開された CRL を直接確認しなくても、失効ステータスを含む証明書の状態を判別できます。OCSP レスポンダー とも呼ばれる検証権限は、アプリケーションをチェックします。
  1. CA は、証明書のステータスに対してクエリーできる OCSP レスポンダーを特定する Authority Information Access 拡張を含む証明書を発行するよう設定されます。
  2. CA は CRL を OCSP レスポンダーに定期的に公開します。
  3. OCSP レスポンダーは、CA から受け取る CRL を維持します。
  4. OCSP 準拠のクライアントは、検証用の OCSP レスポンダーに証明書を特定するのに必要なすべての情報が含まれるリクエストを送信します。アプリケーションは、検証する証明書の Authority Information Access 拡張の値から OCSP レスポンダーの場所を決定します。
  5. OCSP レスポンダーは、リクエストに処理に必要なすべての情報が含まれるかどうかを判断します。有効になっていない場合、または要求されたサービスに対して有効になっていない場合は、拒否通知が送信されます。十分な情報がある場合は、要求を処理し、証明書のステータスを示すレポートを送信します。
2.4.4.2.2.1. OCSP レスポンスの署名
拒否通知を含む、クライアントが受信するすべての応答は、応答者によってデジタル署名されます。クライアントは、署名を検証して、要求を送信したレスポンダーからの応答であることを確認する必要があります。レスポンダーがメッセージに署名するために使用するキーは、OCSP レスポンダーが PKI セットアップでどのように展開されているかによって異なります。RFC 2560 は、応答に署名するために使用される鍵が以下のいずれかに属することを推奨します。
  • ステータスがチェックされている証明書を発行した CA。
  • クライアントが信頼する公開鍵のあるレスポンダー。このようなレスポンダーは 信頼できるレスポンダー と呼ばれます。
  • 証明書を取り消して CRL を公開する CA から直接発行された、特別にマークされた証明書を保持するレスポンダー。レスポンダーによるこの証明書の所持は、CA が、CA によって取り消された証明書に対して OCSP 応答を発行することをレスポンダーに許可したことを示します。このようなレスポンダーは、CA 設計されたレスポンダー または CA 承認レスポンダー と呼ばれます。
Certificate Manager のエンドエンティティーには、OCSP レスポンダーの証明書を手動で要求するためのフォームが含まれています。デフォルトの登録フォームには、OCSP レスポンダー証明書として証明書を識別するすべての属性が含まれます。OCSPNoCheck や Extended Key Usage などの必要な証明書拡張機能は、証明書が送信されたときに証明書に追加できます。
2.4.4.2.2.2. OCSP レスポンス
クライアントが受け取った OCSP 応答は、OCSP レスポンダーが決定した証明書の現在の状態を示します。応答は以下のいずれかになります。
  • Good or Verified。ステータス照会に対する肯定応答を指定します。これは、証明書が取り消されていないことを意味します。必ずしも証明書が発行されたことや、証明書の有効期間内であることを意味するわけではありません。応答拡張は、証明書のステータスに関するレスポンダーによるアサーションの追加情報を示すために使用できます。
  • Revoked。永続的または一時的に、証明書が取り消されたことを指定します。
クライアントは、ステータスに基づいて、証明書を検証するかどうかを決定します。
注記
OCSP レスポンダーは Unknown の応答を返しません。応答は常に Good または Revoked になります。
2.4.4.2.2.3. OCSP サービス
OCSP サービスの設定方法は 2 つあります。
  • Certificate Manager に構築された OCSP
  • Online Certificate Status Manager サブシステム
Certificate Manager は、組み込みの OCSP サービスの他に、CRL を OCSP 準拠の検証認証局に公開できます。CA は、CRL を Certificate System Online Certificate Status Manager に公開できるように設定できます。Online Certificate Status Manager は、各 Certificate Manager の CRL を内部データベースに保存し、適切な CRL を使用して、OCSP 準拠のクライアントから照会されたときに証明書の失効ステータスを確認します。
Certificate Manager は、証明書が取り消され、指定した間隔で CRL を生成および公開します。OCSP レスポンダーの目的は、証明書の即時検証を容易にすることを目的としているため、Certificate Manager は証明書を取り消すたびに CRL を Online Certificate Status Manager に公開する必要があります。間隔を置いてのみ公開するということは、OCSP サービスが古い CRL をチェックしていることを意味します。
注記
CRL が大きい場合、Certificate Manager は CRL を公開するのにかなり時間がかかる場合があります。
Online Certificate Status Manager は、各 Certificate Manager の CRL を内部データベースに保存し、証明書の検証に CRL として使用します。Online Certificate Status Manager は LDAP ディレクトリーに公開される CRL も使用できます。そのため、Certificate Manager は CRL を Online Certificate Status Manager に直接更新する必要はありません。

2.4.5. キーのアーカイブ、リカバリー、およびローテーション

PKI の間、秘密鍵のアーカイブを使用すると、秘密鍵が失われた場合に暗号化されたデータのリカバリーが可能になります。秘密鍵は、ハードウェア障害、パスワード忘れ、スマートカードの紛失、パスワード所有者の資格喪失など、さまざまな理由で失われる可能性があります。このようなアーカイブおよびリカバリー機能は、RHCS の Key Recovery Authority (KRA) サブシステムによって提供されます。
データの暗号化にのみ使用されるキーのみをアーカイブする必要があります。特に署名キーは決してアーカイブされるべきではありません。署名キーのコピーが 2 つあると、誰がキーを使用したかを確実に特定することができなくなります。2 番目にアーカイブされたコピーを使用して、元のキー所有者のデジタル ID を偽装することができます。

2.4.5.1. キーのアーカイブ

KRA で提供されるキーアーカイブメカニズムには、以下の 2 つのタイプがあります。
  • クライアント側のキー生成: このメカニズムを使用すると、クライアントは CRMF 形式で CSR を生成し、登録とキーのアーカイブのために (適切な KRA セットアップを使用して) CA に要求を送信します。『Red Hat Certificate System 管理ガイド』の『CRMFPopClient を使用した CSR の作成』セクションを参照してください。
  • サーバー側の鍵生成: このメカニズムでは、適切に装備された証明書登録プロファイルにより、PKI キーが KRA で生成され、任意で新しく発行された証明書とともにアーカイブされます。『Red Hat Certificate System 管理ガイド』の『サーバー側の鍵生成を使用した CSR の生成』セクションを参照してください。
アーカイブが設定されている場合、KRA は秘密鍵を自動的にアーカイブします。
KRA は秘密鍵を安全な鍵リポジトリーに格納します。各キーは暗号化され、キーレコードとして保存され、一意の鍵 ID が付与されます。
鍵のアーカイブコピーは、KRA のストレージキーでラップされます。ストレージ証明書の対応する秘密鍵ペアを使用することによってのみ、復号またはラップ解除が可能になります。1 つ以上のキーリカバリー (または KRA) エージェントの証明書の組み合わせは、KRA で鍵のリカバリーを完了して秘密鍵を取得し、その証明書を使用してアーカイブされた秘密鍵を復号または再作成できるようにします。「コマンドラインでのエージェント承認キーリカバリーの設定」 を参照してください。
KRA インデックスは、キー番号、所有者名、および公開鍵のハッシュ別に保存されるため、非常に効率的な検索を可能にします。キーリカバリーエージェントには、キーレコードの挿入、削除、および検索を行うための特権があります。
  • キーリカバリーエージェントがキー ID で検索されると、その ID に対応するキーのみが返されます。
  • ユーザー名でエージェントを検索すると、その所有者に属する保存されたすべてのキーが返されます。
  • 証明書の公開鍵でエージェントを検索すると、対応する秘密鍵のみが返されます。
Certificate Manager がキーのアーカイブオプションを含む証明書要求を受信すると、自動的に要求を KRA に転送して暗号鍵をアーカイブします。秘密鍵はトランスポートキーで暗号化され、KRA は暗号化されたコピーを受け取り、キーをキーリポジトリーに保存します。キーをアーカイブするには、KRA は以下の 2 つの特別なキーペアを使用します。
  • トランスポートキーペアと対応する証明書。
  • ストレージキーペア
図2.2「クライアント側のキー生成における鍵アーカイブプロセスの仕組み」 は、サーバー側の鍵の生成時に、最終的にエンティティーが証明書を要求する際に鍵のアーカイブプロセスがどのように発生するかを示しています。

図2.2 クライアント側のキー生成における鍵アーカイブプロセスの仕組み

クライアント側のキー生成における鍵アーカイブプロセスの仕組み
  1. クライアントは CRMF リクエストを生成し、CA の登録ポータルを介して送信します。
    1. クライアントの秘密鍵は CRMF リクエスト内にラップされ、KRA によってだけラップできます。
  2. CA は、キーアーカイブオプションを使用した CRMF リクエストであることを検出し、秘密キーアーカイブのためにリクエストを KRA に転送します。
  3. KRA は、ユーザーの秘密鍵を復号/ラップ解除し、秘密鍵が公開鍵に対応していることを確認した後、内部 LDAP データベースに保存する前に再度暗号化/ラップします。
  4. 秘密鍵が正常に保存されると、KRA は、鍵が正常にアーカイブされたことを確認する CA に応答します。
  5. CA は、証明書情報コンテンツの作成と検証のために、登録プロファイルフレームワークにリクエストを送信します。すべてが渡されると、証明書を発行し、応答でエンドエンティティーに送り返します。

2.4.5.2. キーのリカバリー

KRA は、agent-initiated key recovery をサポートします。エージェントが開始するリカバリーとは、指定されたリカバリーエージェントが KRA エージェントサービスポータルのキーリカバリーフォームを使用して、キーリカバリー要求を処理および承認する場合です。特定の数のエージェントを承認すると、システムは、キーの所有者が利用できない、またはキーが失われた場合にキーを回復できます。
キーリカバリーエージェントは、KRA エージェントサービスポータルを介して、秘密暗号化キーと関連する証明書をまとめて承認し、PKCS #12 パッケージに取得して、クライアントにインポートできます。
キーリカバリー許可では、キーリカバリーエージェントの 1 つが、必要なすべてのリカバリーエージェントに、差し迫ったキーリカバリーについて通知します。すべてのリカバリーエージェントは、KRA キーリカバリーポータルにアクセスします。エージェントの 1 つが、キーリカバリープロセスを開始します。KRA はエージェントへの通知を返します。これには、エージェントの認証に必要な特定のキーリカバリー要求を指定するリカバリー承認参照番号が含まれます。各エージェントは参照番号を使用し、キーの復元を個別に承認します。
KRA は 非同期リカバリー をサポートします。つまり、リカバリープロセスの各ステップ (最初の要求と後続の承認または承認または拒否) は、キーエントリーの KRA の内部 LDAP データベースに保存されます。元のブラウザーセッションが閉じられたり、KRA がシャットダウンしている場合でも、リカバリープロセスのステータスデータを取得することができます。エージェントは、参照番号を使用せずにキーをリカバリーすることができます。
この非同期リカバリーオプションは、図2.3「非同期リカバリー」 で説明されています。

図2.3 非同期リカバリー

非同期リカバリー
KRA は、認可のステータスキーリカバリープロセスを開始したエージェントに通知します。
すべての承認を入力すると、KRA は情報をチェックします。提示された情報が正しい場合は、要求されたキーを取得し、PKCS #12 パッケージの形式で、キーリカバリープロセスを開始したエージェントに、対応する証明書を返します。
警告
PKCS #12 パッケージには、暗号化された秘密鍵が含まれます。キーの不正使用のリスクを最小限に抑えるには、リカバリーエージェントはセキュアな方法を使用して PKCS #12 パッケージおよびパスワードを鍵受信者に提供する必要があります。このエージェントは、PKCS #12 パッケージを暗号化するために適切なパスワードを使用し、適切な配信メカニズムを設定する必要があります。
キーリカバリーエージェントスキーム は、キーリカバリーエージェントが属するグループを認識するように KRA を設定し、アーカイブされた鍵を復元する前にキーリカバリー要求を承認するために必要なこれらのリカバリーエージェントの数を指定します。
重要
上記の情報は、Firefox などの Web ブラウザーを使用することを指します。ただし、KRA の使用に重要な機能は、Red Hat Enterprise Linux 7 プラットフォームでリリースされた Firefox バージョン 31.6 に含まれなくなりました。このような場合は、pki ユーティリティーを使用してこの動作を複製する必要があります。詳細は、pki(1) および pki-key(1) の man ページ、または CRMFPopClient --help および man CMCRequest を実行します。
KRA は非対称鍵を保存する他に、ボリューム暗号化シークレット、パスワード、パスフレーズなどの対称鍵やシークレットも格納することができます。pki ユーティリティーは、これらのタイプのシークレットの保存および取得を可能にするオプションをサポートします。

2.4.5.3. KRA トランスポートのキーローテーション

KRA トランスポートローテーションにより、現在のトランスポートキーと新しいトランスポートキーを使用して、CA サブシステムインスタンスと KRA サブシステムインスタンスとの間のシームレスな移行が可能になります。これにより、移行時に古いトランスポートキーと新しいトランスポートキーの両方を操作できるようにすることで、KRA トランスポートキーを定期的にローテーションしてセキュリティーを強化できます。個々のサブシステムインスタンスは順番に設定され、他のクローンはダウンタイムなしでサービスを継続します。
KRA トランスポートキーローテーションプロセスでは、新しいトランスポートキーペアが生成され、証明書要求が送信され、新しいトランスポート証明書が取得されます。2 番目のトランスポートキーのサポートを提供するために、新しいトランスポートキーペアと証明書を KRA 設定に含める必要があります。KRA が 2 つのトランスポートキーをサポートすると、管理者は CA を新しいトランスポートキーに移行できます。古いトランスポートキーの KRA サポートは、すべての CA が新しいトランスポートキーに移動した後に削除できます。
KRA トランスポートキーローテーションを設定するには、以下を実行します。
  1. 新しい KRA トランスポートの鍵および証明書の生成
  2. 新しいトランスポートキーおよび証明書の KRA クローンへの転送
  3. 新しい KRA トランスポート証明書を使用した CA 設定の更新
  4. 新しいトランスポートキーおよび証明書のみを使用するように KRA 設定を更新
これにより、KRA トランスポート証明書のローテーションが完了し、影響を受ける CA および KRA がすべて新しい KRA 証明書のみを使用します。上記の手順の実行方法は、以下の手順を参照してください。
新しい KRA トランスポートキーおよび証明書の生成
  1. KRA トランスポート証明書を要求します。
    1. KRA を停止します。 
      # pki-server stop pki-kra
      または (nuxwdog watchdog を使用している場合) 
      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
    2. KRA NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    3. サブディレクトリーを作成し、すべての NSS データベースファイルを保存します。以下に例を示します。 
      mkdir nss_db_backup
cp *.db nss_db_backup
    4. PKCS10Client ユーティリティーを使用して新しいリクエストを作成します。以下に例を示します。 
      # PKCS10Client -p password -d '.' -o 'req.txt' -n 'CN=KRA Transport 2 Certificate,O=example.com Security Domain'
      または、certutil ユーティリティーを使用します。以下に例を示します。 
      # certutil -d . -R -k rsa -g 2048 -s 'CN=KRA Transport 2 Certificate,O=example.com Security Domain' -f password-file -a -o transport-certificate-request-file
    5. CA エンドエンティティーページの 手動データリカバリーマネージャートランスポート証明書の登録 ページで、トランスポート証明書要求を送信します。
    6. End-Entity 取得ページで要求ステータスをチェックして、送信した要求のエージェント承認が証明書を取得するのを待ちます。
  2. CA Agent Services インターフェイスを使用して KRA トランスポート証明書を承認します。
  3. KRA トランスポート証明書を取得します。
    1. KRA NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    2. End-Entity 取得ページで要求ステータスをチェックして、送信した要求のエージェント承認が証明書を取得するのを待ちます。
    3. 新しい KRA トランスポート証明書が利用可能になったら、その Base64 でエンコードされた値をテキストファイル (例: cert-serial_number.txt ファイル) に貼り付けます。ヘッダー (-----BEGIN CERTIFICATE-----) またはフッター (-----END CERTIFICATE-----) を追加しないでください。
  4. KRA トランスポート証明書を要求します。
    1. KRA NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    2. トランスポート証明書を KRA NSS データベースにインポートします。 
      # certutil -d . -A -n 'transportCert-serial_number cert-pki-kra KRA' -t 'u,u,u' -a -i cert-serial_number.txt
  5. KRA トランスポート証明書設定を更新します。
    1. KRA NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    2. 新しい KRA トランスポート証明書がインポートされていることを確認します。 
      # certutil -d . -L
# certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
    3. /var/lib/pki/pki-kra/kra/conf/CS.cfg ファイルを開き、以下の行を追加します。 
      kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
新しいトランスポートキーおよび証明書の KRA クローンへの伝搬
  1. KRA を起動します。 
    # pki-server start pki-kra
    または (nuxwdog watchdog を使用している場合) 
    # systemctl start pki-tomcatd-nuxwdog@pki-kra.service
  2. クローンに伝播するために、新しいトランスポートキーと証明書を抽出します。
    1. KRA NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    2. KRA を停止します。 
      # pki-server stop pki-kra
      または (nuxwdog watchdog を使用している場合) 
      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
    3. 新しい KRA トランスポート証明書が存在することを確認します。 
      # certutil -d . -L
# certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
    4. KRA の新規トランスポートキーおよび証明書をエクスポートします。 
      # pk12util -o transport.p12 -d . -n 'transportCert-serial_number cert-pki-kra KRA'
    5. エクスポートした KRA トランスポート鍵および証明書を確認します。 
      # pk12util -l transport.p12
  3. 各 KRA クローンで以下の手順を実行します。
    1. トランスポートキーおよび証明書を含む transport.p12 ファイルを KRA クローンの場所にコピーします。
    2. クローンの NSS データベースディレクトリーに移動します。 
      # cd /etc/pki/pki-kra/alias
    3. KRA のクローンを停止します。 
      # pki-server stop pki-kra
      または (nuxwdog watchdog を使用している場合) 
      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
    4. クローン NSS データベースの内容を確認します。 
      # certutil -d . -L
    5. クローンの新規トランスポートキーと証明書をインポートします。 
      # pk12util -i transport.p12 -d .
    6. クローンの /var/lib/pki/pki-kra/kra/conf/CS.cfg ファイルに以下の行を追加します。 
      kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
    7. KRA のクローンを起動します。 
      # pki-server start pki-kra
      または (nuxwdog watchdog を使用している場合) 
      # systemctl start pki-tomcatd-nuxwdog@pki-kra.service
新しい KRA トランスポート証明書を使用した CA 設定の更新
  1. CA に組み込む新しい KRA トランスポート証明書をフォーマットします。
    1. 直前の手順で KRA トランスポート証明書を取得する際に作成した cert-serial_number.txt KRA トランスポート証明書ファイルを取得します。
    2. cert-serial_number.txt に含まれる Base64 でエンコードされた証明書を 1 行のファイルに変換します。 
      # tr -d '\n' < cert-serial_number.txt > cert-one-line-serial_number.txt
  2. CA と、上記の KRA に対応するすべてのクローンに対して以下を行います。
    1. CA を停止します。 
      # pki-server stop pki-ca
      または (nuxwdog watchdog を使用している場合) 
      # systemctl stop pki-tomcatd-nuxwdog@pki-ca.service
    2. /var/lib/pki/pki-ca/ca/conf/CS.cfg ファイルで、以下の行に含まれる証明書を見つけます。 
      ca.connector.KRA.transportCert=certificate
      その証明書を、cert-one-line-serial_number.txt に含まれる証明書に置き換えます。
    3. CA を起動します。 
      # pki-server start pki-ca
      または (nuxwdog watchdog を使用している場合) 
      # systemctl start pki-tomcatd-nuxwdog@pki-ca.service
注記
CA とそのすべてのクローンが新しい KRA トランスポート証明書で更新されている間、移行を完了した CA インスタンスは新しい KRA トランスポート証明書を使用し、まだ更新されていない CA インスタンスは引き続き古い KRA トランスポート証明書を使用します。対応する KRA とそのクローンが両方のトランスポート証明書を使用するよう更新されているため、ダウンタイムは発生しません。
新しいトランスポートキーおよび証明書のみを使用するように KRA 設定を更新
KRA とその各クローンについて、以下を実行します。
  1. KRA NSS データベースディレクトリーに移動します。 
    # cd /etc/pki/pki-kra/alias
  2. KRA を停止します。 
    # pki-server stop pki-kra
    または (nuxwdog watchdog を使用している場合) 
    # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
  3. 新しい KRA トランスポート証明書がインポートされていることを確認します。 
    # certutil -d . -L
# certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
  4. /var/lib/pki/pki-kra/kra/conf/CS.cfg ファイルを開き、以下の行に含まれる nickName の値を見つけます。 
    kra.transportUnit.nickName=transportCert cert-pki-kra KRA
    nickName の値を、以下の行に含まれる newNickName 値に置き換えます。 
    kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
    これにより、CS.cfg ファイルに以下の行が含まれます。 
    kra.transportUnit.nickName=transportCert-serial_number cert-pki-kra KRA
  5. /var/lib/pki/pki-kra/kra/conf/CS.cfg から以下の行を削除します。 
    kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
  6. KRA を起動します。 
    # pki-server start pki-kra
    または (nuxwdog watchdog を使用している場合) 
    # systemctl start pki-tomcatd-nuxwdog@pki-kra.service