Zimbra証明書の有効期限切れを修正：自己署名証明書を安全に更新する

Zimbraサーバーは、ユーザーが「証明書の有効期限切れ」などのブラウザ警告に突然遭遇したり、メールクライアントがSSL/TLS接続を拒否したり、管理者が証明書の有効期限切れに気づいたりするまで、正常に動作しているように見えることがあります。最も迅速かつ安全な対応策は、証明書のすべてのコンポーネントをすぐに交換しないことです。まず、どのコンポーネントの有効期限が切れたかを特定し、次に必要最小限のコンポーネントのみを更新してください。

Zimbra の現在のテクニカル センターの手順では、シングル サーバーでの自己署名展開に、zmcertmgr証明書の作成と展開に使用されます。重要な点として、Zimbra は、通常の自己署名証明書の更新では新しい認証局 (CA) の作成はオプションであり、サーバー証明書の有効期限が切れるたびに CA を交換する必要はないと述べています。このガイドで使用した公式リファレンスは、2026 年 10 月 6 日に確認されました:自己署名 SSL 証明書の再生成 - シングル サーバーおよび管理コンソールと CLI 証明書ツール。

有効期限切れのZimbra証明書が実際のサービス問題を引き起こす理由

Zimbraは、Webインターフェース、プロキシ、LDAP、メールプロトコルなどのサービス全体でTLS証明書を使用します。証明書の有効期限が切れると、基盤となるZimbraプロセスが引き続き実行されていても、クライアントは接続を拒否する可能性があります。したがって、ブラウザの警告は症状の一つにすぎません。トポロジーやクライアントポリシーによっては、セキュアなIMAP/POP/SMTP接続の失敗、プロキシエラー、LDAP/TLSの問題なども発生する可能性があります。

区別すべき有効期限切れのケースは2つあります。

• サーバー証明書のみが期限切れです。これは比較的簡単なケースです。既存のZimbra CAがまだ有効な場合はそのまま使用し、新しいサーバー証明書を生成してデプロイし、サービスを再起動してください。
• Zimbra CA自体が期限切れになっています。CAを再作成してデプロイし、そのCAで署名された新しいサーバー証明書を作成してデプロイしてください。マルチサーバー環境では、ノード間でCAの一貫性が重要となるため、マルチノード環境をシングルサーバー環境のように扱わないでください。

変更を加える前に、環境に適した最新のバックアップまたはスナップショットを取得してください。証明書の再生成は通常簡単ですが、サーバーに古いカスタマイズ設定、手動でインストールされた証明書、または混在したトポロジーが存在する場合、バックアップがあれば復旧ポイントを確保できます。

ステップ1：デプロイされた証明書が実際に期限切れであることを確認する

Zimbraアカウントに切り替えて、ローカルサービスに現在デプロイされている証明書を確認します。

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

証明書の有効期限とサブジェクトを確認してください。証明書の有効期間内であれば、証明書を不必要に再生成するのではなく、ホスト名の不一致、信頼できない自己署名認証局、プロキシによって提供されている古い証明書、またはサーバー/クライアントの時刻の誤りなどを調査してください。

HTTPS でリモート クライアントが実際に受信する証明書を確認することもできます。mail.example.comをユーザーが接続するホスト名に置き換えてください。

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

このリモートチェックは、見た目は正しくてもブラウザが古い証明書を認識している場合に役立ちますviewdeployedcrt。なぜなら、ディスク上のファイルだけでなく、ネットワーク経由で提示される証明書もテストするからです。

ステップ2：サービスの状態を確認し、CAの更新も必要かどうかを判断します。

証明書を変更する前に、現在のZimbraサービスの状態を確認し、基準となる状態を把握してください。

zmcontrol status

サーバー証明書のみが期限切れで、Zimbra CA がまだ有効な場合は、CA の再作成をスキップして、次のセクションのサーバー証明書コマンドに直接進んでください。これにより、信頼チェーンへの変更を最小限に抑えることができます。Zimbra のシングルサーバーに関するドキュメントには、新しい CA の作成はオプションであり、自己署名証明書を更新するたびに必須ではないことが明記されています。

CAの有効期限が切れている場合、またはCAを交換する正当な理由がある場合は、新しいCAを作成してください。

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

ステップ3：新しい自己署名サーバー証明書を生成してデプロイする

単一サーバーの証明書更新をシンプルに行う場合、Zimbraでは以下の手順を説明しています。この例では、365日間有効な証明書を作成します。

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

クライアントが複数の DNS 名で接続する場合、デフォルトのホスト名で十分だと想定するのではなく、必要なサブジェクト代替名を使用して証明書を生成してください。Zimbra の証明書ツールは、次の形式をサポートしています-subjectAltNames。例:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

この Zimbra サービスに正しく解決され、かつユーザーや統合システムが実際に使用する名前を使用してください。証明書の有効期限が切れていなくても、要求されたホスト名がサブジェクト/SAN値でカバーされていない場合は、検証に失敗する可能性があります。

この自己署名手順を使用して、誤って商用証明書や公的に信頼されている証明書を上書きしないでください。サーバーが商用証明書を使用する必要がある場合は、ここで作業を中止し、Zimbraの商用証明書展開手順に従ってください。

ステップ4：デプロイメントを確認し、Zimbraを再起動して、クライアント側からテストします。

Zimbraが新しい証明書をデプロイしたことを確認してください。

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

次に、Zimbraを再起動して、サービスが新しい証明書を読み込むようにします。

zmcontrol restart

再起動が完了したら、以下を実行してください。

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

求める結果はシンプルです。期待通りのサービスが稼働し、デプロイされた証明書の有効期限が将来の日付になっていることです。最後に、ユーザーが実際にアクセスするホスト名に対して、リモートのOpenSSLテストを再度実行してください。これにより、再起動後にネットワーク上で何が提供されているかが確認できます。

ブラウザに古い証明書または期限切れの証明書が表示されている場合

すぐに別の証明書を再生成しないでください。残りのレイヤーを順番に処理してください。

• DNSとホスト名を確認してください。新しい証明書でカバーされているホスト名と同じホスト名でテストを行い、目的のZimbraサーバーにアクセスできることを確認してください。
• プロキシのパスを確認してください。Zimbraの証明書トラブルシューティングに関するドキュメントには、プロキシが場合によっては古い証明書を提示し続けることがあると記載されています。ローカルの証明書ファイルだけでなく、リモートで提示された証明書も確認してください。Zimbraの証明書エラーを参照してください。
• クライアントの信頼性を確認してください。更新された自己署名証明書は、有効期限が切れていなくても、ブラウザやメールクライアントから信頼されない場合があります。有効期限と信頼性は別個の問題です。
• システム時刻を確認してください。サーバーまたはクライアントの時計が著しく不正確だと、本来有効な証明書が無効または期限切れと表示されることがあります。
• CAを確認してください。リーフ証明書が新しいにもかかわらず、発行元のZimbra CAの有効期限が切れている場合は、CAを交換し、新しいCAからサーバー証明書を再生成してください。

マルチサーバーZimbraには、異なるレベルの管理が必要です。

マルチノードインストールの場合、各ホストでシングルサーバーコマンドを無闇に繰り返すのではなく、マルチサーバー手順を使用してください。Zimbra のドキュメントには、CA の作成/デプロイ、および自己署名証明書をノード全体にデプロイする方法が記載されていますdeploycrt self -allserver。また、viewdeployedcrtローカルサーバーのみが報告されるという警告も記載されています。公式リファレンスは「自己署名 SSL 証明書の再生成 - マルチサーバー」です。

LDAPマスターとレプリカ間のCAの不一致は、TLSおよびレプリケーションの問題を引き起こす可能性があります。マルチサーバー構成で運用している場合は、影響を受けるすべてのノードでCAチェーンを確認し、ドキュメントに記載されている展開順序に従ってください。

自己チェック：修正が完了したかどうかを確認する方法

インシデントをクローズする前に、以下のすべてを確認してください。

• zmcontrol status想定どおりZimbraサービスが実行されていることを示します。
• zmcertmgr viewdeployedcrt有効期限が未来の証明書を示しています。
• リモートopenssl s_clientチェックでは、ユーザーが実際に使用するパブリックホスト名と内部ホスト名の両方について、同じ新しい証明書の日付が返されます。
• 証明書のサブジェクトまたはSANは、そのホスト名をカバーしています。
• ウェブメールや、お使いの環境で使用されているメールプロトコルは、TLS接続を確立できます。
• Zimbra CAを意図的に置き換えた場合、古いCAをピン留めまたは信頼しているクライアントまたは内部システムは、必要に応じて更新されています。

単一サーバーの証明書の有効期限切れという通常のケースでは、通常、最も影響の少ない方法は、有効なZimbra CAを保持したまま、新しい自己署名サーバー証明書を作成し、それをデプロイしてサービスを再起動し、サーバー外部から証明書を検証することです。CAの交換は、有効期限が切れた場合、またはCAをローテーションする明確な理由がある場合にのみ行ってください。この方法により、不要な信頼チェーンの変更を回避しながら、差し迫ったサービス停止を解消できます。