Menu Close

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

Red Hat Certificate System は、RHEL 7 の RHCS 9 から RHEL 8 の RHCS 10 にアップグレードする方法の 2 つの方法をサポートします。

21.1. 既存の CA ファイルを使用した CA の移行

既存の証明書ファイルを使用した Certificate System の移行には、以下の手順が必要です。
  1. 「以前のシステムからのデータのエクスポート」
  2. 「新規ホストでの CA の設定」
  3. 「新規 CA へのデータのインポート」
  4. 「デフォルトグループにユーザーの再割り当て」
重要
HSM が使用されている場合、署名証明書が更新され、同じキーを使用して再発行された場合、同じニックネームを持つ複数の証明書が HSM に存在する可能性があります。これにより、pkispawn が正しい証明書の取得に失敗し、移行が正常に行われなくなる可能性がありました。したがって、移行を開始する前に、HSM の古い、重複した証明書エントリーを削除してください。

21.1.1. 以前のシステムからのデータのエクスポート

新しい Certificate System インスタンスを設定する前に、certutil ツールを使用して現在の認証局 (CA) のデータをエクスポートします。
  1. 古い CA から CRT および CSR をエクスポートするには、以下の手順を使用します。
    1. CRT を生成します。 
      # certutil -L -d /var/lib/instance_name/alias/ -n "caSigningCert cert-instance_name" -a > ca_signing.crt
    2. CSR を生成します。 
      	# echo "-----BEGIN NEW CERTIFICATE REQUEST-----" > ca_signing.csr
	# sed -n "/^ca.signing.certreq=/ s/^[^=]*=// p" < /var/lib/instance_name/conf/CS.cfg >> ca_signing.csr
	# echo "-----END NEW CERTIFICATE REQUEST-----" >> ca_signing.csr
  2. 古い CA が (チェーン内に単一のルート CA を持つ) 中間CAである場合は、NSS データベースからルート CA を抽出します。 
    # certutil -L -d /var/lib/pki/instance_name/alias/ -n "root_CA_nickname" -a > ca_rootca_signing.crt
  3. 以下の手順を使用して、データベースのバックアップを作成します。
    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 ユーザーとして実行されるため、書き込みパーミッションがある宛先フォルダーが必要になります。
  4. エクスポートしたファイル (中間 CA インスタンスの場合は ca_signing.crt, ca_signing.csr, old_ca.ldif、および ca_rootca_signing.crt) を、新しい CA インスタンスをホストする RHEL 8 マシンに転送します。

21.1.2. 新規ホストでの CA の設定

「以前のシステムからのデータのエクスポート」 の既存のインスタンスからデータをエクスポートしたら、新しいホストに認証局 (CA) を設定します。
  1. 古い CA のパラメーターを使用して、pkispawn の設定ファイル (CA.cfg など) を作成します。pkispawn パラメーターの詳細は、以下の手順の 表21.1「pkispawn パラメーターの説明」 を参照してください。 
    [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_hsm_enable=True
	pki_hsm_libfile=path_to_HSM_library
	pki_hsm_modulename=HSM_module_name
	pki_token_name=HSM_token_name
	pki_token_password=HSM_token_password
	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_ca_signing_token=HSM_token_name
	pki_ds_base_dn=o=pki-tomcat-CA
	pki_ds_database=instance_name-CA
	pki_serial_number_range_start=4e
	pki_request_number_range_start=30
	pki_master_crl_enable=False
	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

表21.1 pkispawn パラメーターの説明

パラメーターおよび設定
説明
pki_instance_name
新しいインスタンスに別の名前を付けない場合は、HSM で古いシステム証明書と競合しないように、すべてのシステム証明書のニックネームを必ず定義する必要があります。実際には、どのような場合でも、すべてのニックネームを定義することをお勧めします。CA 署名証明書のニックネームは古い CA と同じになります。
pki_hsm_* および pki_token_*
これらのパラメーターにより、HSM との通信が可能になります。
pki_existing=True
既存の CA メカニズムを使用するように設定します。
pki_ca_signing_nickname
CA 署名ニックネームは、前のインストールで使用されたものとまったく同じである必要があります。そうでない場合、インストーラーは署名キーを見つけることができません。
pki_ca_signing_*
証明書署名要求 (CSR) および既存のマシンからコピーされた証明書ファイルへのパスを設定します。
pki_ds_base_dn
Directory Server ベース識別名 (DN) を設定します。古いデータを簡単にインポートできるように、以前の CA と同じ値を使用する必要があります。この値は、古い CA の /var/lib/instance_name/conf/CS.cfg ファイルの internaldb.basedn パラメーターにあります。
pki_serial_number_range_start
シリアル番号は重要です。値は、以前の CA で使用される最後の数値よりも高くする必要があります。すでに使用されている番号を表示するには、古い CA のエージェントインターフェースを参照してください。このパラメーターは、先頭に 0x の接頭辞なしで 16 進形式で設定されます。例 (4e) で使用される値は、10 進数の 78 です。
pki_request_number_range_start
リクエスト番号が重要である。値は、以前の CA で使用される最後の数値よりも高くする必要があります。すでに使用されている番号を表示するには、古い CA のエージェントインターフェースを参照してください。値は 10 進数の形式で設定されます。
pki_master_crl_enable=False
セットアップ中の証明書失効リスト (CRL) の初期作成と公開を防ぎます。代わりに、CRL はデータベースの移行時に古いデータからインポートされます。
pki_cert_chain_path および pki_cert_chain_nickname
古い CA が中間 CA の場合にのみ、これらのパラメーターを設定します。この場合、ルート CA 証明書ファイルへのパスと、証明書を Network Security Services (NSS) データベースに保存するときに使用するニックネームにパラメーターを設定します。
詳細およびパラメーターの説明は、man ページの pkispawn(8) を参照してください。

21.1.3. 新規 CA へのデータのインポート

「新規ホストでの CA の設定」で新規 CA インスタンスを作成した後に、データを新規 CA データベースにインポートします。
  1. 以前のバージョンから移行する場合、「以前のシステムからのデータのエクスポート」 で作成された LDAP データ交換形式 (LDIF) ファイルを手動でクリーンアップしないといけない場合があります。構文チェックがデフォルトで有効になっているため、古いデータには、新しいデータベースでは無効になるエントリーが含まれている可能性があります。以下に例を示します。
    • ブール値属性の値を TRUE または FALSE (すべて大文字) に設定する必要があります。
      重要
      検索および置換ユーティリティを使用して、すべての出現箇所を自動的に大文字に更新しないでください。LDIF ファイルの一部の属性にはこれらの文字列が含まれますが、ブール値タイプを使用しません。これらの属性の値を更新すると、インポートが失敗する場合があります。通常、ブール値属性は cn=CAList,ou=Security Domain,CS_instance_name セキュリティードメインデータベースエントリーでのみ使用されます。
    • 構文の検証では空の文字列は使用できません。解決策として、その属性に対応する行を削除することです。
      空の文字列は、ou=People,CS_instance_name の cmsUser エントリーに含まれる userType と userState の属性で頻繁に表示されます。
    インポート中に、他のエントリーも構文チェックに失敗することがあります。したがって、操作後にログファイルを確認することが重要です。必要に応じて、LDIF ファイルを一時的な空のデータベースにインポートして、インポートに失敗したエントリーを見つけることができます。または、事前に空のデータベースにテストインポートを実行します。
  2. CA サービスをシャットダウンします。 
    # systemctl stop pki-tomcatd@instance_name.service
  3. 必要に応じて、新しいホストの CA データベースをバックアップします。 
    # db2bak
    バックアップは、/var/lib/dirsrv/instance_name/bak/host_name-time_stamp/ ディレクトリーに保存されます。
  4. ldapdelete コマンドを実行して、インポートされた署名証明書のシリアル番号を使用して、新しい RHEL 8 内部データベースから署名証明書の証明書エントリーを削除します。新しいデータベースからエントリーを削除すると、このエントリーが古いデータからインポートされるため、そのエントリーの CRL 属性が正しいエントリーを指すようになります。 
    # ldapdelete -x -w password -D 'cn=Directory Manager' "cn={serial_number},ou=certificateRepository,ou=ca,o=pki-tomcat-CA"
  5. ldapmodify ユーティリティーを使用して、データを新規データベースにインポートします。以下に例を示します。 
    # ldapmodify -x -W password -D 'cn=Directory Manager' -a -c -f path/to/old_ca.ldif
    ldapmodify ユーティリティーは新しいエントリーのみを追加し、CA のインストール時に作成された既存のエントリーを更新しません。以下に例を示します。
    • トップレベルエントリー。たとえば、o=pki-tomcat-CAです。
    • デフォルトグループたとえば、cn=Certificate Manager Agents,ou=groups,o=pki-tomcat-CA です。
      標準グループは更新されないため、ユーザーはこれらのグループに自動的に追加されません。インポート後に、各デフォルトグループにメンバーを手動で追加する必要があります。「デフォルトグループにユーザーの再割り当て」を参照してください。
    • CA のデフォルトアクセス制御リスト (ACL)。
    • 署名証明書: このエントリーは、古い署名証明書および鍵をインポートする一部として作成されます。
    前述のように、一部のエントリーは構文の検証に失敗する場合があります。import.log ファイルの出力を確認し、失敗したアクション (ldap_add: Invalid syntax (21)など) を検索します。詳細は、ステップ 1 を参照してください。
  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-tomcat@instance_name

21.1.4. デフォルトグループにユーザーの再割り当て

「新規 CA へのデータのインポート」で説明したように、データのインポート時にデフォルトグループのメンバーは復元されません。
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. user アカウントを Certificate Manager Agents、Administrators、および Security Domain Administrators グループに追加します。 
    # pki -n "PKI Administrator for example.com" -c password \
	     user-membership-add user_name "Certificate Manager Agents"

	# 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"