SSL証明書の自動更新とは、証明書の有効期限が近づいた際に、ソフトウェアが認証局との手続きを行って新しい証明書を取得し、必要に応じてWebサーバーへ反映する仕組みです。その手続きを自動化するために利用される標準プロトコルが、ACME（Automatic Certificate Management Environment）です。
例えばLet’s EncryptとACMEクライアントのCertbotを使用すると、対象ドメインを管理していることの確認、証明書の申請・取得、定期的な更新処理を自動化できます。ただし、Certbotをインストールするだけですべての環境で自動更新が完成するわけではありません。定期実行の設定、ドメイン認証に必要な経路、更新後に証明書を読み込む処理、公開サイトでの最終確認が揃っていることが重要です。
この記事では、ACMEの仕組み、HTTP-01とDNS-01の違い、Certbotを使う場合の導入準備、更新が定期実行されるかの調査、certbot renew --dry-runによる試験、更新後の動作確認までを整理します。すでに期限切れが発生している場合の詳しい復旧はSSL証明書が期限切れになったときの対処記事、外部からの継続監視はSSL証明書の期限監視記事で扱います。
SSL証明書の自動更新とは？仕組みを一言で説明
証明書の自動更新は、担当者が期限のたびに手作業で証明書を申請しなくても、新しい証明書を取得できるようにする運用です。しかし、その作業には「証明書の発行」「サーバーへの適用」「外部からの確認」という異なる段階があるため、順序を分けて理解する必要があります。
新しい証明書を自動的に取得する仕組み
通常、公開Webサイトのサーバー証明書には有効期限があります。期限が過ぎるとブラウザの安全な接続に関する警告につながることがあります。自動更新では、期限に余裕があるうちにACMEクライアントが認証局へ更新に必要な申請を行い、ドメインの管理権限を確認する手続きなどを経て、新しい証明書を取得します。
厳密には、既存の証明書の有効期限を書き換えるのではなく、再び発行手続きを行って新しい証明書を受け取ります。Let’s Encryptの公式解説でも、証明書の更新は、ドメイン認証と新しい証明書の申請を繰り返す仕組みとして説明されています。
「発行」「適用」「確認」を分けると理解しやすい
新しい証明書を取得できたとしても、Webサーバーやロードバランサーが古い証明書を使い続ける場合があります。そのため自動更新を運用するときは、①証明書の発行・更新、②正しい保存先・設定への反映、③利用者がアクセスする公開URLでの検証、の三つに分けます。
Certbotには証明書の取得だけを行う方法と、Nginx・Apacheなどの設定を扱えるプラグインがあります。利用しているサーバー構成によって、自動的に行える範囲が違います。「証明書が新しい」と「HTTPSの公開環境も新しい証明書へ切り替わった」は別の事実です。
自動更新と期限監視は別の役割
自動更新は新しい証明書を取得・適用するための処理です。一方、期限監視は現在の公開環境が提示している証明書の終了日時を継続して調べ、期限が近い場合に管理者へ知らせる仕組みです。更新処理自体に問題がないか確認するためにも、更新の仕組みと外部からの期限確認は分けて考えましょう。
自動更新を導入した場合でも、定期実行が止まる、認証に失敗する、証明書を取得できても反映されない、といった問題は残り得ます。自動化によって管理作業を減らしながら、確認できる仕組みを用意することが大切です。
ACMEとは？自動発行・自動更新を支える標準プロトコル
ACMEは、証明書を必要とするシステムと認証局（CA）が、ネットワーク経由で証明書の発行や更新に関する手続きを行うためのプロトコルです。IETFのRFC 8555で標準化されています。
ACMEクライアントと認証局がやり取りする
ACMEの基本的な登場人物は、証明書の発行を要求するACMEクライアント、申請を受け付ける認証局、対象ドメインの管理権限を示すWebサーバーまたはDNSです。ACMEクライアントにはCertbotなどがあり、認証局の例としてLet’s Encryptがあります。
ACMEは、証明書を自動的に発行できるようにする通信手続きの標準です。すべてのサーバーにCertbotを使う義務があるわけではありません。別のACMEクライアントを使う構成や、ホスティングサービスが内部的に証明書を管理する構成もあります。
ACMEによる発行・更新の基本フロー
一般的な流れは、①ACMEクライアントが認証局へ証明書を要求、②認証局がドメインの管理を確かめる方法を提示、③クライアントが必要なHTTPリソースやDNS情報を用意、④認証局が内容を検証、⑤新しい証明書を発行、⑥クライアントが取得してサーバーへ適用、というものです。
認証を受ける方法は環境に応じて異なります。いずれの場合も、認証局は「申請者が対象ドメインを管理する権限を持つか」を確認します。ACMEはブラウザからWebサイトを閲覧している間に動く仕組みではなく、証明書を管理する側のソフトウェアと認証局との間で使われる仕組みです。
新規発行も更新も基本的には同じ考え方
既存の証明書を更新するときも、発行が許可されるかの確認と新しい証明書の取得を行います。利用環境や認証局、クライアントの機能によって手続きの最適化はあり得ますが、以前の証明書へ日付だけを上書きするものではありません。
RFC 8555では、証明書の申請、識別子の認可、発行、失効などの仕組みが定義されています。この仕組みによって、発行のたびに管理者が同じ画面操作を繰り返す手間を減らせます。ただし、自動化を行うプログラムが正しく動くかの運用確認は別に必要です。
HTTP-01・DNS-01の違いと選び方
ACMEでは、対象ドメインを管理していることを認証局へ示すために「チャレンジ」と呼ばれる確認を行います。Let’s Encryptが公式に説明する代表的な方法がHTTP-01とDNS-01です。何が必要かを理解すると、自動更新の導入で失敗しやすい構成を事前に見直せます。
| 比較項目 | HTTP-01 | DNS-01 |
|---|---|---|
| 確認の対象 | Webサーバーで公開する指定ファイル | DNSのTXTレコード |
| 主な条件 | 対象ドメインの80番ポートへ到達できる | 対象ドメインのDNSに必要なTXT値を設定できる |
| 自動化の方法 | Webサーバープラグインやwebrootなど | DNS APIに対応したプラグインなど |
| ワイルドカード証明書 | Let’s Encryptでは利用不可 | 利用可能 |
| 注意点 | リダイレクト・複数サーバー・80番ポート | DNS伝播・API権限・認証情報の保護 |
HTTP-01はWebサーバーの指定URLで認証する
HTTP-01では、ACMEクライアントが対象ドメインの特定のパスへ検証用の情報を配置し、認証局がHTTP経由でアクセスして確認します。Let’s Encryptでは通常、/.well-known/acme-challenge/ 配下を使い、検証のアクセスには80番ポートを利用します。
この方式では、Webサーバーが認証局からの確認要求を正しく処理できる必要があります。ロードバランサーや複数のWebサーバーがある場合、どの接続先でも認証用の情報へ到達できるか確認が必要です。HTTP-01は、Let’s Encryptにおけるワイルドカード証明書の発行には使用できません。
DNS-01はTXTレコードでドメイン管理権限を示す
DNS-01では、_acme-challenge.example.com のような名前に指定されたTXTレコードを設定し、認証局から参照できるようにします。Webサーバーへ80番ポートで接続できない構成でも使える場合があり、Let’s Encryptのワイルドカード証明書にも利用できます。
ただし、DNS-01で「自動更新」まで実現するには、必要なTXTレコードを自動的に作成・削除できる構成が重要です。毎回、人がDNS管理画面でTXT値を手入力する方式では、自動更新の目的を十分に達成できません。DNS事業者のAPIや対応プラグインの有無を確認しましょう。
DNS APIの認証情報は最小権限にする
DNS-01を自動化する際には、DNSのAPIトークンなどを利用する場合があります。DNS全体を変更できる強い権限の認証情報をWebサーバーへ無制限に保存すると、サーバーへの侵入が発生した場合の被害を大きくする恐れがあります。
Let’s Encryptの公式資料も、DNSのAPI認証情報は権限を絞ることや、必要に応じて認証を別の環境で行う方法に触れています。対応可能なDNS事業者であれば、対象ゾーンやレコード操作に必要な範囲だけの権限を設定しましょう。
SSL証明書を自動更新する前に確認すること
自動更新の導入方法はサーバーや管理サービスによって異なります。最初に「誰が証明書を発行・更新しているか」と「HTTPS接続をどの機器が受け付けているか」を確認すると、不要なソフトウェア導入や設定の重複を避けやすくなります。
現在の証明書の管理方式を把握する
レンタルサーバーの管理画面で「無料SSL」「自動SSL」などを利用している場合、そのサービスが更新まで管理している可能性があります。CloudflareやクラウドロードバランサーでHTTPSを終端している場合、証明書の更新主体がWebサーバー本体とは異なることがあります。
Certbotを導入する前に、既存の証明書管理者、発行元、対象ホスト名、更新担当者を調べましょう。すでに提供事業者が自動更新している構成へ別のCertbotを追加すると、どの証明書を使うべきか分かりにくくなる恐れがあります。
対象ドメインとHTTPSの終端場所を確認する
example.com と www.example.com、app.example.com は異なるホスト名です。どの名前が証明書に含まれるか確認します。また、CDNやロードバランサーを利用している場合、ブラウザとCDNの間、CDNとオリジンサーバーの間で異なる証明書が使われている場合があります。
自動更新を行う場所と、利用者へ証明書を提示する場所が違う場合は、発行後の配布・反映が必要です。自動化の設計は、実際の通信経路と一致している必要があります。
ドメイン認証に必要なアクセス条件を確認する
HTTP-01を利用するなら80番ポートでの検証アクセス、DNS-01を利用するならDNSの変更権限とTXTレコードの公開が確認事項になります。リバースプロキシ、WAF、CDNのルール、DNSの伝播時間も関係する場合があります。
Let’s Encryptがチャレンジを検証するための条件を満たせるかを確認し、必要な通信経路だけを整えます。セキュリティ設定を無条件に無効化することを、自動更新の導入手順と考えないでください。
本番サイトの設定を変更できる権限と復旧方法を用意する
ACMEクライアントの設定や証明書の配布先を間違えると、HTTPSが利用できなくなる可能性があります。権限を持つ管理者が、現行設定のバックアップ、証明書ファイルの参照先、サービスの再読み込み方法、切り戻し方法を把握したうえで作業します。秘密鍵やDNS APIトークンを外部へ送信しないことも重要です。
Certbotで自動更新を導入する基本的な流れ
Certbotは、Let’s Encryptなどに対してACMEによる証明書の取得・更新を行えるクライアントです。ここでは、環境依存のインストールコマンドを無理に一つへ決めず、公式の案内に沿って設定を進める順番と、確認に使えるコマンドを示します。
手順1：OS・Webサーバーに対応した公式手順を選ぶ
まずCertbot公式の導入案内で、Nginx・ApacheなどのWebサーバーと利用するOSを選びます。Certbotはインストール方法やWebサーバープラグインによって証明書の適用方法が違うため、利用環境を確認せずに他サイトのコマンドをコピーすることは避けましょう。
共有レンタルサーバーやホスティング会社が独自の証明書管理を提供している構成では、Certbotを自分でインストールする必要がない場合もあります。現在の証明書管理方式に合わせて導入することが基本です。
手順2：Certbotが使えるか確認する
Certbotを導入済みのLinuxサーバーで、コマンドが利用できるか確認するときは以下を使います。これは状態を読むための操作で、証明書を変更しません。
certbot --versionバージョンが表示されない場合、インストールされていないか、PATHなど実行環境の問題が考えられます。実際のインストール方法は利用するOSと配布パッケージに合わせて確認してください。
手順3：証明書の取得方法と適用方法を決める
Certbotには、証明書を取得する認証プラグインと、Webサーバーの設定へ証明書を適用するインストーラープラグインがあります。例えばNginx用プラグインを利用する場合、公式資料では次のような発行・設定の例が示されています。ただし実際に実行すると証明書の発行やWebサーバー設定の変更が行われ得るため、読み取り専用のコマンドではありません。
sudo certbot --nginx -d example.com -d www.example.comこの例は、Nginxで対象のドメインを正しく公開し、CertbotのNginxプラグインが利用できる環境を前提とした参考例です。環境によっては --apache、certonly、Webroot、DNSのプラグインなど別の方法が適切です。example.com は説明用であり、必要な対象ホスト名へ置き換えます。
手順4：更新を定期実行する仕組みを確認する
Certbotの多くのインストール方法では、certbot renew を周期的に実行するタイマーやスケジュールが最初から用意されています。公式ユーザーガイドでも、すでに自動更新のスケジュールが設定されている場合は重ねて設定する必要がないと説明されています。
重要なのは、証明書を取得できたかだけでなく、将来も更新処理が起動する仕組みを確認することです。OSのタイマー、cron、管理サービスのスケジューラーのどれが担当しているかを把握します。次の章で確認方法を紹介します。
自動更新の定期実行はsystemd・cron・管理機能のどれか
更新を自動的に行うには、ACMEクライアントが適切な間隔で実行される必要があります。Certbotでは導入方法によって定期実行の仕組みが異なり、すべてのサーバーで同じサービス名や設定ファイルが存在するわけではありません。
systemdタイマーがある場合の確認
Linuxのsystemdを使う構成であれば、次のコマンドで現在登録されているタイマーを一覧表示できます。出力にCertbot関連のタイマーがあるか確認します。
systemctl list-timers --allタイマー名は配布方法で異なります。例えば certbot.timer の場合がありますが、Snapなど別の方法で導入した環境では名称が違う場合があります。certbot.timer が表示されないだけで、自動更新が設定されていないと断定しないでください。
該当タイマーが見つかったら、次回実行時刻や最終実行時刻、そのタイマーがどのサービスを呼び出すかを確認します。必要なら管理者がサービスのログも点検します。タイマーが一覧に存在することと、実際に更新処理が成功することは別です。
cronで実行する構成を確認する
cronで定期的にCertbotを起動する場合もあります。サーバーの管理権限がある担当者は、OSのcron設定や対象ユーザーのcrontabに certbot renew が登録されているか調べます。ただし、同一ホストで複数の実行スケジュールが存在する場合、更新タイミングやログの見方が分かりにくくなることがあります。
既存の定期処理があるなら、その所有者とログの場所を確認してから変更します。原因が分からないまま別のcronを追加することは避け、実際に利用する一つの管理方式を明確にします。
レンタルサーバーでは管理画面の設定を確認する
共有レンタルサーバーやマネージドサービスでは、証明書の自動更新が事業者側で提供されていることがあります。その場合、ユーザー側でsystemdやcronを確認する権限がないこともあります。管理画面の自動SSL設定、更新予定、失敗時の通知方法など、そのサービスで公開されている仕様を確認してください。
自社のWebサーバーと証明書を管理するクラウドサービスが異なる場合は、更新主体がどちらにあるのかを整理します。管理画面での成功表示だけで利用者側のHTTPSまで保証されるわけではありません。
Certbotの更新が正常に動くか確認する方法
自動更新が設定されていることを確認したら、将来の更新処理が成功できるかを試験します。Certbotには更新手続きをテストする --dry-run があり、通常はLet’s Encryptのステージング環境で検証できます。
手順1：Certbotが管理する証明書の状態を見る
まず、Certbotに登録された証明書を一覧表示します。以下は読み取り用のコマンドです。
sudo certbot certificates出力には、証明書名、対象ドメイン、期限、証明書ファイルの保存先などが表示されます。例えば対象ドメインが www.example.com の場合でも、Certbot内の Certificate Name が example.com になっている場合があります。更新テストで対象を指定するときは、実際の証明書名を使用します。
手順2：対象証明書の更新テストを実行する
対象を特定したら、管理者が更新に必要な認証経路とフックの影響を確認したうえで、次のコマンドで更新試験を行います。これはサーバー管理権限がある担当者向けの操作で、テストだから本番サービスへ一切影響しないという意味ではありません。
sudo certbot renew --cert-name example.com --dry-run通常、この試験ではLet’s Encryptのステージング環境を使ってドメイン認証や証明書発行手続きの可否を確認し、取得したテスト証明書を本番用として保存しません。ただしCertbotの設定によってWebサーバー設定の一時変更やフックの実行が発生する場合があります。特に独自の --server 指定がある環境では、接続先が公式のステージングとは限らないため事前確認が必要です。
手順3：成功メッセージの意味を正しく理解する
--dry-run が成功した場合、主としてその時点の設定でテスト用の更新手順を通過できたと判断できます。成功したからといって、本番の証明書が更新された、systemdやcronの定期実行が正常、更新後のWebサーバーへの反映も完了とは限りません。
一方、テストに失敗した場合はドメイン認証、接続経路、権限、プラグイン設定などの確認が必要です。詳しいエラー別の復旧対応は期限切れが発生した場合の復旧記事と分け、ここでは「何を確認できたか」を整理します。
手順4：スケジュールとログを別途確認する
定期実行が登録されている場合は、タイマーやcronの最終実行日時、実行ログ、直近の更新結果を確認します。--dry-run は管理者が手動で実行した試験なので、日々の定期タスクが予定どおり動いている証拠にはなりません。
定期実行のログに異常がなくても、公開HTTPSへの反映を確認する必要があります。更新テスト、定期実行、公開証明書の確認は、それぞれ別のチェック項目です。
証明書の更新後に公開サイトへ反映されているか確かめる
ACMEで新しい証明書を取得できても、Webサーバー・CDN・ロードバランサーで古いものが使われていれば、利用者には新しい証明書が届きません。自動更新の完成度は、取得できたかだけでなく、正しく配信されているかでも判断する必要があります。
証明書の保存先と公開側の証明書を区別する
Certbotの一般的な構成では、/etc/letsencrypt/live/ 配下に現在の証明書などへの参照が置かれます。しかし、Webサーバーがその参照先を使う設定になっていなければ、更新後も古い証明書を提供する場合があります。
「Certbotで表示された期限」と「ブラウザが受け取る期限」を照合することが重要です。CloudflareなどのCDNを使っている場合は、利用者向けとオリジン向けの証明書が別である可能性も考慮します。
OpenSSLで公開ホストの証明書を調べる
OpenSSLを利用できるLinux・macOS環境で、公開サイトが実際に提示する証明書の有効期間を確認するコマンド例です。example.com を管理している正式なドメイン名へ置き換えます。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer表示された notAfter は、取得できたサーバー証明書の終了日時です。2>/dev/null は診断メッセージを隠す指定なので、通信に問題がある場合は外してください。また、期限が将来の日付だからといって、証明書チェーンやホスト名の検証を含むすべてのHTTPS接続が正常というわけではありません。
更新前後の変化と実際のブラウザ表示を確認する
更新前後に取得した証明書の終了日時、識別情報、対象ホスト名を比較します。新しい証明書が発行されているかの確認に加え、ブラウザで正式なHTTPS URLを開き、証明書の警告が出ないか、主要画面が表示されるかを確認します。
証明書の有効期間だけを手動で確認する詳しい操作についてはChrome・Edge・FirefoxとOpenSSLでの有効期限確認方法をご参照ください。本記事では「更新した結果が外部から見えているか」を重視します。
deploy hookとは？更新成功後に必要な処理を行う
新しい証明書を取得したあと、Webサーバーを再読み込みしたり、別のサーバーへファイルを配置したりする必要がある構成もあります。Certbotでは、そのような更新後の処理にフックを利用できます。
更新成功後の処理にはdeploy hookを利用する
Certbotの公式資料では、--pre-hook と --post-hook は更新試行の前後に実行する処理、--deploy-hook は証明書の更新に成功したあとに実行する処理として説明されています。例えば新しい証明書が準備されたときだけ反映作業を行う場合は、deploy hookの考え方が適しています。
ただし、Webサーバーの再読み込みを毎回必ず設定すべきという意味ではありません。利用するCertbotプラグインやホスティング環境がすでに反映処理を行っている場合もあります。二重の処理や不要な再起動を避け、既存の構成を確認します。
dry-runではdeploy hookの試験範囲が異なる
Certbotの --dry-run では、通常、deploy hookは実行されません。公式ガイドには --run-deploy-hooks を使って該当フックをテスト時に実行する機能が説明されていますが、これは実際のフックスクリプトを動かすため、本番サービスへの影響があり得ます。
また、--run-deploy-hooks が利用されてもテスト証明書ではなく現在有効な証明書を用いると説明されています。これを「公開環境が新しい本番証明書へ切り替わったことの確認」と混同しないでください。検証前に独自フックの内容や変更対象を把握しておくことが必要です。
renewの終了コードだけで更新したと判断しない
Certbotの公式資料によると、certbot renew は更新対象の証明書が存在しなかった場合でも終了コード0になることがあります。したがって終了コード0は「今回、新しい証明書に切り替わった」という証明ではありません。
更新が実際に行われたかを判定する処理には、deploy hookや証明書の識別情報の比較などが必要になります。ログと公開側の証明書確認を組み合わせると判断しやすくなります。
自動更新が動いているか判断するチェック表
自動更新の確認は、ひとつのコマンドの結果だけで完了としない方が安全です。「準備」「実行予定」「更新試験」「適用」「公開確認」の順に、実際の仕組みと結果を照らし合わせましょう。
| 確認項目 | 確認する内容 | 完了の目安 |
|---|---|---|
| 管理主体 | 証明書を誰が発行・更新するか | 対象サービスと担当者が分かる |
| 対象ドメイン | www・サブドメインを含む発行対象 | 利用するホスト名を把握している |
| 認証方法 | HTTP-01・DNS-01など | 必要な到達性・権限がある |
| 定期実行 | systemd・cron・管理サービス | 実行主体とスケジュールが分かる |
| 更新試験 | renew –dry-runの結果 | 試験時点の認証・発行手順が成功 |
| 更新ログ | 定期実行時の記録と失敗有無 | 最近の実行結果を確認できる |
| 証明書の適用 | Webサーバー・CDNでの反映方法 | 新しい証明書を使う経路を把握 |
| 公開側の確認 | notAfter・ホスト名・HTTPS警告 | 利用者経路で適切な接続を確認 |
| 失敗時の連絡 | 担当者・代行者・確認手段 | 処理が失敗した場合に気付ける |
「試験成功」「定期実行成功」「実際に更新済み」は異なる
--dry-run の成功は更新の試験、タイマーの実行履歴は定期処理が動いたこと、公開証明書の新しい終了日時は利用者の接続先での状態を示します。これらは意味が異なるため、それぞれを確認した上で運用状況を判断します。
実際の更新時期が到来していない場合、公開証明書の期限が変わっていないこと自体は不具合ではありません。更新試験と定期実行の確認ができていても、将来の更新成功を100％保証するものではありません。
関係者が複数いる場合は担当の境界を明確にする
Web制作会社、サーバー事業者、DNS管理者、サイト運営者が異なる場合、誰がドメイン認証や証明書反映を管理するのか分からなくなることがあります。対象ホスト、更新担当者、定期実行の管理者、確認先を一覧にすると、変更時の混乱を減らせます。
Let’s Encryptの証明書短期化と自動更新の考え方
SSL証明書の運用では、証明書の有効期間が短くなる動きにも注意が必要です。有効期間が短い証明書ほど更新の実行機会が増えるため、手作業に依存するよりも更新の自動化と検証を整えておく意味が大きくなります。
2027年2月10日から標準64日になる予定
Let’s Encryptは2026年10月7日に、2027年2月10日以降に発行・更新する証明書の標準有効期間を64日へ変更する予定を公表しました。45日または6日の、より短い有効期間を選ぶ場合を除き、標準で64日になると案内しています。これは2026年10月26日時点では将来の予定です。
発表では、有効な既存証明書を一斉に失効させるわけではないとも説明しています。すでに有効な証明書を持っている場合、発表された日程だけを理由に新しい証明書を無理に取得し直す必要はありません。実際の証明書の有効期間を確認してください。
残り30日で更新という固定ルールに依存しない
証明書の有効期間が短くなると、以前の「期限の30日前に更新する」といった一律の処理条件が適切でない場合があります。Let’s Encryptの公式発表は、更新タイミングを有効期間の約3分の2の時点に合わせる考え方や、ACME Renewal Info（ARI）へ対応することを勧めています。
実際にどのタイミングで更新を試みるかは、利用するACMEクライアントのバージョンや認証局の案内に従います。自分で固定の日数を組み込んでいる場合は、実際の証明書の有効期間を考慮した設定へ見直す必要があります。
ARIは更新すべき時期を認証局から受け取る仕組み
ACME Renewal Info（ARI）は、認証局が更新に適した時期についてACMEクライアントへ情報を提供するための仕組みです。ただし、すべてのACMEクライアントが同じように対応しているとは限りません。利用するソフトウェアがARIを利用できるかを公式資料で確認してください。
ARIを利用しているからといって、ドメイン認証、証明書の配布、公開HTTPSへの反映が自動的にすべて成功する保証があるわけではありません。更新処理が正常に行われているかを確認する運用は引き続き必要です。
自動更新でよくある誤解と注意点
自動更新を設定したあとにトラブルを防ぐには、「どこまでが自動化されるのか」を正確に理解することが大切です。導入時に見落としやすい点を整理します。
Certbotを入れただけで自動更新が完了したと思う
Certbotが実行できても、証明書の発行対象や更新設定、定期実行の仕組みが揃っているとは限りません。既存の自動更新スケジュールの有無を確認し、更新試験とログで動作を確かめます。
手動のDNS-01を毎回行う構成を自動更新と呼ぶ
DNS-01を手動で運用している場合、更新のたびにTXTレコードを管理者が入力する必要が残る場合があります。Certbotの公式ガイドでも、--manual による証明書の自動更新には認証作業を自動化するフックなどが必要であると説明されています。更新のたびに人の操作が必要なら、その前提を明記して管理する必要があります。
dry-runに成功したので更新後の反映は不要だと思う
--dry-run は本番証明書を更新しない試験です。成功してもWebサーバーの設定やCDNへの反映が済んだ証拠にはなりません。証明書を実際に更新したときは、公開サイトが提示する証明書を確認します。
外部から取得できない結果を期限切れと断定する
証明書が取得できない原因には、DNSや通信経路、TLS接続の問題などもあります。notAfter を取得できないという結果だけで、期限切れと判断しないでください。現在の状況を把握するには通信エラーと期限の情報を別々に扱う必要があります。
秘密鍵やDNS APIトークンを広く共有する
自動更新には証明書に関係する秘密鍵や、DNSを操作する認証情報を扱う場合があります。権限を必要最小限にし、外部の資料やチャットに秘密情報を貼り付けないでください。自動更新のための便利さと、認証情報の保護は両立させる必要があります。
SSL証明書の自動更新についてよくある質問
導入時や更新試験のときに出てきやすい疑問を整理します。自動更新と他の運用を混同しないよう、役割を分けて確認してください。
Q．ACMEとLet’s EncryptとCertbotは同じものですか？
同じではありません。ACMEは証明書の発行・更新手続きを自動化するためのプロトコル、Let’s Encryptはその仕組みを利用して証明書を発行する認証局、CertbotはACMEを利用して認証局と通信するクライアントソフトウェアです。
Q．自動更新は無料で利用できますか？
Let’s Encryptは無料の証明書を発行する認証局で、CertbotもオープンソースのACMEクライアントです。ただし、サーバー、DNS、ホスティングサービス、保守管理などに費用がかかる場合があります。システム全体の運用が必ず無料という意味ではありません。
Q．ワイルドカード証明書を自動更新できますか？
可能な構成があります。Let’s Encryptではワイルドカード証明書のドメイン認証にDNS-01が必要です。DNS APIに対応したプラグインなどでTXTレコードの更新を自動化できるか確認しましょう。
Q．certbot renew –dry-runが成功したら自動更新は完成ですか？
いいえ。更新試験の成功は、試験時点の認証・発行手続きの確認です。定期実行が予定どおり起動するか、更新後にWebサーバーへ反映されるか、公開URLで正しい証明書が使われているかは別途確認が必要です。
Q．certbot renewを実行したのに有効期限が変わりません。
証明書が更新対象の時期に達していない場合、certbot renew は更新を行わずに正常終了することがあります。成功したように見えても、その実行で新しい証明書が発行されたとは限りません。表示内容と実際の証明書情報を確認しましょう。
Q．レンタルサーバーにもCertbotを入れるべきですか？
必須ではありません。レンタルサーバーがすでに証明書の自動更新を提供している場合があります。まず契約中サービスの管理画面や公式マニュアルを確認し、更新主体を把握してください。
Q．エンリンクでSSL証明書の自動更新までできますか？
現在の公開エンリンク機能一覧では、SSL証明書の有効期限と残り日数、期限接近の管理画面内通知を案内しています。一方、証明書を発行・更新してサーバーへ反映する機能は公開仕様で確認できません。自動更新の設定と、期限を確認する監視は別の役割です。
まとめ：ACMEで更新を自動化し、実際の動作まで確認する
SSL証明書の自動更新は、ACMEを利用して認証局との手続きを自動化し、新しい証明書を必要な時期に取得する仕組みです。Let’s EncryptとCertbotを利用する場合も、ドメイン認証・証明書の取得・定期実行・サーバーへの反映・外部からの確認を一つずつ確認することが大切です。
導入時は、HTTP-01とDNS-01のどちらが適切かを判断し、既存の自動更新設定を調べ、certbot certificates で証明書を把握します。そのうえで、影響を確認した担当者が certbot renew --dry-run を実行して将来の更新手続きをテストします。試験成功だけでは本番の更新や公開環境の反映まで確認できないため、スケジュールと外部HTTPSの状態も別に確認しましょう。
エンリンクでは、公式機能一覧で複数サイトのSSL証明書の期限日と残り日数を確認できる機能を案内しています。料金ページに記載された無料プランでは最大5サイトを登録し、定期監視は1日2回です。無料アカウント登録から利用できます。これは証明書を自動発行・更新する機能ではなく、自動更新された結果を外部から確認するための補助的な管理として位置づけられます。
参考資料・確認日
本記事のACME仕様、チャレンジ方式、Certbotのコマンドと更新タイミングは、以下の一次資料を確認しています（確認日：2026年10月26日）。実際のコマンドは利用環境とバージョンによって異なる場合があります。
- IETF RFC 8555：Automatic Certificate Management Environment（ACME） — ACMEの役割と発行・認証フロー。
- Let’s Encrypt公式：How It Works — ACMEによる認証と証明書の発行・更新。
- Let’s Encrypt公式：Challenge Types — HTTP-01とDNS-01の違い。
- Certbot公式：User Guide — certificates、renew、dry-run、deploy hook、定期実行。
- Certbot公式：Instructions — OS・Webサーバー別の導入方法。
- Let’s Encrypt公式：64-Day Certificate Lifetimes Coming Feb 2027（2026年10月7日） — 標準64日証明書への移行予定とARI。
