Certbot は、Let's Encrypt などの ACME 対応認証局から証明書を取得・更新するための代表的なクライアントです。
certbot renew による自動更新を前提に設計されています。
証明書の有効期間が短いから自動化が前提になる
Let's Encrypt の証明書は有効期間が意図的に短く、しかもさらに短縮される方向にあります。手作業で更新する運用は現実的ではなく、自動更新が動いていることが前提の仕組みだと理解してください。
認証方式の選び方
証明書を出す前に「そのドメインが本当にあなたのものか」を確認します。ここで方式が分かれます。
| 方式 | 確認のしかた | 向いている場面 |
|---|---|---|
| HTTP-01 | 80番ポートに置いたファイルを取りに来る | 一般的なWebサーバー |
| DNS-01 | DNSにTXTレコードを立てる | ワイルドカード証明書は必須。80番を開けられない環境 |
*.example.com のようなワイルドカードが必要なら DNS-01 以外の選択肢はありません。DNS事業者のAPIに対応したプラグインが必要になるので、証明書の設計より先にDNSの契約先を確認してください。
更新は通るのにエラーが出続ける典型
いちばん多い事故がこれです。証明書の更新自体は成功しているのに、Webサーバーが古い証明書を読み込んだまま動き続けるというパターンです。
nginx や Apache は起動時に証明書を読み込むため、更新後にリロードしなければ新しい証明書は使われません。--deploy-hook に systemctl reload nginx などを指定して、更新が成功したときだけリロードが走るようにします。
動いているかを確認する方法
自動更新はしばらく黙って失敗します。気づくのは期限切れ当日というのが最悪のパターンです。
certbot renew --dry-run… 実際には更新せず、手順が通るか試すsystemctl list-timers | grep certbot… 定期実行が仕込まれているか確認- 外部から有効期限を監視する仕組みを別に持つ
実務で見るポイント
- 更新は期限のかなり前から試行される。1回失敗しても即エラーではないが、放置はしない
- 短期間に何度も取得を試すと発行側の制限に当たる。試行は
--dry-runで - 証明書ファイルの実体はシンボリックリンク。バックアップ時はリンク先ごと取る