第17章 サブシステム証明書の管理
この章では、証明書の使用の概要を示します。使用できるタイプと形式、HTML エンドエンティティーフォームと Certificate System コンソールを使用して証明書を要求および作成する方法、Certificate System とさまざまなクライアントに証明書をインストールする方法です。さらに、コンソールを介した証明書の管理と、証明書を使用するためのサーバー設定に関する情報があります。
17.1. 必要なサブシステム証明書
各サブシステムには、操作を実行するためにサブシステムインスタンスに発行する必要のある証明書の定義されたセットがあります。Certificate Manager の設定中に設定される証明書の内容の特定の詳細があり、証明書のタイプに応じて制約、設定、および属性に関するさまざまな考慮事項があります。証明書のフォーマットの計画は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 を参照してください。
17.1.1. 証明書マネージャー証明書
Certificate Manager がインストールされると、CA 署名証明書、SSL サーバー証明書、および OCSP 署名証明書の鍵および要求が生成されます。この証明書は、設定を完了する前に作成されます。
CA 証明書要求は、CA への自己署名リクエストとして送信されます。次に、証明書を発行して自己署名ルート CA の作成を終了するか、サードパーティーのパブリック CA または別の Certificate System CA に送信されます。外部 CA が証明書を返すと、証明書がインストールされ、下位 CA のインストールが完了します。
17.1.1.1. CA 署名キーペアおよび証明書
すべての Certificate Manager には、Certificate Manager が発行する証明書と CRL に署名するために使用する秘密鍵に対応する公開鍵を持つ CA 署名証明書があります。この証明書は、Certificate Manager のインストール時に作成され、インストールされます。証明書のデフォルトのニックネームは caSigningCert cert-instance_ID CA です。ここで、instance_ID は Certificate Manager インスタンスを識別します。証明書のデフォルトの有効期間は 5 年間です。
CA 署名証明書のサブジェクト名は、インストール時に設定された CA の名前を反映します。Certificate Manager によって署名または発行されたすべての証明書には、証明書の発行者を識別するためにこの名前が含まれています。
Certificate Manager のステータスがルートまたは下位 CA として評価されるかどうかは、その CA 署名証明書が自己署名の証明書であるか、または別の CA により署名されているかにより決まります。これは、証明書のサブジェクト名に影響します。
- Certificate Manager がルート CA の場合、その CA 署名証明書は自己署名の証明書です。つまり、証明書のサブジェクト名と発行者名は同じです。
- Certificate Manager が下位 CA である場合、その CA 署名証明書は別の CA、通常は CA 階層の上位レベル (ルート CA である場合とそうでない場合があります) によって署名されます。Certificate Manager を使用して証明書を発行する前に、ルート CA の署名証明書を個別のクライアントおよびサーバーにインポートする必要があります。
注記
CA 名を変更 できない か、以前に発行された証明書がすべて無効化されている。同様に、新しい鍵ペアで CA 署名証明書を再発行し、古い鍵ペアで署名された証明書をすべて無効にします。
17.1.1.2. OCSP 署名キーペアおよび証明書
OCSP 署名証明書のサブジェクト名は cn=OCSP cert-instance_ID CA の形式であり、OCSP レスポンスの署名に必要な拡張機能 (OCSPSigning および OCSPNoCheck など) が含まれます。
OCSP 署名証明書の公開鍵に対応する OCSP 秘密鍵は、証明書失効リストのステータスをクエリーするときに Certificate Manager が OCSP 準拠のクライアントに署名するために使用されます。
17.1.1.3. サブシステム証明書
セキュリティードメインのすべてのメンバーには、サーバー SSL 証明書とは別のドメインメンバー間の通信に使用するサーバー証明書が発行されます。この証明書はセキュリティードメイン CA によって署名されます。セキュリティードメイン CA 自体の場合は、そのサブシステム証明書自体によって署名されます。
証明書のデフォルトのニックネームは subsystemCert cert-instance_ID です。
17.1.1.4. SSL サーバーキーペアおよび証明書
すべての証明書マネージャーには、証明書マネージャーのインストール時に最初に生成された SSL サーバー証明書が少なくとも 1 つ含まれます。証明書のデフォルトのニックネームは Server-Cert cert-instance_ID です。instance_ID は証明書マネージャーインスタンスを識別します。
デフォルトでは、認証に Certificate Manager は SSL サーバー証明書を使用します。ただし、エンドエンティティーサービスインターフェイスとエージェントサービスインターフェイスへの認証に個別のサーバー証明書を使用するように証明書マネージャーを設定するなど、さまざまな操作に使用する追加のサーバー証明書を要求できます。
Certificate Manager が公開ディレクトリーとの SSL 対応通信用に設定されている場合、デフォルトではクライアント認証に SSL サーバー証明書を使用します。証明書マネージャーは、SSL クライアント認証に別の証明書を使用するように設定することもできます。
17.1.1.5. Audit ログ署名キーペアおよび証明書
CA は、サーバーで発生したすべてのイベントのセキュアな監査ログを保持します。監査ログが改ざんされていないことを保証するために、ログファイルは特別なログ署名証明書によって署名されます。
監査ログ署名証明書は、サーバーの初回設定時に発行されます。
注記
その他の証明書は ECC キーを使用できますが、監査署名証明書は 常に RSA キーを使用する必要があります。
17.1.2. オンライン証明書ステータスマネージャーの証明書
Online Certificate Status Manager が最初に設定されていると、必要な証明書の鍵がすべて作成され、OCSP 署名、SSL サーバー、監査ログ署名、およびサブシステム証明書の証明書要求が作成されます。これらの証明書要求は CA (Certificate System CA またはサードパーティー CA のいずれか) に送信され、設定プロセスを完了するには Online Certificate Status Manager データベースにインストールする必要があります。
17.1.2.1. OCSP 署名キーペアおよび証明書
すべての Online Certificate Status Manager には、証明書である OCSP 署名証明書があります。これには、Online Certificate Status Manager が OCSP 応答に署名するために使用する秘密鍵に対応する公開鍵があります。Online Certificate Status Manager の署名は、Online Certificate Status Manager がリクエストを処理している永続的な証明を提供します。この証明書は、Online Certificate Status Manager が設定されている場合に生成されます。証明書のデフォルトのニックネームは ocspSigningCert cert-instance_ID で、instance_ID OSCP は Online Certificate Status Manager インスタンス名です。
17.1.2.2. SSL サーバーキーペアおよび証明書
すべての Online Certificate Status Manager には、Online Certificate Status Manager の設定時に生成された SSL サーバー証明書が少なくとも 1 つ含まれます。証明書のデフォルトのニックネームは Server-Cert cert-instance_ID です。ここで、instance_ID は Online Certificate Status Manager インスタンス名を識別します。
Online Certificate Status Manager は、Online Certificate Status Manager エージェントサービスページでサーバー側の認証にサーバー証明書を使用します。
Online Certificate Status Manager は認証目的で単一のサーバー証明書を使用します。追加のサーバー証明書をインストールして、さまざまな目的で使用できます。
17.1.2.3. サブシステム証明書
セキュリティードメインのすべてのメンバーには、サーバー SSL 証明書とは別のドメインメンバー間の通信に使用するサーバー証明書が発行されます。この証明書はセキュリティードメイン CA によって署名されます。
証明書のデフォルトのニックネームは subsystemCert cert-instance_ID です。
17.1.2.4. Audit ログ署名キーペアおよび証明書
OCSP は、サーバーで発生したすべてのイベントのセキュアな監査ログを保持します。監査ログが改ざんされていないことを保証するために、ログファイルは特別なログ署名証明書によって署名されます。
監査ログ署名証明書は、サーバーの初回設定時に発行されます。
注記
その他の証明書は ECC キーを使用できますが、監査署名証明書は 常に RSA キーを使用する必要があります。
17.1.2.5. オンライン証明書ステータスマネージャー証明書の認識
Online Certificate Status Manager の SSL サーバー証明書に署名した CA によっては、Certificate Manager が認識する証明書および発行する CA を取得しないといけない場合があります。
- Online Certificate Status Manager のサーバー証明書が CRL を公開している CA によって署名されている場合は、何もする必要はありません。
- Online Certificate Status Manager のサーバー証明書が、下位の Certificate Manager の証明書に署名したのと同じルート CA によって署名されている場合、ルート CA は、下位の Certificate Manager の証明書データベースで信頼できる CA としてマークする必要があります。
- Online Certificate Status Manager の SSL サーバー証明書が別のルート CA によって署名されている場合は、ルート CA 証明書を下位の Certificate Manager の証明書データベースにインポートし、信頼できる CA としてマークする必要があります。
Online Certificate Status Manager のサーバー証明書が、選択したセキュリティードメインの CA によって署名されている場合は、Online Certificate Status Manager の設定時に証明書チェーンがインポートされ、マークされます。他の設定は必要ありません。ただし、サーバー証明書が外部 CA で署名されている場合は、設定を完了するために証明書チェーンをインポートする必要があります。
注記
セキュリティードメイン内のすべての CA が、設定時に OCSP Manager によって自動的に信頼されるわけではありません。ただし、CA パネルで設定された CA の証明書チェーン内のすべての CA は、OCSP Manager によって自動的に信頼されます。セキュリティードメイン内にあるが証明書チェーンにはない他の CA は、手動で追加する必要があります。
17.1.3. キーリカバリー認証局の証明書
17.1.3.1. トランスポートキーペアおよび証明書
17.1.3.2. ストレージキーペア
すべての KRA にはストレージキーペアがあります。 KRA は、このキーペアの公開コンポーネントを使用して、キーをアーカイブするときに秘密暗号化キーを暗号化 (またはラップ) します。プライベートコンポーネントを使用して、リカバリー中にアーカイブされたキーを復号化 (またはアンラップ) します。このキーペアの使用方法に関する詳細は、4章キーアーカイブおよびリカバリーの設定 を参照してください。
ストレージキーで暗号化したキーは、承認されたキーリカバリーエージェントによりのみ取得できます。
17.1.3.3. SSL サーバー証明書
すべての Certificate System KRA には、少なくとも 1 つの SSL サーバー証明書があります。最初の SSL サーバー証明書は、KRA が設定される際に生成されます。証明書のデフォルトのニックネームは Server-Cert cert-instance_ID です。instance_id は KRA インスタンスを識別します。
KRA の SSL サーバー証明書は、証明書要求が送信される CA により発行されました。これは Certificate System CA またはサードパーティー CA です。発行者名を表示するには、KRA コンソールの System Keys and Certificates オプションで証明書の詳細を開きます。
KRA は、KRA エージェントサービスインターフェイスに対するサーバー側の認証に SSL サーバー証明書を使用します。デフォルトでは、Key Recovery Authority は認証に単一の SSL サーバー証明書を使用します。ただし、追加の SSL サーバー証明書を要求し、KRA にインストールすることができます。
17.1.3.4. サブシステム証明書
セキュリティードメインのすべてのメンバーには、サーバー SSL 証明書とは別のドメインメンバー間の通信に使用するサーバー証明書が発行されます。この証明書はセキュリティードメイン CA によって署名されます。
証明書のデフォルトのニックネームは subsystemCert cert-instance_ID です。
17.1.3.5. Audit ログ署名キーペアおよび証明書
KRA は、サーバーで発生したすべてのイベントのセキュアな監査ログを保持します。監査ログが改ざんされていないことを保証するために、ログファイルは特別なログ署名証明書によって署名されます。
監査ログ署名証明書は、サーバーの初回設定時に発行されます。
注記
その他の証明書は ECC キーを使用できますが、監査署名証明書は 常に RSA キーを使用する必要があります。
17.1.4. TKS 証明書
TKS には 3 つの証明書があります。SSL サーバーおよびサブシステムの証明書が標準の操作に使用されます。監査ログの保護には、追加の署名証明書が使用されます。
17.1.4.1. SSL サーバー証明書
すべての Certificate System TKS には、少なくとも 1 つの SSL サーバー証明書があります。最初の SSL サーバー証明書は、TKS が設定される際に生成されます。証明書のデフォルトのニックネームは Server-Cert cert-instance_ID です。
17.1.4.2. サブシステム証明書
セキュリティードメインのすべてのメンバーには、サーバー SSL 証明書とは別のドメインメンバー間の通信に使用するサーバー証明書が発行されます。この証明書はセキュリティードメイン CA によって署名されます。
証明書のデフォルトのニックネームは subsystemCert cert-instance_ID です。
17.1.4.3. Audit ログ署名キーペアおよび証明書
TKS は、サーバーで発生したすべてのイベントのセキュアな監査ログを保持します。監査ログが改ざんされていないことを保証するために、ログファイルは特別なログ署名証明書によって署名されます。
監査ログ署名証明書は、サーバーの初回設定時に発行されます。
注記
その他の証明書は ECC キーを使用できますが、監査署名証明書は 常に RSA キーを使用する必要があります。
17.1.5. TPS 証明書
TPS は、サーバー証明書、サブシステム証明書、監査ログ署名証明書の 3 つの証明書のみを使用します。
17.1.5.1. SSL サーバー証明書
すべての Certificate System TPS には、少なくとも 1 つの SSL サーバー証明書があります。TPS が設定されると、最初の SSL サーバー証明書が生成されます。証明書のデフォルトのニックネームは Server-Cert cert-instance_ID です。
17.1.5.2. サブシステム証明書
セキュリティードメインのすべてのメンバーには、サーバー SSL 証明書とは別のドメインメンバー間の通信に使用するサーバー証明書が発行されます。この証明書はセキュリティードメイン CA によって署名されます。
証明書のデフォルトのニックネームは subsystemCert cert-instance_ID です。
17.1.5.3. Audit ログ署名キーペアおよび証明書
TPS は、サーバーで発生したすべてのイベントのセキュアな監査ログを保持します。監査ログが改ざんされていないことを保証するために、ログファイルは特別なログ署名証明書によって署名されます。
監査ログ署名証明書は、サーバーの初回設定時に発行されます。
17.1.6. サブシステム証明書のキータイプについて
新規インスタンスの作成時には、
pkispawn ユーティリティーに渡される設定ファイルでキーのタイプとキーサイズを指定できます。
例17.1 CA のキータイプ関連の設定パラメーター
以下は、例の値を含む主要なタイプ関連のパラメーターです。これらのパラメーターは、新規 CA の作成時に
pkispawn に渡される設定ファイルで設定できます。
pki_ocsp_signing_key_algorithm=SHA256withRSA pki_ocsp_signing_key_size=2048 pki_ocsp_signing_key_type=rsa pki_ca_signing_key_algorithm=SHA256withRSA pki_ca_signing_key_size=2048 pki_ca_signing_key_type=rsa pki_sslserver_key_algorithm=SHA256withRSA pki_sslserver_key_size=2048 pki_sslserver_key_type=rsa pki_subsystem_key_algorithm=SHA256withRSA pki_subsystem_key_size=2048 pki_subsystem_key_type=rsa pki_admin_keysize=2048 pki_admin_key_size=2048 pki_admin_key_type=rsa pki_audit_signing_key_algorithm=SHA256withRSA pki_audit_signing_key_size=2048 pki_audit_signing_key_type=rsa
注記
サンプルの値は CA 用です。他のサブシステムには異なるパラメーターが必要です。
詳細は、以下を参照してください。
- 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の『
ユーティリティーの理解』 セクション - パラメーターおよび例の説明の pki_default.cfg(5) man ページ。
17.1.7. HSM を使用したサブシステム証明書の保存
デフォルトでは、鍵と証明書は、
/var/lib/pki/instance_name/alias ディレクトリーのローカル管理のデータベースである key4.db および cert9.db に保存されます。ただし、Red Hat Certificate System は、ハードウェアセキュリティーモジュール (HSM) もサポートします。この外部デバイスは、ネットワーク上にある集中的な場所に鍵と証明書を保存できます。HSM を使用すると、インスタンスのキーと証明書に簡単にアクセスできるため、クローン作成などの一部の機能が簡単になります。
HSM を使用して証明書を保存する場合、HSM 名は証明書のニックネームに付加され、
server.xml ファイルなどのサブシステム設定にフルネームが使用されます。以下に例を示します。
serverCert="nethsm:Server-Cert cert-instance_ID
注記
1 つの HSM を使用して、複数のホストにインストールする可能性がある複数のサブシステムインスタンスの証明書および鍵を保存することができます。HSM を使用する場合、サブシステムの証明書ニックネームは HSM で管理される各サブシステムインスタンスに対して一意である必要があります。
証明書システムは、nCipher netHSM と Chrysalis LunaSA の 2 種類の HSM に対応します。
