Zimbraサーバーに商用SSL証明書をインストールする方法

Zimbra 上の商用 SSL 証明書は、認証局が証明書が正しく発行されたと言っている場合でも、いくつかの厄介な問題が発生する可能性があります。最も一般的な問題は、証明書自体にあるのではなく、秘密鍵が返された証明書と一致しない、中間認証局が欠落している、ホスト名が証明書のサブジェクト代替名 (SAN) に含まれていない、または管理者が証明書チェーンを検証する前にファイルをデプロイしている、といったケースです。

この作業を安全に処理するには、単一の「証明書のインストール」コマンドではなく、一連のチェックとして扱うのが最も良い方法です。Zimbra の公式ドキュメントに記載されている証明書ツールをzmcertmgr使用すると、証明書署名要求 (CSR) の作成、秘密鍵と CA チェーンの検証、証明書の Zimbra サービスへのデプロイ、および現在アクティブな証明書の表示が可能です。これらのコマンドについては、Zimbra 公式テクニカル センターの「管理コンソールおよび CLI 証明書ツール ガイド」に記載されています。

Zimbra SSLのインストールが成功した場合、どのような状態になるべきか

変更を加える前に、まず望む結果を明確に定義してください。適切なデプロイメントは、以下のすべての条件を満たす必要があります。

• 証明書の SAN リストには、クライアントが実際に使用するすべてのパブリック ホスト名が含まれますmail.example.com。
• 発行された証明書は、商用証明書に保存されている秘密鍵と一致します。
• Zimbraは、サーバー証明書から中間CA証明書を経てルートCAに至るまでの証明書チェーン全体を検証できます。
• zmcertmgr deploycrt commキーの不一致やチェーン検証エラーなく完了します。
• Zimbraサービスは正常に再起動しました。
• zmcertmgr viewdeployedcrt期待される証明書が表示されます。
• 公開ホスト名に接続するブラウザまたはTLSクライアントは、新しい証明書を認識し、信頼に関する警告は表示されません。

これらのチェックのいずれかが失敗した場合は、続行する前に該当するレイヤーを修正してください。同じファイルを繰り返し再デプロイしても、キー、SAN、またはチェーンの問題が解決することはほとんどありません。

始める前に：適切な証明書ワークフローを選択してください

Zimbraの最新のテクニカルセンターページには、Zimbra 8.7以降では、zmcertmgrがユーザーとして実行されると記載されていますzimbra。また、商用秘密鍵commercial.keyはに名前を付ける必要が/opt/zimbra/ssl/zimbra/commercialあり、サーバー証明書とCAチェーンファイルはデプロイ前に一時ディレクトリにステージングする必要があることも記載されています。

ステップ1：現在の証明書資料をバックアップする

既存の SSL ディレクトリを削除することから始めないでください。まず、新しいデプロイメントが失敗した場合に復元できるバックアップを作成してください。root 権限で実行する場合の保守的な例は次のとおりです。

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

また、変更する前に、現在デプロイされている証明書を記録しておきましょう。

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

これにより、変更後の比較基準が得られます。環境に複数の Zimbra ノードがある場合は、証明書の状態が同一であると想定するのではなく、関連する各サーバーで現在の証明書の状態を取得してください。

ステップ2：実際に必要なホスト名を含むCSRを生成する

新しい商用証明書の場合は、本番環境のホスト名と追加のSANを含むCSRを作成します。Zimbraのドキュメントには、以下の構文が記載されています。

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

ユーザーが などの別の名前でも接続する場合はwebmail.example.com、証明書を要求する際に SAN リストにその名前を含めてください。最新の TLS クライアントはホスト名を SAN と照合して検証するため、共通名だけで正しく見える証明書でも、ホスト名が欠落している場合はブラウザに警告が表示されることがあります。

認証局に送信する前に、CSRの内容を確認してください。

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

チェックポイント：要求されたDNS名が間違っている場合は、ここで停止します。証明書を先に発行してからSANが欠落していることに気づいた場合、通常は認証局（CA）に再発行を依頼する必要があります。

ステップ3：サーバー証明書と完全なCAチェーンを収集する

検証後、商用認証局（CA）は通常、サーバー証明書と1つ以上の中間証明書を返します。Zimbraの公式シングルノード商用証明書手順では、サーバー証明書はPEM形式で提供されることが想定されており、管理者は中間CA証明書とルートCA証明書を組み合わせてチェーンファイルを作成する必要があります。

典型的なステージングレイアウトは以下のとおりです。

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

次に、Zimbraが文書化した順序でチェーンを構築します。

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

ご使用の証明書製品に付属するファイルは、認証局から提供されたものを使用してください。認証局のブランド名が似ているという理由だけで、無関係なチュートリアルから中間証明書をコピーしないでください。認証局の階層は時間の経過とともに変化するため、間違った中間証明書を使用すると、エラーが発生することがよくありますunable to get local issuer certificate。

ステップ4：デプロイ前に秘密鍵、サーバー証明書、および証明書チェーンを確認する

これは最も重要な安全対策です。最新のZimbraリリースで、Zimbraユーザーとして、ドキュメントに記載されている検証コマンドを実行してください。

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

検証が成功すると、証明書と秘密鍵が一致し、証明書が有効であることが報告されます。Zimbraの証明書ツールに関するドキュメントでは、verifycrt鍵チェックと証明書チェーンチェックを組み合わせた検証方法が説明されています。

検証が失敗した場合は、エラーに基づいて修正方法を選択してください。

• 証明書と秘密鍵が一致しません: CA証明書は、現在の証明書に関連付けられているCSRから発行されていませんcommercial.key。正しい鍵を復元するか、新しいCSRから証明書を再発行してください。
• 証明書チェーンを検証できません。中間証明書/ルート証明書バンドルが不完全、順序が間違っている、有効期限が切れている、またはこのサーバー証明書のチェーンではありません。発行元の認証局から正しいチェーンを入手してください。
• 証明書の有効期限が切れています。この証明書は展開しないでください。最新の証明書を要求するとともに、証明書チェーン内の中間証明書またはルート証明書の有効期限が切れていないか確認してください。Zimbra は、有効期限切れのルート CA のトラブルシューティング ガイダンスでこの障害モードについて説明しています。
• ホスト名が欠落しています。この検証は、ブラウザが行うホスト名チェックとは異なる可能性があります。発行されたSANを調べ、公開名が存在しない場合は再発行してください。

ステップ5：商用証明書をデプロイする

検証が成功した後のみ、デプロイしてください。

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Zimbraの文書化された導入プロセスでは、商用証明書をSSL領域にコピーし、CAチェーンを追加し、証明書構成を更新し、サーバーに応じてMTA、LDAP、プロキシ、メールボックスコンポーネントなどのサービス用の証明書マテリアルをインストールします。

ご使用のZimbraリリースに関するドキュメントで特に指示されている場合を除き、任意のJavaキーストアやサービス証明書ファイルを手動で上書きしないでください。これは、zmcertmgrサービス固有の証明書資料の一貫性を維持するためです。

ステップ6：Zimbraサービスを再起動する

デプロイ後、Zimbraを再起動してください。

su - zimbra
zmcontrol restart

次に、サービスの状態を確認します。

zmcontrol status

サービスが に応答しない場合はRunning、証明書の変更が完了したと宣言する前に調査してください。証明書の問題は、特にマルチノード環境では、LDAP、プロキシ、メールボックス、またはその他のTLSに依存する通信に影響を与える可能性があります。

ステップ7：Zimbra側とクライアント側の両方から結果を確認する

まず、Zimbra独自の証明書ビューを使用してください。

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

デプロイ済みのサービス証明書の有効期限が近づいているかどうかを確認することもできます。

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

最後に、ユーザーが実際にアクセスする公開ホスト名を正確にテストします。別のマシンからOpenSSLでチェックする便利な方法は次のとおりです。

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

期待されるリーフ証明書、正しいホスト名、完全な証明書チェーン、および検証結果が正常であることを確認してください。次に、同じHTTPS URLを最新のブラウザで開きます。ブラウザでのテストが重要なのは、ディスク上の証明書ファイルだけでなく、ユーザーが実際にアクセスするホスト名を検証できるためです。

標準手順では不十分な場合

以下のいずれかの条件に該当する場合は、単一ノードの手順を強制するのではなく、アプローチを変更してください。

• マルチノードZimbra：証明書の展開には、異なるホスト上のプロキシ、メールボックス、LDAP、MTAといった役割をカバーする必要がある場合があります。Zimbraの証明書ツールはマルチサーバーオプションをサポートしていますが、使用する前にトポロジーに応じた手順を確認してください。
• リバースプロキシまたは外部ロードバランサーがTLSを終端する場合、そのデバイスにも公開証明書をインストールする必要がある場合があります。TLSが上流で終端されている場合、正しいZimbra証明書だけではクライアントに表示される内容は変わりません。
• 既存のキーをインポートしています。検証を行う前に、Zimbraが商用秘密鍵を想定する場所にキーが配置されていること、および権限がバージョンの要件と一致していることを確認してください。
• 認証局（CA）は中間証明書のみを提供します。ルート証明書を自作するのではなく、CAの現在の証明書チェーンの指示に従ってください。Zimbraは検証可能な証明書チェーンを必要とします。必要なファイルは発行者によって異なります。
• 証明書はホスト名は同じですが、鍵が異なって更新されました。検証を行う前に、対応する秘密鍵を更新してください。以前の証明書では、commercial.key新しい鍵ペアに対して発行された証明書を検証できません。

最終自己点検

インストールは、以下のすべてが満たされた場合にのみ完了します。verifycrtテストがパスし、deploycrt成功し、Zimbra サービスが実行状態に戻り、viewdeployedcrt新しい証明書が表示され、実際のホスト名への外部 TLS 接続が信頼またはホスト名の警告なしに同じ有効な証明書を受信すること。

コマンド構文やバージョン固有の動作については、Zimbraの公式証明書ツールドキュメントを主要な参考資料として参照してください。ここに示す例ではmail.example.com、プレースホルダーを使用しています。名前、証明書ファイル、組織の詳細は、ご使用の環境に発行された値に置き換えてください。