WebサーバにおいてHTTPS通信を実現するために導入されるSSL証明書は、Let’s EncryptのCertbotを使えば無償で取得・更新が可能です。
しかし、自動更新に失敗し、結果的に証明書が期限切れになってしまうという問題が現場でたびたび発生します。
本記事では、CertbotでのSSL証明書の更新において、設定ファイルからApacheの停止と起動を行う命令（pre_hookとpost_hook）が消えていたことによって更新処理に失敗したという事例をもとに、同じ問題が再発しないための対処方法を解説します。
前回の記事より深堀していますので、併せて読んでみてください。
80番ポートが競合している問題
Certbotは証明書の更新時にHTTP通信（80番ポート）を利用してドメインの所有確認を行います。
その際、すでに同じポートをApacheなどのWebサーバーが使用していると、ポートの競合により失敗します。
この問題を避けるため、更新前にApacheを停止し、更新後に再度起動する処理を仕込むのが一般的です。
そのために使われるのがpre_hookとpost_hookという設定です。
設定ファイルに書いたはずのpre_hookとpost_hookが消えた？
Certbotでは、個別のドメインに対応する設定ファイル（例：/etc/letsencrypt/renewal/example.com.conf）に以下のような形で処理を記述します。
|
1 2 |
pre_hook = systemctl stop apache2 post_hook = systemctl start apache2 |
この設定をしていたにもかかわらず、ある日突然これらの行が消えていた、という現象が報告されています。
設定ファイルの意図しない上書きや削除の原因には、以下の2つが特に関係しています。
Certbotによる設定ファイルの上書き
Certbotは更新時に設定ファイルを内部で書き換える仕様を持っています。
とくに、コマンド実行時に引数として--pre-hookや--post-hookを指定すると、その内容が個別設定ファイルに反映される場合があり、以前に手動で記載した内容が消されてしまうことがあります。
たとえば、以下のような形で更新を行った場合、
|
1 |
certbot renew --pre-hook "echo pre" --post-hook "echo post" |
この引数の値が/etc/letsencrypt/renewal/example.com.confに記録され、以前のsystemctlコマンドが失われる可能性があります。
また、複数の証明書を同時に管理している環境では、他の証明書に適用された更新処理が、同じように別の設定ファイルを間接的に更新してしまうこともあります。
Certbotの仕様変更や更新による設定の消失
Certbotは定期的に機能追加や仕様変更が行われており、動作仕様が変更されることで以前の設定が無効化されることがあります。
とくに、OSの自動更新機能を有効にしている環境では、Certbotのバージョンが意図せず上がり、その際に設定ファイルのフォーマットが変更されることがあります。
その結果、旧形式の設定内容（とくにフック関連の記述）が新しい仕様では無視される、または削除される可能性があります。
有効な対策方法
同様の事象を未然に防ぐためには、以下の方法を組み合わせて導入することをおすすめします。
共通設定ファイルにフック処理を記述する
ドメイン個別の設定ファイルではなく、Certbot全体の設定を司る/etc/letsencrypt/cli.iniに以下のように記述します。
|
1 2 |
pre_hook = systemctl stop apache2 post_hook = systemctl start apache2 |
これにより、どの証明書更新時でもApacheの停止・再起動処理が確実に実行されるようになります。
しかも、個別ファイルが上書きされても影響を受けません。
更新処理をスクリプトとして統一管理する
Certbotの更新処理を手動で制御したい場合は、次のようなシェルスクリプトを作成し、cronやtimerで定期実行します。
|
1 2 3 4 |
#!/bin/bash systemctl stop apache2 certbot renew systemctl start apache2 |
この方法であれば、Certbot側で設定ファイルが書き換えられても問題なくWebサーバとの競合を回避できます。
設定ファイルのバックアップを定期的に取得する
設定ファイルが変更されたことに気づかない場合を想定して、以下のように定期バックアップを取得しておくと安心です。
|
1 |
tar -czf /backup/letsencrypt-backup-$(date +%Y%m%d).tar.gz /etc/letsencrypt |
こうすることで、万が一内容が書き換わっても、以前の状態をすぐに復元できます。
更新の動作確認を習慣にする
以下のコマンドで、証明書の更新処理が正常に動作するか事前検証が可能です。
|
1 |
certbot renew --dry-run |
この確認を定期的に行うことで、フックの動作確認や競合エラーの事前検出ができます。
まとめ
SSL証明書の更新失敗は、Webサービスの信頼性に直結する問題です。特にCertbotによる自動更新では、内部動作や設定ファイルの扱いにより、pre_hookやpost_hookの記述が予期せず消失するリスクが存在します。
このような問題を防ぐには、共通設定ファイルの活用、スクリプトによる更新制御、定期バックアップ、そして更新処理の事前検証といった対策が効果的です。
サーバー運用において、こうした細かい設定の確認と見直しは、システムの安定性を守るために欠かせません。
日々の保守作業の一環として、これらの対策をぜひ取り入れてください。
コメント