2.4. PKI (証明書システムあり)

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 管理ガイド』 の 『CMC 認証プラグイン』 セクションおよび 「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 以外で発行された証明書は、システム内で信頼できます。