第22章 期限切れのシステム証明書の回復

手順

1. IdM サービスが実行されていることを確認します。

   # ipactl status

2. オプション: いずれかのサービスが実行されていない場合は、強制的に起動します。

   # ipactl start -f

   -f または --force フラグは、起動チェックの一部を省略します。これは、証明書の期限切れによりサービスが通信できない場合に必要です。

3. 更新サーバーと障害が発生したレプリカ間で、RA エージェント証明書とサブシステム証明書を比較します。

   正常な更新サーバーと障害が発生したレプリカの両方で、RA エージェント証明書とサブシステム証明書のシリアル番号を取得し、それらが同一であることを確認します。

   1. RA エージェント証明書とそれに対応する LDAP エントリー。シリアル番号は、セミコロンで区切られた description 属性文字列の 2 番目の値です (例: 2;SERIAL;…​)。

      # openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -serial
      
      # ldapsearch -D "cn=directory manager" -W -b "uid=ipara,ou=people,o=ipaca" description

   2. サブシステム証明書とそれに対応する LDAP エントリー。シリアル番号は、セミコロンで区切られた description 属性文字列の 2 番目の値です (例: 2;SERIAL;…​)。

      # certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' | grep "Serial Number"
      
      # ldapsearch -D "cn=directory manager" -W -b "uid=pkidbuser,ou=People,o=ipaca" description

      レプリカ上のシリアル番号が CA 更新サーバー上のシリアル番号と一致しない場合は、次のステップに進んでそれらを同期してください。

4. 正常な証明書をレプリカに手動でコピーします。更新サーバーから、ra-agent.pem とサブシステム証明書を障害が発生したレプリカにコピーします。

   1. RA エージェント証明書ファイルをコピーします。

      # scp /var/lib/ipa/ra-agent.pem root@failed-replica.idm.example.com:/tmp/

   2. サブシステム証明書をエクスポートします。

      # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a > /tmp/subsystem.pem

   3. サブシステム証明書をコピーします。

      # scp /tmp/subsystem.pem root@failed-replica.idm.example.com:/tmp/

5. 障害が発生したレプリカで、期限切れの RA エージェント証明書を置き換えます。

   1. 正常な証明書を次の場所にコピーします。

      # cp /tmp/ra-agent.pem /var/lib/ipa/ra-agent.pem

   2. LDAP 内の対応するエントリーを更新して、正しい証明書の Blob とシリアル番号が含まれていることを確認します。このステップでは Directory Manager のパスワードが必要です。

      1. 新しい RA エージェント証明書を 1 行の Blob に変換し、変数に格納することで、LDAP 用に準備します。

         # RA_CERT_BLOB=$(sed -rn '/^-----BEGIN CERTIFICATE-----$/{:1;n;/^-----END CERTIFICATE-----$/b2;H;b1};:2;${x;s/\s//g;p}' /tmp/ra-agent.pem)

      2. 新しい証明書からシリアル番号を抽出し、変数に格納します。

         # RA_CERT_SERIAL=$(openssl x509 -in /tmp/ra-agent.pem -noout -serial | cut -d'=' -f2)

      3. LDAP データベースを変更する前に、IdM サービスが実行されていることを確認します。

         # ipactl start -f

      4. 新しい証明書の Blob とシリアル番号を使用して、RA エージェントの LDAP エントリーを更新します。Directory Manager のパスワードを入力するよう求められます。

         # ldapmodify -D "cn=Directory Manager" -W -x <<EOF
         dn: uid=ipara,ou=people,o=ipaca
         changetype: modify
         add: userCertificate
         userCertificate:: ${RA_CERT_BLOB}
         
         replace: description
         description: 2;${RA_CERT_SERIAL};CN=Certificate Authority,O=IDM.EXAMPLE.COM;CN=IPA RA,O=IDM.EXAMPLE.COM
         EOF

         IDM.EXAMPLE.COM は、IdM レルムに置き換えるか、カスタムの証明書サブジェクトベースを使用します。

6. 障害が発生したレプリカで、期限切れのサブシステム証明書を置き換えます。

   1. 正常な証明書を NSS データベースにインポートします。これには NSS データベースパスワードが必要です。このパスワードは /etc/pki/pki-tomcat/password.conf にあります。

      1. 次のコマンドで NSS データベースパスワードファイルの場所の変数を設定し、簡単に使用できるようにします。

         # PWDFILE=/etc/pki/pki-tomcat/alias/pwdfile.txt

      2. NSS データベースから古い期限切れのサブシステム証明書を削除します。

         # certutil -D -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -f $PWDFILE

      3. /tmp/subsystem.pem ファイルから新しい正常なサブシステム証明書を NSS データベースに追加します。

         # certutil -A -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -t ",," -i /tmp/subsystem.pem -f $PWDFILE

   2. RA エージェントのステップと同様に、LDAP 内の対応するエントリーを更新します。

      # SUBSYS_CERT_BLOB=$(cat /tmp/subsystem.pem | sed -rn '/^-----BEGIN CERTIFICATE-----$/{:1;n;/^-----END CERTIFICATE-----$/b2;H;b1};:2;${x;s/\s//g;p}')
      
      # SUBSYS_CERT_SERIAL=$(openssl x509 -in /tmp/subsystem.pem -noout -serial | cut -d'=' -f2)
      
      # ldapmodify -D "cn=Directory Manager" -W -x <<EOF
      dn: uid=pkidbuser,ou=people,o=ipaca
      changetype: modify
      add: userCertificate
      userCertificate:: ${SUBSYS_CERT_BLOB}
      
      replace: description
      description: 2;${SUBSYS_CERT_SERIAL};CN=Certificate Authority,O=IDM.EXAMPLE.COM;CN=CA Subsystem,O=IDM.EXAMPLE.COM
      EOF

      IDM.EXAMPLE.COM は、IdM レルムに置き換えるか、カスタムの証明書サブジェクトベースを使用します。

7. レプリカの LDAP サービス用の一時証明書を手動で発行します。

   1. 障害が発生したレプリカで、Directory Server の NSS データベースにある既存の鍵から証明書署名要求 (CSR) を生成します。

      # DS_INSTANCE=$(grep ldap_uri /etc/ipa/default.conf | sed -n 's|.%2Frun%2F\(slapd-\)\.socket.|\1|p')*
      
      # LDAP_CERT_NICKNAME=$(grep nsSSLPersonalitySSL "/etc/dirsrv/${DS_INSTANCE}/dse.ldif" | awk '{ print $2 }')
      
      # HOSTNAME=$(hostname -f)
      
      # PWDFILE="/etc/dirsrv/${DS_INSTANCE}/pwdfile.txt"
      
      # certutil -R -d "/etc/dirsrv/${DS_INSTANCE}" -k ${LDAP_CERT_NICKNAME} -n ${LDAP_CERT_NICKNAME} -s "CN=${HOSTNAME}" -a -f "${PWDFILE}" -8 "${HOSTNAME}" -o /tmp/ldap.csr

      注記

      上記のコマンドは /tmp/ldap.csr を作成します。一部のバージョンの certutil では、ファイルにテキストがさらに追加される場合があります。ファイルに -----BEGIN NEW CERTIFICATE REQUEST----- ブロックだけが含まれており、他には何も含まれていないことを確認してください。

   2. 証明書が IdM CA によって署名されている場合:

      1. 障害が発生したレプリカで、CSR を更新サーバーにコピーします。

         # scp /tmp/ldap.csr root@renewal-master.idm.example.com:/tmp/

      2. 更新サーバーで、CSR に署名します。ldap/ プリンシパルを使用して、証明書が GSSAPI バインドに対して有効であることを確認します。

         # ipa cert-request /tmp/ldap.csr --principal="ldap/$(hostname -f)" --certificate-out=/tmp/ldap.pem

      3. 更新サーバーで、新しい証明書をレプリカにコピーします。

         # scp /tmp/ldap.pem root@failed-replica.idm.example.com:/tmp/

      4. 障害が発生したレプリカで、新しい証明書を Directory Server の NSS データベースにインポートします。

         # certutil -D -d "/etc/dirsrv/${DS_INSTANCE}" -n ${LDAP_CERT_NICKNAME} -f "${PWDFILE}"
         
         # certutil -A -d "/etc/dirsrv/${DS_INSTANCE}" -n ${LDAP_CERT_NICKNAME} -t ",," -i /tmp/ldap.pem -f "${PWDFILE}"

   3. 証明書が外部 CA によって署名されている場合:

      1. /tmp/ldap.csr ファイルを取得し、署名のために外部認証局に送信します。
      2. 新しい証明書ファイル (たとえば、new_ldap_cert.pem) を受け取ったら、それを障害が発生したレプリカの /tmp/ ディレクトリーにセキュアにコピーし、名前を ldap.pem に変更します。

      3. 障害が発生したレプリカで、新しい証明書を Directory Server の NSS データベースにインポートします。

         # certutil -D -d "/etc/dirsrv/${DS_INSTANCE}" -n ${ LDAP_CERT_NICKNAME} -f "${PWDFILE}"
         
         # certutil -A -d "/etc/dirsrv/${DS_INSTANCE}" -n ${ LDAP_CERT_NICKNAME} -t ",," -i /tmp/ldap.pem -f "${PWDFILE}"

8. レプリカの PKI Tomcat サービス用の一時証明書を手動で発行します。

   1. 障害の影響を受けたレプリカで、PKI Tomcat NSS データベースに保存されている既存の鍵を使用して CSR を生成します。

      # HOSTNAME=$(hostname -f)
      
      # PWDFILE="/etc/pki/pki-tomcat/alias/pwdfile.txt"
      
      # certutil -R -d /etc/pki/pki-tomcat/alias -k 'Server-Cert cert-pki-ca' -n 'Server-Cert cert-pki-ca' -s "CN=${HOSTNAME},O=IDM.EXAMPLE.COM" -a -f "${PWDFILE}" -o /tmp/server-cert.csr

      IDM.EXAMPLE.COM は、IdM レルムに置き換えるか、カスタムの証明書サブジェクトベースを使用します。

   2. 障害が発生したレプリカで、CSR を更新サーバーにコピーします。

      # scp /tmp/server-cert.csr root@renewal-master.idm.example.com:/tmp/

   3. 更新サーバーで、CSR に署名します。Web サーバー証明書の host/ プリンシパルを使用します。

      # ipa cert-request /tmp/server-cert.csr --principal="host/$(hostname -f)" --certificate-out=/tmp/server-cert.pem

   4. 更新サーバーで、新しい証明書をレプリカにコピーします。

      # scp /tmp/server-cert.pem root@failed-replica.idm.example.com:/tmp/

   5. 障害が発生したレプリカで、新しい証明書を PKI Tomcat NSS データベースにインポートします。

      # certutil -D -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -f "${PWDFILE}"
      
      # certutil -A -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -t ",," -i /tmp/server-cert.pem -f "${PWDFILE}"

9. サービスを再起動し、残りの証明書を更新します。

   1. 新しい証明書を使用するために、レプリカ上の IdM サービスを再起動します。

      # ipactl restart

   2. 手動による変更を適用するために、certmonger サービスを再起動します。再起動すると、残りの証明書の更新が開始されます。

      # systemctl restart certmonger

   3. getcert list | grep -E "Request ID|status|expires" を定期的に実行することで、更新プロセスを監視できます。すべての証明書が MONITORING 状態になれば、プロセスは完了です。

   4. これで、certmonger サービスが CA と通信できるようになります。数分経っても 1 つ以上の証明書が更新されない場合は、手動で更新することを検討してください。

      # getcert list
      
      # getcert resubmit -i <REQUEST_ID>