Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第20章 Certificate System 9 から Certificate System 10 へのアップグレード

ユーザーは、Errata-Support チャネルを通じてセキュリティーとバグ修正を入手するために、Red Hat Certificate System の最新バージョンにアップグレードすることを推奨します。現在、最新バージョンは RHEL 7.9 の RHCS 9.7 と RHEL 8.10 の RHCS 10.8 です。

20.1. CA の移行
リンクのコピー

既存の証明書ファイルを使用した Certificate System の移行には、以下の手順が必要です。

  1. 「以前のシステムからのデータのエクスポート」
  2. 「PKCS12 ファイルの確認」
  3. 「新規ホストでの CA の設定」
  4. 「古いデータの新規 CA へのインポート」
  5. 「デフォルトグループにユーザーの再割り当て」

20.1.1. 以前のシステムからのデータのエクスポート
リンクのコピー

新しい Certificate System インスタンスをセットアップする前に、以下の手順を使用して、現在の認証局 (CA) のデータをエクスポートします。この例では、CA のインスタンス名は <pki-rootCA> で、/var/lib/pki/<instance_name> にあります。

  1. CA 署名証明書とキーをエクスポートします。 

    # grep internal= /var/lib/pki/<instance_name>/conf/password.conf | awk -F= '{print $2;}' > internal.txt
# echo <Secret.123> > password.txt
# PKCS12Export -d /var/lib/pki/<instance_name>/alias -p internal.txt -o ca.p12 -w password.txt

  2. 証明書署名要求 (CSR) をエクスポートします。 

    # echo "-----BEGIN NEW CERTIFICATE REQUEST-----" > ca_signing.csr
# sed -n "/^ca.signing.certreq=/ s/[=]*=// p" < /var/lib/pki/<instance_name>/ca/conf/CS.cfg >> ca_signing.csr
# echo "-----END NEW CERTIFICATE REQUEST-----" >> ca_signing.csr

  3. 古い CA が (チェーン内に単一のルート CA を持つ) 中間 CA である場合は、NSS データベースからルート CA を抽出します。 

    # certutil -L -d /var/lib/pki/<instance_name>/alias/ -n root_CA_nickname -a > ca_rootca_signing.crt

  4. 内部 LDAP データベースをバックアップします。

    1. CA の CS.cfg で internaldb.database の値をチェックして、CA データベースの名前を見つけます。 

      # grep internaldb.database /etc/pki/<instance_name>/ca/CS.cfg
	internaldb.database=<CS_database_name>

    2. インスタンスが作成されたら、setup-ds.pl によって生成されたインスタンス固有のスクリプトを使用して、このデータベースを .ldif ファイルにエクスポートします。 

      # cd /usr/lib64/dirsrv/<instance_name>
# ./db2ldif -n "<CS_database_name>" -a /tmp/old_ca.ldif

      db2ldif コマンドは DB ユーザーとして実行されるため、書き込みパーミッションを持つ宛先フォルダーが必要になります。

  5. old_ca.ldif、ca_p12、ca_signing.csr ファイルを新しい CA マシンに転送します。移行する CA が中間 CA でもある場合は、ca_rootca_signing.crt も転送します。

20.1.2. PKCS12 ファイルの確認
リンクのコピー

新しい CA では、新しいデータベースインスタンスが標準ポート (389) で実行されます。PKCS12 ファイルには、古いシステムのすべてのシステム証明書が含まれています。ファイルに CA 署名証明書およびキーが含まれていることを確認します。

注記

FIPS モードでは、NSS データベースを使用して pki pkcs12 コマンドを実行する必要があります。詳細は、pki-pkcs12 CLI を参照してください。

  1. CA 署名証明書およびキーを見つけます。 

    $ echo "<Secret.123>" > password.txt
$ pki pkcs12-cert-find --pkcs12-file ca.p12 --pkcs12-password-file password.txt
$ pki pkcs12-key-find --pkcs12-file ca.p12 --pkcs12-password-file password.txt

  2. CA 署名証明書の信頼フラグが存在することを確認します。フラグが "CTu,Cu,Cu" ではない、またはそれらがない場合は追加します。 

    $ pki pkcs12-cert-mod "<caSigningCert cert-pki-rootCA>" \ --pkcs12-file ca.p12 --pkcs12-password-file password.txt \ --trust-flags "CTu,Cu,Cu"

  3. 他の証明書およびキーを削除します。 

    $ pki pkcs12-cert-del "<Server-Cert cert-pki-rootCA>" --pkcs12-file ca.p12 --pkcs12-password-file password.txt
$ pki pkcs12-cert-del "<subsystemCert cert-pki-rootCA>" --pkcs12-file ca.p12 --pkcs12-password-file password.txt
$ pki pkcs12-cert-del "<ocspSigningCert cert-pki-rootCA>" --pkcs12-file ca.p12 --pkcs12-password-file password.txt
$ pki pkcs12-cert-del "<auditSigningCert cert-pki-rootCA>" --pkcs12-file ca.p12 --pkcs12-password-file password.txt

  4. 移行する CA も中間 CA の場合は、ルート CA 証明書を PKCS#12 ファイルから削除します。 

    $ pki pkcs12-cert-del "<Top-level Root CA Signing Certificate>" --pkcs12-file ca.p12 --pkcs12-password-file password.txt

20.1.3. 新規ホストでの CA の設定
リンクのコピー

既存のインスタンスからデータをエクスポートしたら、新しいホストに認証局 (CA) を作成してセットアップします。

  1. 古い CA のパラメーターを使用して、pkispawn の設定ファイル (例: CA.cfg) を作成します。このインスタンスは標準ポート (389) で実行されます。 

    [DEFAULT]
	pki_instance_name=<new_instance_name>
	pki_admin_password=<caadmin_password>
	pki_client_pkcs12_password=<pkcs12_file_password>
	pki_ds_password=<DS_password>
	pki_ds_ldap_port=389
	pki_existing=True

[CA]
	pki_ca_signing_csr_path=<path/to/ca_signing.csr>
	pki_ca_signing_cert_path=<path/to/ca_signing.crt>
	pki_ca_signing_nickname=<caSigningCert cert-nickname>
	pki_ds_base_dn=<o=pki-tomcat-CA>
	pki_ds_database=<instance_name-CA>
	pki_master_crl_enable=False

    古い CA が中間 CA の場合は、以下の 2 行を設定ファイルに追加します。これらは、ルート CA 証明書へのパスと、NSS データベースに証明書を保存するときに使用するニックネームに対応します。 

    pki_cert_chain_path=<rootca_signing.crt>
pki_cert_chain_nickname=<caSigningCert cert-pki-ca>

  2. 新規ホストで pkispawn を実行して、新規 CA インスタンスを作成します。 

    # pkispawn -s CA -f ca.cfg -vv
注記

新規 CA 用に新しい DS インスタンスをセットアップする方法は、Red Hat Directory Server のインストール を参照してください。

20.1.4. 古いデータの新規 CA へのインポート
リンクのコピー

新しい CA インスタンスを作成した後、データを新しい CA データベースにインポートします。

  1. CA サービスを停止します。 

    # systemctl stop pki-tomcatd@<instance_name>.service

  2. オプション: 新しいホストで CA データベースをバックアップします。 

    # dsctl -v idm-qe-01 db2bak

    バックアップは、/var/lib/dirsrv/<instance_name>/bak/<host_name-time_stamp>/ ディレクトリーに保存されます。

  3. 新しい RHEL 8 内部データベースから、署名証明書の証明書エントリーを削除します。 

    # ldapdelete -x -w <password< -D 'cn=Directory Manager' "cn=<serial_number<,ou=certificateRepository,ou=ca,o=pki-tomcat-CA"

    エントリーが古いデータからインポートされ、そのエントリーの CRL 属性が正しいエントリーをポイントするようになりました。

  4. データを新しいデータベースにインポートします。 

    # ldapmodify -x -W <password> -D 'cn=Directory Manager' -a -c -f <path/to/old_ca.ldif>

    ldapmodify ユーティリティーは新しいエントリーのみを追加し、CA のインストール時に作成された既存のエントリーを更新しません。

  5. オプション: import.log ファイルの出力を確認します。ldap_add: Invalid syntax (21) など、失敗したアクションを検索できます。

  6. 古いセキュリティードメインのディレクトリーエントリーを削除します。 

    # ldapmodify -W <password> -x -D "cn=Directory Manager"
dn: cn=<server.example.com:9445>,cn=CAList,ou=Security Domain,<o=pki-tomcat-CA>
changetype: delete

  7. CA が証明書失効リスト (CRL) マスターとして機能するように、/etc/pki/<instance_name>/ca/CS.cfg ファイルで ca.crl.MasterCRL.enable パラメーターを有効にします。 

    ca.crl.MasterCRL.enable=true

  8. CA サービスを起動します。 

    # systemctl start pki-tomcatd@<instance_name>

20.1.5. デフォルトグループにユーザーの再割り当て
リンクのコピー

ldapmodify ユーティリティーまたは pki ユーティリティーを使用して、デフォルトのグループにメンバーを手動で追加します。

  1. クライアントを設定します。 

    # pki -c <password> client-init
Client initialized
     
    # pk12util -i ~/.dogtag/<instance_name>/ca_admin_cert.p12 -d ~/.dogtag/nssdb/
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
pk12util: PKCS12 IMPORT SUCCESSFUL

  2. ユーザー アカウントを Administrators および Security Domain Administrators グループに追加します。 

    # pki -n "<PKI Administrator for example.com>" -c <password> \
user-membership-add <user_name> "Certificate Manager Agents"

    RHCS 9 と RHCS 10 のデフォルト (ブートストラップ) 管理者ユーザーは、同じデフォルトのロール、つまり同じグループメンバーシップを持っています。ただし、デフォルト以外の管理者ユーザーがいる場合や、RHCS 9 で管理者ロールをカスタマイズしている場合は、これらの変更が適切に移行されない可能性があります。この場合は、RHCS 10 でロールを再設定します。 

    # pki -n "<PKI Administrator for example.com>" -c <password> \
user-membership-add <user> "Administrators"
# pki -n "<PKI Administrator for example.com>" -c <password> \
user-membership-add <user> "Security Domain Administrators"

証明書が正常に移行されたことを確認する場合は、ca-cert-find コマンドを実行して、新しいホストに存在することを確認します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る