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


Identity Management (IdM) 証明書の有効期限が切れると、Web UI、LDAP、証明書の発行などのコアサービスで障害が発生します。システムがセキュアな接続を確立できないため、ipa-certupdateipa-cacert-manage などのコマンドは機能しません。以下のセクションでは、いくつかの重大な障害シナリオに対処するための手順を説明します。

重要

変更を行う前に、IdM サーバーの完全なバックアップを作成してください。少なくとも、各サーバー上の重要なデータのファイルレベルのバックアップを作成してください。

# tar czvf /root/pki-backup_$(hostname -f)_$(date +%F).tar.gz /etc/dirsrv/slapd-* /etc/pki/pki-tomcat/ /var/lib/ipa/ /var/kerberos/krb5kdc/

信頼できるバックアップがない状態で続行しないでください。

警告

ipa-cert-fix コマンドは細心の注意を払って使用してください。ipa-cert-fix は、強力ですがシステムへの影響が大きいツールであり、特定の障害シナリオ (更新サーバー上のサービス証明書の期限切れ) のために設計されています。

  • CA 証明書自体の有効期限が切れている場合は、ipa-cert-fix を実行しないでください。
  • 更新サーバーが回復不能な状態にある場合を除き、レプリカサーバーで ipa-cert-fix を実行しないでください。このような状況に陥った場合は、サポートチケットを作成してください。
  • ipa-cert-fix を一般的なトラブルシューティングツールとして実行しないでください。

このツールを誤用すると状況が悪化する可能性があります。

22.1. レプリカ上の期限切れサービス証明書の回復

この障害シナリオでは、更新サーバーは正常ですが、1 つ以上のレプリカが証明書の更新に失敗し、現在オフラインになっています。目標は、レプリカを復元するために、サーバーから必要な証明書を手動で同期または再発行することです。

この手順では、RA Agent 証明書、Subsystem 証明書、Directory Server (LDAP) 証明書、および PKI Tomcat (Web Server) 証明書という 4 つの重要な証明書を説明します。

注記

どのサーバーが更新サーバーであるかわからない場合は、任意の IdM サーバーで次のコマンドを実行してください。このコマンドにより、CA 更新サーバーの識別名 (DN) が出力されます。

# ldapsearch -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com ipaConfigString=caRenewalMaster dn
Copy to Clipboard Toggle word wrap

Kerberos が利用できない場合は、Directory Manager のパスワードを使用して次のコマンドを使用してください。

# ldapsearch -x -D 'cn=Directory Manager' -W -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com ipaConfigString=caRenewalMaster dn
Copy to Clipboard Toggle word wrap

手順

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

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

    # ipactl start -f
    Copy to Clipboard Toggle word wrap

    -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
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

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

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

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

      # scp /var/lib/ipa/ra-agent.pem root@failed-replica.idm.example.com:/tmp/
      Copy to Clipboard Toggle word wrap
    2. サブシステム証明書をエクスポートします。

      # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a > /tmp/subsystem.pem
      Copy to Clipboard Toggle word wrap
    3. サブシステム証明書をコピーします。

      # scp /tmp/subsystem.pem root@failed-replica.idm.example.com:/tmp/
      Copy to Clipboard Toggle word wrap
  5. 障害が発生したレプリカで、期限切れの RA エージェント証明書を置き換えます。

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

      # cp /tmp/ra-agent.pem /var/lib/ipa/ra-agent.pem
      Copy to Clipboard Toggle word wrap
    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)
        Copy to Clipboard Toggle word wrap
      2. 新しい証明書からシリアル番号を抽出し、変数に格納します。

        # RA_CERT_SERIAL=$(openssl x509 -in /tmp/ra-agent.pem -noout -serial | cut -d'=' -f2)
        Copy to Clipboard Toggle word wrap
      3. LDAP データベースを変更する前に、IdM サービスが実行されていることを確認します。

        # ipactl start -f
        Copy to Clipboard Toggle word wrap
      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
        Copy to Clipboard Toggle word wrap

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

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

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

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

        # PWDFILE=/etc/pki/pki-tomcat/alias/pwdfile.txt
        Copy to Clipboard Toggle word wrap
      2. NSS データベースから古い期限切れのサブシステム証明書を削除します。

        # certutil -D -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -f $PWDFILE
        Copy to Clipboard Toggle word wrap
      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
        Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

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

        # scp /tmp/ldap.csr root@renewal-master.idm.example.com:/tmp/
        Copy to Clipboard Toggle word wrap
      2. 更新サーバーで、CSR に署名します。ldap/ プリンシパルを使用して、証明書が GSSAPI バインドに対して有効であることを確認します。

        # ipa cert-request /tmp/ldap.csr --principal="ldap/$(hostname -f)" --certificate-out=/tmp/ldap.pem
        Copy to Clipboard Toggle word wrap
      3. 更新サーバーで、新しい証明書をレプリカにコピーします。

        # scp /tmp/ldap.pem root@failed-replica.idm.example.com:/tmp/
        Copy to Clipboard Toggle word wrap
      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}"
        Copy to Clipboard Toggle word wrap
    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}"
        Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap

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

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

      # scp /tmp/server-cert.csr root@renewal-master.idm.example.com:/tmp/
      Copy to Clipboard Toggle word wrap
    3. 更新サーバーで、CSR に署名します。Web サーバー証明書の host/ プリンシパルを使用します。

      # ipa cert-request /tmp/server-cert.csr --principal="host/$(hostname -f)" --certificate-out=/tmp/server-cert.pem
      Copy to Clipboard Toggle word wrap
    4. 更新サーバーで、新しい証明書をレプリカにコピーします。

      # scp /tmp/server-cert.pem root@failed-replica.idm.example.com:/tmp/
      Copy to Clipboard Toggle word wrap
    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}"
      Copy to Clipboard Toggle word wrap
  9. サービスを再起動し、残りの証明書を更新します。

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

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

      # systemctl restart certmonger
      Copy to Clipboard Toggle word wrap
    3. getcert list | grep -E "Request ID|status|expires" を定期的に実行することで、更新プロセスを監視できます。すべての証明書が MONITORING 状態になれば、プロセスは完了です。
    4. これで、certmonger サービスが CA と通信できるようになります。数分経っても 1 つ以上の証明書が更新されない場合は、手動で更新することを検討してください。

      # getcert list
      
      # getcert resubmit -i <REQUEST_ID>
      Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat