Let’s Encryptの自動更新に失敗したら、まずCertbotの実行ログを確認し、失敗した段階が「定期実行」「ドメイン認証」「証明書発行」「サーバーへの反映」のどこなのかを切り分けます。 やみくもに certbot renew を繰り返すより、エラーの種類に対応するDNS・Webサーバー・認証局側の条件を確かめる方が原因を絞れます。
例えば unauthorized と Invalid response はHTTP-01の認証用URLが正しく返されない場合に見られます。Timeout during connect ならポート80や通信経路、NXDOMAIN や SERVFAIL ならDNSを確認します。too many failed authorizations のような制限エラーでは、原因を直さず本番で再試行を続けるべきではありません。エラーの文言だけで原因を断定せず、対象ドメイン・認証方式・実際の応答を照合してください。
本記事では、Let’s EncryptとCertbotによる「更新に失敗したときの原因調査と対処」に限定して、エラーログ別の切り分け表、読み取り用コマンド、HTTP-01・DNS-01・IPv6・CAA・実行スケジュールの確認手順、修正後のテストを紹介します。自動更新の導入やACMEの仕組みを最初から知りたい場合はSSL証明書の自動更新とACMEの解説、すでに期限切れでブラウザ警告が出ている場合はSSL証明書が期限切れになったときの復旧手順をご覧ください。
Let’s Encryptの更新失敗は4つの段階に分けて確認する
更新処理は「スケジュールされた処理が動く」「認証局にドメインを確認してもらう」「証明書を取得する」「Webサーバーなどに反映する」という複数の段階からなります。どこまで進んだかを把握すると、不要な設定変更を減らせます。
段階1：更新処理が起動しているか
最初は、Certbotが自動実行されているかを確認します。systemdタイマーやcronが動いていない場合、証明書の取得に失敗したログ自体が存在しないことがあります。Certbotの実行履歴やスケジューラーを確認し、最後にいつ実行したのかを把握します。
定期実行が正常でも、証明書が更新対象の時期に達していなければ、実際の発行処理をせずに終わることがあります。「今回更新しなかった」ことと「更新に失敗した」ことは別です。
段階2：ドメイン認証（チャレンジ）が通るか
Let’s EncryptはACMEを使い、申請者が対象ドメインを管理していることを確認します。HTTP-01ならWebサーバーの指定URL、DNS-01ならDNSのTXTレコードを使います。更新失敗の原因は、この認証に必要なネットワーク・DNS・設定が前回発行時から変わったことにある場合があります。
例えば、Webサーバーの移転、DNSの切り替え、WAFの新ルール、IPv6の設定、APIトークンの権限変更などが確認対象です。実際の原因を決めるには、ログと現時点の設定を突き合わせます。
段階3：認証局から新しい証明書を取得できるか
ドメインの検証が通っても、証明書発行の条件やレート制限、CAAレコードなどの問題で発行できない場合があります。エラーに rateLimited や CAA が含まれるときは、サーバーの再起動よりも認証局が拒否した理由の確認が先です。
発行に失敗している場合は、期限が残っている既存証明書を不必要に削除しないでください。Let’s Encryptの公式資料は、繰り返す検証失敗を避けるためステージング環境での試験を勧めています。
段階4：取得後に新しい証明書が公開されているか
Certbotの更新自体に成功しても、Nginx・Apache・ロードバランサーなどの反映処理が失敗すると、公開サイトに古い証明書が残ることがあります。この状態はACMEでの発行失敗とは異なります。ログが更新成功を示す場合には、証明書の保存先、Webサーバーの参照先、再読み込みの実行結果を確認します。
期限切れがすでに起きている場合の具体的な反映・復旧操作は期限切れの復旧記事にまとめ、本記事ではまず失敗箇所を見つけるための手順を中心に説明します。
Certbotの更新失敗を調べる最初の5手順
最初に調べるのは「誰が、どの証明書を、どの方法で、いつ更新しようとして、どこで止まったか」です。以下はCertbotが導入されているLinux環境を想定した確認例です。読み取り用のコマンドと、実際に更新試験をするコマンドは区別して説明します。
手順1：Certbotの管理対象と有効期限を確認する
まず証明書名と対象ドメインを把握します。Certbotを使用しているサーバーで、必要な権限がある担当者が次を実行します。これは証明書一覧を表示するための読み取り操作です。
sudo certbot certificates出力中の Certificate Name、Domains、Expiry Date、Certificate Path を記録します。--cert-name で対象を絞る場合は、画面上のホスト名ではなく実際のCertificate Nameを指定します。対象が一覧にない場合は、Certbot以外で証明書を管理している可能性も確認してください。
手順2：Certbotのログで最初の失敗を探す
Certbotの公式ガイドによると、標準構成ではログが /var/log/letsencrypt/ に保存されます。例えば次のコマンドで、一般的なログファイルの末尾を確認できます。ファイルの場所は --logs-dir の指定や導入方法で異なることがあります。
sudo tail -n 120 /var/log/letsencrypt/letsencrypt.logERROR、Detail、unauthorized、DNS problem、rateLimited などに注目し、失敗した証明書名と時刻を確認します。最後の「すべて失敗しました」という要約だけでなく、その前に記録された実際の検証エラーを読むことが重要です。
ログを外部のサポートへ共有する場合は、ドメイン情報、アカウント情報、認証用トークン、内部パスなどを確認し、必要な範囲だけを共有します。秘密鍵やDNS APIの認証情報を貼り付けないでください。
手順3：認証方式と更新設定の保存内容を確認する
Certbotは更新時に、以前の取得・更新で使った設定を再利用します。webroot、nginx、apache、dns 系プラグイン、manual など、どの認証方式が登録されているかを確かめます。サイト移転後に昔のwebrootを参照している場合などは、設定と現行環境がずれている可能性があります。
標準的には /etc/letsencrypt/renewal/証明書名.conf などに更新設定が保存されます。ただし、秘密情報や環境固有の設定が含まれることもあるため、権限を持つ担当者が閲覧し、設定ファイルをいきなり直接書き換えないようにします。Certbot公式ガイドも手動編集は推奨していません。
手順4：修正対象を決めるまで本番で再試行しない
更新失敗を見てすぐ --force-renewal を繰り返すのは避けてください。失敗したドメイン認証を短時間に何度も再試行すると、Let’s Encryptの認証失敗に関する制限が適用される可能性があります。まず失敗の理由を特定し、該当する設定や通信条件を直します。
更新試験にはステージング環境を使う方法があり、Certbotでは通常 --dry-run がこれに該当します。ただし --server などの独自設定がある場合は接続先が異なることがあるため、試験時も事前確認が必要です。
手順5：エラーに該当する章を読み、ひとつずつ検証する
ログにHTTP-01の 404 があればWebrootとURL、接続タイムアウトならポート80やDNS、DNS-01の Incorrect TXT record ならTXTレコード、SERVFAIL なら権威DNSやDNSSECなど、最初に確認する場所が変わります。
以下の切り分け表は、ログ断片から次にどこを調べるかを決めるための一覧です。文字列は製品やバージョンによって異なるため、ひとつの断片だけで原因を断定するものではありません。
失敗ログ別の原因・確認箇所・対処方法の早見表
CertbotやACMEのログに現れやすいキーワードを軸に、最初に確認する項目を整理します。下表のログ文言は検索の手がかりとなる例であり、すべての環境で同じ全文が表示される保証はありません。
| ログのキーワード例 | 考えられる状況 | 最初に確認する場所 |
|---|---|---|
unauthorized / Invalid response |
HTTP-01の確認先から期待した応答を得られない | 認証URL、webroot、転送、WAF、各Webサーバー |
404 / 403 |
検証ファイルが見つからない、アクセスが拒否される | /.well-known/acme-challenge/ の経路 |
Timeout / Connection refused |
通信先に到達できない、接続を受け付けない | A・AAAA、ポート80、ファイアウォール、転送先 |
NXDOMAIN |
参照したDNS名が見つからない | 権威DNS、A・AAAA、DNS-01のTXT名 |
Incorrect TXT record |
DNS-01に必要なTXT値が一致しない | _acme-challenge の値、権威DNS、伝播 |
SERVFAIL |
DNS問い合わせが正常に完了していない | DNSSEC、権威DNS、CAA問い合わせ |
CAA / caa |
発行制限またはCAA問い合わせの問題 | CAAレコード、権威DNS、DNSSEC |
rateLimited / too many |
認証失敗や発行要求の制限に該当 | 具体的な制限名、再試行可能時刻、公式ルール |
Address already in use |
standalone方式が使用するポートを確保できない | 既存のWebサーバーと競合プロセス |
Another instance |
Certbotが重複起動している可能性 | systemd、cron、現在のCertbotプロセス |
Plugin / authenticator |
必要なプラグインや設定の不一致 | 導入済みプラグイン、renewal設定、実行環境 |
同じエラーワードでも確認すべき場所は違う
例えば unauthorized は権限がないという一般的な語ですが、ACMEの文脈では認証局がドメイン管理の確認に失敗したことを示す場合があります。Webサーバーのユーザー権限だけを変更しても直らないことがあります。どのドメインの、どのURLやDNS名を検証しようとしたかを読んでください。
本番ログと架空のサンプルを混同しない
この記事のコマンド例に登場する example.com は説明用のドメインです。ログ全文や認証トークンを実在するものとして再現した例ではありません。実際の対処では、Certbotに記録されたエラーメッセージと対象ホストを正確に確認し、下記の順序で検証します。
HTTP-01でunauthorized・404・403になる原因と対処
HTTP-01では、Let’s Encryptが対象のWebサイトへHTTPでアクセスし、指定されたチャレンジ情報を取得します。更新失敗がHTTP-01の認証URLに集中している場合は、まず実際の配信経路とWebサーバーの設定を確認します。
認証ファイルを置く場所と公開URLが一致しているか
HTTP-01で使うURLは、一般に http://対象ドメイン/.well-known/acme-challenge/トークン の形式です。webroot 方式なら、Certbotが想定するディレクトリとWebサーバーが公開しているDocumentRootが一致する必要があります。
移転や仮想ホストの変更後は、以前の設定に残ったwebrootのパスを参照していないか調べます。認証用ファイルが存在していても、公開URLが別のディレクトリへ向いている場合は404になります。
403やWAFの拒否を確認する
アクセス制限、Basic認証、WAF、CDN、リダイレクトルールなどにより、認証局がチャレンジURLへアクセスできない場合があります。通常のトップページが表示できても、/.well-known/acme-challenge/ だけ拒否されていることがあります。
対処では、該当する経路だけを許可できるか確認し、管理画面やサイト全体の認証・防御を無条件に解除しないことが重要です。WAFのイベントログで対象URLの拒否状況を確認できる場合は、失敗時刻と照合します。
HTTPからHTTPSへの転送は常に失敗するわけではない
Let’s Encryptの公式資料では、HTTP-01の検証で一定条件のリダイレクトを追跡すると説明されています。したがって「HTTPSへ転送しているから必ず更新できない」という説明は正しくありません。ただし、許可されない転送先や、転送先で誤った応答が返る構成は問題になります。
HTTP-01は通常、外部から80番ポートを利用できる必要があります。ポート80を閉じている場合は、ネットワークの条件を確認してください。Let’s Encrypt公式は、一般公開Webサイトでの80番ポートの扱いについて別途説明しています。
接続できるかをcurlで確かめる
次はHTTPのトップページへの到達状況を確認するための例です。実行結果が成功しても、認証用のトークンURLへ正しくアクセスできることまで証明するものではありません。対象のドメイン名に置き換えてください。
curl -I http://example.com/接続先のHTTPレスポンスや転送先を確認したら、サーバー管理者が実際のチャレンジURLに対するログと設定を照合します。検証に利用するトークンは発行時に都度生成されるため、古いトークンのURLをコピーして404だったという結果だけでは更新失敗の原因になりません。
Timeout・Connection refusedはポート80と接続経路を調べる
HTTP-01で接続タイムアウトや接続拒否のエラーが表示される場合、Let’s Encryptからの確認要求が対象Webサーバーへ届いていない可能性があります。まずDNSとポート80、公開経路にあるファイアウォールやロードバランサーを分けて調べましょう。
A・AAAAレコードが現在の配信先と一致しているか
ドメインのAレコードはIPv4、AAAAレコードはIPv6の接続先を示します。IPv4だけ正常でも、IPv6側が別のサーバーへ向いていると認証が失敗する場合があります。DNSの状態を確認できる環境では、次のコマンドで両方を調べられます。
dig +short example.com Adig +short example.com AAAA出力されたIPアドレスが意図した公開先かを確認します。DNS変更があった場合は、権威DNSと実際にアクセスされる接続先の違いも調べます。dig がない環境では、利用可能なDNS管理画面や別の確認方法を用いてください。
IPv6の応答が間違っているとIPv4正常でも失敗する
Let’s Encrypt公式のIPv6解説によると、AとAAAAが存在する場合、ドメイン検証ではまずIPv6のアドレスを優先します。条件によってIPv4へ再試行することがありますが、IPv6側が接続だけ成功して誤ったチャレンジ内容を返す場合は、IPv4へ切り替わらず失敗することがあります。
IPv6を提供する意図がないのに誤ったAAAAレコードが残っている場合は、DNS管理者と配信構成を確認して設定を修正します。IPv6の問題を回避するためだけに、必ずすべてのサイトからAAAAを削除すべきという意味ではありません。
外部から80番ポートへ到達できるか
ファイアウォール、セキュリティグループ、ホスティング側のポート制限、リバースプロキシなどにより、80番ポートへの到達が妨げられる場合があります。サーバー内から自分自身へアクセスできたという結果だけでは、外部の認証局が到達できることを保証しません。
Linux上でWebサーバーの待ち受け状況を見る場合、管理権限のある担当者は次のような読み取り用コマンドを利用できます。
sudo ss -ltnp '( sport = :80 )'この結果はサーバー上の待ち受け情報であり、インターネットから到達できるかを確定するものではありません。問題が続く場合は、外部からのHTTP接続、DNS、ネットワーク機器の設定を合わせて調べます。
DNS-01のTXT不一致・NXDOMAINを切り分ける
DNS-01では、認証局が _acme-challenge という名前のTXTレコードを確認します。HTTP-01と違ってWebサーバーのポート80が直接の認証条件ではないため、更新失敗時はDNSの値と反映状況が中心となります。
TXTレコードが正しい名前で公開されているか
次のコマンドは、例示用ドメインでDNS-01のTXTレコードを問い合わせます。読み取り操作でありDNS設定は変更しません。
dig TXT _acme-challenge.example.com出力に期待する検証用の値が存在するかを確認します。ただし、現在のCertbot試行で発行された値でなければ意味がありません。以前の更新で使用した古いTXT値が残っているだけでは、今回の認証に成功できるとは限りません。
DNS APIトークンの期限・権限・対象ゾーンを確認する
DNSプラグインでTXTレコードを自動更新している場合、認証情報が失効している、管理するDNSゾーンが変更された、権限が不足しているといった理由でTXTの作成に失敗する場合があります。ログにDNS事業者側のAPIエラーがある場合は、該当プラグインの仕様と権限設定を確認してください。
トークンの値をログや問い合わせ本文に貼り付けてはいけません。認証情報を確認する場合でも、必要最小限の権限と安全な保存方法を守ります。
DNSの伝播時間や参照先の違いに注意する
TXTを登録した直後、すべてのDNS経路から同じ値が見えるとは限りません。DNS事業者の反映時間、権威DNSの構成、委譲設定によって見える結果が異なる場合があります。Let’s Encryptの公式資料でも、DNS-01では値が反映されるまでの時間を考慮する必要があると説明されています。
認証局が参照するDNSの情報と、管理者が利用するDNSリゾルバーの結果に違いがある場合は、権威DNSや委譲先も確認します。単に待てば必ず直るわけではなく、設定したレコード名や内容が誤っている場合は修正が必要です。
NXDOMAINはDNS名と委譲を確認する
NXDOMAIN は問い合わせ対象のDNS名が存在しないことを示します。DNS-01の場合は _acme-challenge の名前が正しいか、TXTを設定したDNSゾーンが権威DNSとして公開されているかを確認します。HTTP-01に関係するドメインならA・AAAAの向き先も確認してください。
DNSプラグインが自動作成したつもりのレコードを別のDNS事業者へ書いている場合もあります。現在のネームサーバーと実際にAPI操作しているゾーンを照合すると切り分けやすくなります。
SERVFAIL・CAAエラーではDNSSECと認証局の発行条件を見る
DNSに関するエラーでも、TXTレコードの不足とCAAの検証失敗は別の問題です。Let’s Encryptは証明書の発行前にCAAレコードも確認するため、CAAの内容やDNSの応答不良が更新失敗に結び付くことがあります。
SERVFAILが出たらDNSSECや権威DNSを確認する
Let’s EncryptのCAAに関する公式解説では、SERVFAIL の代表的な原因としてDNSSECの検証失敗が紹介されています。権威DNSが必要な情報を返せていない場合なども考えられます。SERVFAIL を見ただけで「TXTを追加すれば直る」とは判断しないでください。
DNSSECを利用している場合は、署名やDNSSECの構成、ネームサーバー変更との整合性を確認します。権威DNSが応答しているか、DNS事業者の障害がないかも調べます。DNSSECは適切な検証の仕組みなので、原因を確認せず無条件に無効化することを標準対処としません。
CAAレコードによりLet’s Encryptが許可されているか
CAAは、どの認証局に証明書を発行させるかをドメイン所有者が指定できるDNSレコードです。CAAの設定によりLet’s Encryptの発行が許可されていない場合は、発行できない原因になる可能性があります。設定を確認するコマンド例は次のとおりです。
dig CAA example.comCAAが表示されなかったからといって必ず問題というわけではありません。親ドメインのレコードも判定に関係する場合があり、エラーの内容によってはCAA問い合わせ時のDNS応答不良が原因です。対象ドメインの委譲関係と、Let’s Encryptが確認したCAAの名前を調べます。
DNS側の原因を直してから再試験する
CAAやDNSSECが原因であれば、Certbotを何度再実行しても結果は変わらない場合があります。DNSの管理担当者が設定を確認し、必要な修正が反映されたことを確かめてから、ステージングで更新を試す方が安全です。
Let’s Encryptの公式ドキュメントには、DNS事業者がCAAの問い合わせへ不正な応答を返す場合や、DNSSEC検証が失敗する場合の解説があります。ログの内容がそれに該当するかを照合しましょう。
rateLimited・too manyで更新できない場合の対応
Let’s Encryptには、発行サービスの安定性を保つための制限があります。認証失敗を繰り返した場合や短時間に大量の発行を試みた場合などに、制限エラーが表示されることがあります。どの制限に当たったのかを区別せずに再試行を続けないでください。
エラー文に記載された制限の種類を確認する
rateLimited や too many failed authorizations といった断片が表示された場合は、エラーメッセージの全文に記載された制限の種類、対象ドメイン、再試行可能時刻や案内URLなどを確認します。Let’s Encryptの公式レート制限の説明では、認証失敗と証明書発行などで異なる制限が説明されています。
一部の更新は通常の新規発行と異なる制限の扱いになることがあります。具体的なエラーメッセージを読まず「証明書は何回まで」と一律に判断するのは避けましょう。
失敗の根本原因を修正してステージングで検証する
HTTP-01のアクセス拒否やDNS-01のTXT設定の誤りが原因なら、制限が解除されても同じ失敗を繰り返す可能性があります。認証経路やDNSを先に修正し、Let’s Encryptのステージング環境でテストします。--dry-run は通常ステージングを利用しますが、実行環境に独自の --server 設定がある場合は事前確認が必要です。
ステージングは本番と異なるテスト用の証明書を使用するため、取得結果をそのまま本番のHTTPS公開に適用するものではありません。テストを実施するときも、プラグインやフックがサーバー設定に影響する場合があることを確認します。
期限が迫っている場合は管理者に状況を共有する
制限が適用されている間に証明書の期限が迫っている場合は、対象サイト・有効期限・失敗の原因候補・制限メッセージ・次回の確認予定を管理担当者へ共有します。期限切れが発生した場合の利用者向け案内と復旧作業は別途必要になります。
制限の解除方法や適用条件は公式資料とエラー本文で確認し、根拠のない待ち時間を約束しないようにしてください。
Certbotの定期実行・設定・プラグインが原因の場合
ドメイン認証に関係するログが見つからない場合や、以前は動いていた更新処理が止まった場合には、Certbotの実行環境を確認します。systemd・cron・Snapなどの導入方法、実行ユーザー、プラグインの有無によって確認先が変わります。
systemdやcronで更新処理が実行されているか
systemdを使っている環境で、タイマーが登録されているかを確認するための読み取り用コマンドです。
systemctl list-timers --all表示名は導入方法によって異なります。certbot.timer が見つからないというだけで、自動更新が存在しないとは断定できません。cronで設定されている場合もあれば、ホスティング事業者が別の仕組みで管理している場合もあります。
更新処理が起動していることと、更新に成功したことも別です。実行時刻、ログ、戻り値、実際の証明書を分けて確認しましょう。
同時起動・ロックの問題がないか
Certbotは、複数プロセスが同じ設定ディレクトリなどを同時に扱わないようロックを使用します。重複起動を示すログがある場合、既存の実行プロセスやタイマー・cronの重複設定を調べます。現在のCertbotプロセスを調べる読み取り例は次のとおりです。
ps -ef | grep '[c]ertbot'ロック関連のファイルが見える場合も、実際に処理が走っている可能性があるため、原因を確認せずロックファイルを削除しないでください。Certbotの公式ガイドは複数インスタンスの同時動作を防ぐロックの仕組みを説明しています。
旧webrootやプラグインの設定が残っていないか
サイト移転後に以前のwebroot設定を使っている、Nginx・Apacheの設定が変更された、必要なDNSプラグインが利用できないといった状況では、以前の更新設定が使えなくなる可能性があります。どのプラグインが利用できるかを確認するときは、次の読み取りコマンドを使えます。
certbot pluginsCertbot 2.3.0以降では、更新設定の変更に certbot reconfigure を利用できることが公式ガイドに記載されています。ただしこれは設定変更を行う操作です。バージョンと実行条件を確かめ、必要な権限のある管理者が検証してから利用してください。/etc/letsencrypt/renewal/ の設定ファイルを直接編集する方法は、破損のおそれがあるため推奨されません。
standalone方式のポート競合を確認する
standalone方式でHTTP-01の認証用ポートを使用する構成では、すでにNginxなどが80番ポートを使っていると待ち受けできない場合があります。ポート競合を示すエラーがあれば、現在の待ち受けサービスとCertbotの認証方式を確認します。
本番サイトのWebサーバーを停止すれば必ず直るという意味ではありません。停止が利用者へ影響する場合があるため、既存のプラグインやwebroot方式など、サービスを止めずに認証できる構成も含めて管理者が判断します。
修正後はdry-runと公開証明書の確認を分けて行う
原因と思われる箇所を修正したら、再試行前に修正した設定が反映されているかを確認します。次に更新試験で認証が通るかを調べ、実際の証明書の有効期限と公開側の接続を照合します。更新テストが通っただけでは、本番証明書が新しくなったことを証明しません。
対象証明書だけをdry-runで試験する
Certbot公式の --dry-run は、一般的にLet’s Encryptのステージング環境で更新を試す方法です。次の例は、Certbotが管理する証明書名を example.com としたものです。sudo certbot certificates で確認した実際の名称へ置き換えてください。
sudo certbot renew --cert-name example.com --dry-runこの操作は通常、本番用の新しい証明書を保存しません。ただし、Certbotのプラグインやpre/postフックによってWebサーバーの一時的な設定変更や再読み込みが発生する場合があります。サーバー管理者が設定を確認した上で行ってください。
成功したら本番の更新条件と定期実行も確認する
dry-runが成功した場合は、試験時の認証が通ったと考えられます。しかし、定期実行の登録がない場合には次の自動更新機会で処理が起動せず、証明書は更新されません。スケジューラー、実行ユーザー、前回ログ、今後の更新条件を確認します。
実際に更新が必要な時期に達していなければ、certbot renew が証明書を更新せずに正常終了する場合もあります。更新しなかったことと失敗したことを混同しないようにします。強制更新を繰り返して確認する方法は避けましょう。
公開URLで証明書が切り替わったか確認する
本番で新しい証明書が発行されたときは、利用者が接続するHTTPSのホスト名に対して、実際に提示される証明書を確認します。Linux・macOSのOpenSSLで終了日時を取得する例は次のとおりです。これは読み取り用で証明書を変更しません。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -subject -issuer出力された終了日時が将来で、対象ホストに対応しているか確認します。2>/dev/null は診断メッセージを隠すため、取得できなかったときは外して接続エラーを調べます。更新ファイルと公開側で期限が食い違う場合は、Webサーバー・CDN・ロードバランサーなどで古い証明書が使われている可能性があります。
本番の復旧完了はブラウザで確認して判断する
証明書が取得できるだけでは、ブラウザが正しい接続先を信頼できることまで保証されません。ブラウザでHTTPSの警告がないこと、ログインやフォームなど影響した機能が利用できることを確認します。必要に応じてサブドメインや別経路も確認し、未確認の範囲を分けて記録します。
証明書がすでに期限切れで利用者へ影響が生じている場合は、復旧確認チェック表のある記事も参照してください。
エラー解消を確認するチェックリスト
原因を直したと思っても、設定反映や外部確認が不足すると同じ障害を繰り返す場合があります。次のチェック項目を用いて、確認できた事実だけを完了としましょう。
- 失敗した証明書名と対象ホスト名を確認したか。
- 最初に失敗したログの日時と具体的なエラーを保存したか。
- HTTP-01かDNS-01か、実際の認証方式を確認したか。
- HTTP-01の場合、認証用経路と外部からのポート80到達性を確認したか。
- DNS-01の場合、TXTレコードの名前・値・権威DNS・反映状況を確認したか。
- AとAAAAの両方が意図した接続先を指しているか確認したか。
- CAA・DNSSECなど別のDNSエラーを見落としていないか。
- rateLimitedの場合、根本原因を直すまで再試行を抑えたか。
- Certbotの実行スケジュールとプラグインを確認したか。
- 影響を把握したうえで更新テストを実施したか。
- 本番の新しい証明書が実際の公開URLに反映されているか。
- ブラウザの警告と主要な操作を確認したか。
結果は「未確認」「確認済み」「対応済み」を分ける
期限切れが迫っているときは、調べる順序を早めたくなります。しかし、確認していない項目を完了と扱うと、同じ原因が残る可能性があります。ログの確認・設定の修正・更新試験・公開サイトの確認を別々に記録してください。
定期実行の次回成功も確認する
手動でdry-runを実施しただけでは、将来の自動実行が成功する保証はありません。次回の定期実行ログや、期限が近づいたときに実際の公開証明書が更新されたかを確認できる運用を考えましょう。期限が近いサイトが複数ある場合は、対象の一覧と担当者を整理すると見落としを減らせます。
Let’s Encrypt更新失敗に関するよくある質問
「Certbotが失敗と表示した」「自動更新のはずなのに期限が近い」といった場面で、特に質問されやすい点をまとめます。更新の失敗と別の状態を区別して判断してください。
Q．certbot renewを実行しても証明書が新しくなりません。
証明書が更新対象の時期に達していない場合、Certbotは更新を行わず正常終了することがあります。失敗のログがあるか、更新対象として判定されているか、現在の有効期限がいつかを確認してください。更新する必要がないことと失敗は別です。
Q．「unauthorized」が出たら何を調べればよいですか？
HTTP-01の検証URLが正しく返されるか、webrootや転送ルール、WAF、公開先の各サーバーなどを確認します。DNS-01を使っている場合は認証方式の違いを踏まえて、ログの詳細に従います。「unauthorized」という単語だけで同じ原因と決めないでください。
Q．80番ポートを開けているのに失敗します。
ポートが開いているだけでは、認証ファイルが正しい内容で返されるとは限りません。DNSのA・AAAA、リバースプロキシ、認証パス、Webroot、複数サーバーの配信、WAFなどを確認します。IPv6で別の内容が返される場合もあります。
Q．DNS-01でTXTを登録しましたが通りません。
TXTを設定した名前・値が今回の検証要求と一致するか、権威DNSへ反映されているか、DNSプラグインが正しいゾーンに書き込めているか確認します。古いTXTだけが残っている場合や、DNSの伝播に時間がかかっている場合もあります。
Q．SERVFAILが出たらTXTを作り直すべきですか？
必ずしもそうではありません。DNSSECの検証、権威DNSの応答、CAA問い合わせなどを確認します。Let’s Encrypt公式はCAAに関するSERVFAILの原因としてDNSSECやネームサーバーの問題も説明しています。
Q．レート制限に達した場合は何回再試行できますか？
制限は種類によって異なり、公式ルールも変更される可能性があります。表示されたエラーにある制限名や再試行条件と、Let’s Encryptの公式レート制限資料を確認してください。原因を直さず同じ失敗を繰り返すことは避けます。
Q．dry-run成功後、すぐ公開証明書も更新されますか？
通常の --dry-run は本番用証明書を更新しない試験です。成功しただけでは公開側が新しい証明書に切り替わったとはいえません。実際の更新結果、定期実行、公開側の証明書を別々に確認してください。
Q．自動更新の仕組みを最初から設定したい場合は？
導入の基本はSSL証明書の自動更新とACMEの仕組みをご参照ください。この記事は更新に失敗した状態からの切り分けを扱うため、新規導入手順の詳しい説明とは分けています。
まとめ：ログで失敗箇所を特定し、修正後に再試験する
Let’s Encryptの自動更新に失敗した場合は、Certbotの実行ログと管理対象を確認し、失敗した場所を特定することが出発点です。HTTP-01の認証URL、DNS-01のTXTレコード、A・AAAA、CAA・DNSSEC、認証失敗の制限、タイマーやプラグインの設定では、それぞれ確認すべき情報が異なります。
原因を確認せず本番で更新を繰り返すと、発行制限や設定変更の混乱を招く可能性があります。ログと現在の設定を照合し、必要な修正を行ってから、通常はステージングを利用する --dry-run で更新試験を行います。さらに定期実行の記録と、実際に公開されている証明書を確認して、同じ問題が残っていないか確かめましょう。
自動更新そのものの導入方法は前回のACME・自動更新の記事、期限切れ後の復旧は期限切れの対処記事、期限が近いサイトをまとめて管理する方法はSSL証明書の期限監視記事に分けてあります。
エンリンクでは、現行の機能一覧でSSL証明書の期限日と残り日数、管理画面内の期限接近通知を案内しています。料金プランにある無料プランは最大5サイトで定期監視1日2回です。無料アカウント登録から確認を始められます。ただし、エンリンクがLet’s Encryptの再発行や更新失敗の自動修復を代行するという意味ではありません。
参考にした公式資料と確認日
この記事の技術的な説明は、CertbotとLet’s Encryptの公式資料を基に確認しています（確認日：2026年10月26日）。ログ文言は環境により異なり、本文のコマンド例は一般的なLinux・Certbot構成を前提とします。
- Certbot公式：User Guide — 証明書一覧、ログ、更新設定、dry-run、ロック、スケジュール。
- Let’s Encrypt公式：チャレンジの種類 — HTTP-01の80番ポート、DNS-01のTXT、認証方式の違い。
- Let’s Encrypt公式：IPv6 Support — AAAAレコードの問題とIPv4へのフォールバック条件。
- Let’s Encrypt公式：Rate Limits — 認証失敗と発行要求の各種制限。
- Let’s Encrypt公式：CAA — 発行権限とSERVFAIL、DNSSECの問題。
- Let’s Encrypt公式：Staging Environment — 本番とは別の検証環境。
