17.3. エージェント承認キーリカバリースキームの設定
キーリカバリーエージェントは、PKCS #12 パッケージ内の秘密暗号化キーと関連する証明書をまとめて承認および取得します。キーリカバリーを承認するには、必要な数のリカバリーエージェントが KRA エージェントサービスページにアクセスし、Authorize Recovery 領域を使用して各承認を個別に入力します。
エージェントの 1 つが、キーリカバリープロセスを開始します。同期リカバリーの場合、各承認エージェントは、(最初のリクエストで返された) 参照番号を使用して要求をオープンにし、その後、個別に鍵のリカバリーを承認します。非同期リカバリーの場合、承認エージェントはすべてキーリカバリー要求を検索してから、キーリカバリーを承認します。すべての承認が指定されている場合に、KRA は情報を確認します。提示された情報が正しい場合は、要求されたキーを取得し、PKCS #12 パッケージの形式で、キーリカバリープロセスを開始したエージェントに、対応する証明書を返します。
キーリカバリーエージェントスキーム は、キーリカバリーエージェントが属するグループを認識するように KRA を設定し、アーカイブされた鍵を復元する前にキーリカバリー要求を承認するために必要なこれらのエージェントの数を指定します。
17.3.1. コマンドラインでのエージェント承認キーリカバリーの設定
エージェントが開始するキーリカバリーを設定するには、KRA 設定で 2 つのパラメーターを編集します。
- リカバリーの承認に必要なリカバリーマネージャーの数を設定します。
- これらのユーザーが属する必要のあるグループを設定します。
これらのパラメーターは、KRA の
CS.cfg 設定ファイルで設定されます。
- 設定ファイルを編集する前にサーバーを停止します。
# systemctl stop pki-tomcatd@instance_name.service
または (nuxwdog watchdogを使用している場合)# systemctl stop pki-tomcatd-nuxwdog@instance_name.service
- KRA の
CS.cfgファイルを開きます。# vim /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
- 2 つのリカバリースキームパラメーターを編集します。
kra.noOfRequiredRecoveryAgents=3 kra.recoveryAgentGroup=Key Recovery Authority Agents
- サービスを再起動します。
# systemctl start pki-tomcatd@instance_name.service
または# systemctl start pki-tomcatd-nuxwdog@instance_name.service
注記
コンソールでエージェント承認済みキーリカバリーを設定する方法は、『Red Hat Certificate System 管理ガイド』 の 『コンソールでのエージェント承認キーリカバリーの設定』 を参照してください。
17.3.2. キーリカバリーフォームのカスタマイズ
デフォルトのキーエージェントスキームでは、キーリカバリー認証局エージェントグループの単一のエージェントがキーリカバリーの承認を担当する必要があります。
キーリカバリー形式の外観をカスタマイズすることもできます。キーリカバリーエージェントには、キーリカバリープロセスを開始するための適切なページが必要です。デフォルトでは、KRA のエージェントサービスページには、キーリカバリーエージェントがキーリカバリーを開始し、キーリカバリー要求を承認し、暗号化キーを取得できるようにする適切な HTML フォームが含まれています。このフォームは、
confirmRecover.html と呼ばれる /var/lib/pki/pki-tomcat/kra/webapps/kra/agent/kra/ ディレクトリーにあります。
重要
キーリカバリーの確認フォームをカスタマイズするには、応答を生成するための情報を削除しないでください。これは、フォームの機能に不可欠です。コンテンツへの変更とフォームの表示を制限します。
17.3.3. 新しいプライベートストレージキーでのキーの再ラップ
一部の秘密鍵 (主に以前のデプロイメントで) は、KRA でアーカイブされた場合に SHA-1、1024 ビットのストレージキーでラップされました。プロセッサーの速度とアルゴリズムが破損しているため、このアルゴリズムはセキュリティーレベルが低くなります。セキュリティー対策として、新しい強力なストレージ鍵 (SHA-256、2048 ビット鍵) で秘密鍵を再ラップできます。
17.3.3.1. KRATool について
キーの再ラップと移動、およびキーの登録とリカバリー要求は、KRATool ユーティリティー (以前のバージョンの Red Hat Certificate System では DRMTool) を使用して行われます。
KRATool は、2 つの操作を実行します。新しい秘密鍵で鍵を再ラップでき、登録やリカバリー要求など、キーレコードの LDIF ファイルエントリーで属性を再配列できます。少なくとも 1 つの操作 (再ラップまたは再番号付け) を実行する必要があり、両方を 1 回の呼び出しで実行できます。
キーを再ラップする場合、ツールは元の KRA のエクスポートされた LDIF ファイルのキーエントリーにアクセスし、元の KRA ストレージキーを使用してキーをアンラップしてから、新しい KRA のより強力なストレージキーでキーを再ラップします。
例17.1 キーの再ラップ
KRATool -kratool_config_file "/usr/share/pki/java-tools/KRATool.cfg" -source_ldif_file "/tmp/files/originalKRA.ldif" -target_ldif_file "/tmp/files/newKRA.ldif" -log_file "/tmp/kratool.log" -source_pki_security_database_path "/tmp/files/" -source_storage_token_name "Internal Key Storage Token" -source_storage_certificate_nickname "storageCert cert-pki-tomcat KRA" -target_storage_certificate_file "/tmp/files/omega.cert"
複数の KRA インスタンスが単一のインスタンスにマージされる場合は、キーまたは要求レコードに競合する CN、DN、シリアル番号、または要求 ID 番号がないことを確認することが重要です。これらの値を処理して、既存の値に新しい大きな数値を追加できます。
例17.2 キーの番号変更
KRATool -kratool_config_file "/usr/share/pki/java-tools/KRATool.cfg" -source_ldif_file "/tmp/files/originalKRA.ldif" -target_ldif_file "/tmp/files/newKRA.ldif" -log_file "/tmp/kratool.log" -append_id_offset 100000000000 -source_kra_naming_context "pki-tomcat-KRA" -target_kra_naming_context "pki-tomcat-2-KRA" -process_requests_and_key_records_only
KRATool オプションとその設定ファイルの詳細は、
KRATool(1) の man ページで説明されています。
17.3.3.2. 1 つまたは複数の KRA から 1 つの KRA へのキーのラップとマージ
この手順では、1 つ以上の Certificate System KRA (たとえば、sourcekra.example.comの
pki-tomcat) に保存されているキーを再ラップし、それを別の Certificate System KRA (たとえば targetkra.example.com の pki-tomcat-2) に保存します。これが唯一のユースケースではありません。このツールは、ソースとターゲットの両方と同じインスタンスで実行して既存のキーを再ラップすることも、キーをまったく再ラップせずに複数の KRA インスタンスから単一のインスタンスにキーをコピーするために使用することもできます。
重要
pki-tomcat-2 KRA ストレージ鍵のサイズとタイプは、2048 ビットおよび RSA に設定する必要があります。
- targetkra.example.com にログインします。
pki-tomcat-2KRA を停止します。[root@targetkra ~]# systemctl stop pki-tomcatd@pki-tomcat-2.service
- sourcekra.example.com にある
pki-tomcatKRA インスタンスからインポートされるキーデータを保存するデータディレクトリーを作成します。[root@targetkra ~]# mkdir -p /export/pki
pki-tomcat-2KRA のパブリックストレージ証明書を、新規データディレクトリーのフラットファイルにエクスポートします。[root@targetkra ~]# certutil -L -d /var/lib/pki/pki-tomcat-2/alias -n "storageCert cert-pki-tomcat-2 KRA" -a > /export/pki/targetKRA.cert
- 同じマシンにある場合は、
pki-tomcat-2KRA の Directory Server インスタンスを停止します。[root@newkra ~]# systemctl stop dirsrv.target
pki-tomcat-2KRA の設定情報をエクスポートします。root@targetkra ~]# grep nsslapd-localuser /etc/dirsrv/slapd-instanceName/dse.ldif nsslapd-localuser: dirsrv [root@targetkra ~]# chown dirsrv:dirsrv /export/pki [root@targetkra ~]# /usr/lib64/dirsrv/slapd-instanceName/db2ldif -n pki-tomcat-2-KRA -a /export/pki/pki-tomcat-2.ldif
重要LDIF ファイルの最後に 1 行の空白行が含まれていることを確認してください。- sourcekra.example.com にログインします。
pki-tomcatKRA を停止します。[root@sourcekra ~]# systemctl stop pki-tomcatd@pki-tomcat.service
- targetkra.example.com にある
pki-tomcat-2KRA インスタンスにエクスポートされるキーデータを保存するデータディレクトリーを作成します。[root@sourcekra ~]# mkdir -p /export/pki
- 同じマシンにある場合は、
pki-tomcatKRA の Directory Server インスタンスを停止します。[root@sourcekra ~]# systemctl stop dirsrv.target
pki-tomcatKRA の設定情報をエクスポートします。[root@sourcekra ~]# grep nsslapd-localuser /etc/dirsrv/slapd-instanceName/dse.ldif nsslapd-localuser: dirsrv [root@sourcekra ~]# chown dirsrv:dirsrv /export/pki [root@sourcekra ~]# /usr/lib64/dirsrv/slapd-instanceName/db2ldif -n pki-tomcat-KRA -a /export/pki/pki-tomcat.ldif
重要LDIF ファイルの最後に 1 行の空白行が含まれていることを確認してください。- このディレクトリーに
pki-tomcatKRA NSS セキュリティーデータベースをコピーします。[root@sourcekra ~]# cp -p /var/lib/pki/pki-tomcat/alias/cert9.db /export/pki [root@sourcekra ~]# cp -p /var/lib/pki/pki-tomcat/alias/key4.db /export/pki [root@sourcekra ~]# cp -p /var/lib/pki/pki-tomcat/alias/pkcs11.txt /export/pki
- パブリックストレージキーを持つファイルを
pki-tomcat-2KRA マシンからこのマシンにコピーします。以下に例を示します。[root@sourcekra ~]# cd /export/pki [root@sourcekra ~]# sftp root@targetkra.example.com sftp> cd /export/pki sftp> get targetKRA.cert sftp> quit
- 必要に応じて、このツールで使用するデフォルトの
KRATool.cfgファイルを編集します。デフォルトのファイルは、変更せずに使用することもできます。 - KRATool を実行します。これらのパラメーターはすべて 1 行にまとめる必要があります。
[root@sourcekra ~]# KRATool -kratool_config_file "/usr/share/pki/java-tools/KRATool.cfg" -source_ldif_file /export/pki/pki-tomcat.ldif \ -target_ldif_file /export/pki/source2targetKRA.ldif \ -log_file /export/pki/kratool.log \ -source_pki_security_database_path /export/pki \ -source_storage_token_name 'Internal Key Storage Token' \ -source_storage_certificate_nickname 'storageCert cert-pki-tomcat KRA' \ -target_storage_certificate_file /export/pki/targetKRA.cert -append_id_offset 100000000000 \ -source_kra_naming_context "pki-tomcat-KRA" \ -target_kra_naming_context "pki-tomcat-2-KRA" \ -process_requests_and_key_records_only注記コマンドは、pki-tomcatKRA NSS セキュリティーデータベースに保存されているトークンのパスワードの入力を求める場合があります。完了すると、このコマンドは、-target_ldif_fileパラメーターsource2targetKRA.ldifで指定されたファイルを作成します。 - この LDIF ファイルを
pki-tomcat-2KRA マシンにコピーします。以下に例を示します。[root@sourcekra ~]# scp /export/pki/source2targetKRA.ldif root@targetkra.example.com:/export/pki
重要LDIF ファイルの最後に 1 行の空白行が含まれていることを確認してください。 - 複数の KRA インスタンスをマージしている場合、それらのデータは単一のインポート操作にマージできます。マージされるすべての KRA で同じ手順を実施します。重要
-target_ldif_fileパラメーターが LDIF ファイルを作成するように一意の値を指定し、LDIF ファイルが連結したときに競合が発生しないように一意の-append_id_offset値を指定します。 pki-tomcat-2KRA マシンに、pki-tomcat-2KRA 設定 LDIF ファイル、およびその他の KRA インスタンス用にエクスポートされたすべての LDIF ファイルを連結して、LDIF ファイルを他のキーデータとともにインポートします。以下に例を示します。[root@targetkra ~]# cd /export/pki [root@targetkra ~]# cat pki-tomcat-2.ldif source2targetKRA.ldif > combined.ldif
pki-tomcat-2KRA インスタンス用に、この組み合わせた LDIF ファイルを Directory Server データベースにインポートします。[root@targetkra ~]# /usr/lib64/dirsrv/slapd-instanceName/ldif2db -n pki-tomcat-2-KRA -i /export/pki/combined.ldif
pki-tomcat-2KRA の Directory Server インスタンスを起動します。[root@targetkra ~]# systemctl start dirsrv.target
pki-tomcat-2KRA を起動します。[root@targetkra ~]# systemctl start pki-tomcatd@pki-tomcat-2.service
17.3.4. クローン後の CA-KRA コネクター情報の更新
クローン後の CA-KRA 情報の更新に関する詳細は、「クローン後の CA-KRA コネクター情報の更新」 を参照してください。
