ドメイン認証（DV）SSLの更新が失敗したときの対処：自動更新のエラーの読み方と原因別の直し方

ドメイン認証（DV）SSLの更新が失敗する原因の大半は、認証局がドメインの管理権限を確認する通信（DCV）が届かないことです。Let's Encrypt などの自動更新でも、販売代理店で買う有料DVでも、まずエラーメッセージから「どの確認で、何が返ったか」を読み取れば、原因はかなり絞り込めます。この記事では、エラーの読み方と、起こりやすい順の原因・確認方法・直し方、更新できたのにサイトが古いままのときの対処を説明します。

DCVの各方式（メール・DNS・ファイル）の手順そのものではなく、「前は更新できていたのに止まった」場面の切り分けを中心に扱います。

まず期限と失敗の内容を確認する

最初に、いま配信されている証明書の期限を確認します。残り日数によって、落ち着いて原因を探すか、手動で取り直すかが決まります。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

Certbot を使っている場合は、本番の発行枠を消費しないテスト環境で更新を試し、エラーを再現させます。

sudo certbot renew --dry-run
# 詳しい記録はこちら
sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log

失敗すると、ホスト名ごとに Type と Detail が表示されます（表示形式はバージョンにより異なります）。Type はACMEの規格で決まった分類で、次のように読み替えられます。

• unauthorized: 認証局の確認には応答したが、期待した内容ではなかった（多くは404や別サイトの応答）
• connection: 接続できなかった（ポートが閉じている、タイムアウト、拒否）
• dns: ドメインの名前解決ができなかった
• caa: CAAレコードがこの認証局での発行を許可していない
• rateLimited: 発行回数などの上限に達した

Detail には、認証局がアクセスしたURLやIPアドレス、返ってきたステータスコードが書かれています。原因探しの手がかりはほぼここにあります。

原因1：認証用のURLに外から届かない

HTTP-01方式では、認証局が http://example.com/.well-known/acme-challenge/（トークン） にアクセスします。これが失敗する典型例は次のとおりです。

• ドットで始まるパスを一律に拒否している: nginx で location ~ /\. { deny all; } のような設定があると、.well-known も403になります。
• ドキュメントルートが変わった: サーバー移行やディレクトリ構成の変更後、Certbot の webroot の設定が古いパスのままになっている。
• ポート80を閉じた: HTTPSだけで運用しようとしてファイアウォールで80番を閉じると、HTTP-01は失敗します。
• サイト全体にBasic認証をかけた: 公開前のサイトや一時的な制限で認証をかけると、401が返ります。

nginx でドットファイルを拒否している場合は、認証用のパスだけを先に許可します。^~ を付けた前方一致は正規表現の location より優先されるため、拒否ルールより前に評価されます。

location ^~ /.well-known/acme-challenge/ {
    root /var/www/html;
    default_type "text/plain";
}

location ~ /\. {
    deny all;
}

root は実際に Certbot の webroot に指定しているパスに合わせます。設定は /etc/letsencrypt/renewal/example.com.conf の webroot_path などで確認できます。変更後は sudo nginx -t で構文を確かめてから再読み込みし、テスト用のファイルを置いて外部から取得できるかを試します。

なお、HTTPからHTTPSへのリダイレクト自体は問題になりません。Let's Encrypt はリダイレクト先のHTTPSも追いかけ、その際は期限切れなどの証明書エラーがあっても確認を続ける仕様です（2026年10月現在）。リダイレクト先が別のサーバーやドメインになっていると失敗します。

原因2：DNSが別のサーバーを向いている

Detail に書かれたIPアドレスが、自分のサーバーのものでない場合はDNSの問題です。

dig A example.com +short
dig AAAA example.com +short

特に見落としやすいのがAAAAレコード（IPv6）です。AAAAレコードがあるとIPv6での接続が優先して試されるため、サーバーがIPv6で応答しない、またはAAAAが古いサーバーを指したままだと失敗の原因になります。IPv6を使っていないなら、AAAAレコードを削除するのが簡単な解決です。

サーバー移行後に旧サーバーで自動更新が動き続けている、ネームサーバーを変更した、CDNのプロキシを有効にした、という変化があった場合もここを疑います。レンタルサーバーの無料SSL機能は、ドメインがそのサーバーを向いていることを前提に更新されるため、DNSを他社に切り替えると更新が止まることがあります。

原因3：ファイアウォールや国別制限で認証局の通信を遮断している

認証局は、なりすましを防ぐために複数の地点のネットワークから確認を行う方式（マルチパースペクティブ検証）を採っています。そのため、「日本国内のIPアドレスだけ許可する」「特定のIPアドレスだけ許可する」といった制限をかけていると、海外の地点からの確認が届かずに失敗します。Let's Encrypt は確認に使うIPアドレスを公開していないため、IPアドレスで許可する方法は使えません。

Type が connection でタイムアウトになっている場合は、サーバーのファイアウォール、WAF、セキュリティプラグインの国別ブロック設定を確認します。どうしても制限を外せない環境では、外部からのHTTPアクセスが要らないDNS-01方式への切り替えを検討します。

原因4：CAAレコードや発行上限

Type が caa なら、ドメインのCAAレコードで認証局が許可されていません。dig CAA example.com +short で内容を確認し、使う認証局を追加します。

rateLimited は、失敗を繰り返したことによる一時的な制限であることが多いです。原因を直す前に本番で何度も再試行すると、制限が解けるまで待つことになります。原因の調査は --dry-run で行い、直ったことを確かめてから本番の更新を一度だけ実行します。

原因5：更新はできたのにサイトが古い証明書のまま

certbot renew が成功しているのに期限が延びない場合は、Webサーバーが新しいファイルを読み込み直していません。更新後に自動で再読み込みするよう、デプロイフックを設定します。

# 更新に成功したときだけ実行されるスクリプトを置く
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

あわせて、自動更新のタイマーが動いているかも確認します。パッケージで入れた場合と snap で入れた場合でタイマー名が異なります。

systemctl list-timers | grep -i certbot

ロードバランサーやCDNで別の証明書を使っている場合は、そちらの期限も確認してください。

有料DV証明書の場合

販売代理店から購入するDV証明書は、更新のたびに注文とDCVが必要になります。認証局の決定により、ドメイン認証の結果を使い回せる期間は2026年3月から段階的に短くなっており、以前は不要だった再認証を求められることが増えています。承認メールの宛先が存在しない、DNS認証のレコードを消してしまった、という理由で止まることが多いため、注文の状態と認証方式を管理画面で確認します。

期限の通知に頼らない

Let's Encrypt は2025年に有効期限の通知メールを終了しています。また、証明書の最大有効期間は業界全体で段階的に短縮されており、Let's Encrypt も既定の有効期間を短くする計画を公表しています（2026年10月現在、時期は公式の告知で確認してください）。更新回数が増えるほど失敗に気づく機会も増えるため、外部の監視サービスや定期実行のスクリプトで証明書の期限を確かめる仕組みを用意しておくと安心です。

作業の前には /etc/letsencrypt ディレクトリとWebサーバーの設定をバックアップし、設定変更は可能ならステージング環境で試してから本番に反映してください。

まとめ

• まず certbot renew --dry-run とログで、失敗の Type と Detail を確認します。原因の手がかりはほぼそこにあります。
• 多い原因は、認証用URLに届かない（ドットファイル拒否・ポート80閉鎖・Basic認証）、DNSやAAAAレコードが別のサーバーを向いている、国別・IP制限で認証局の通信を遮断している、の順です。
• 更新は成功したのに古いままなら、デプロイフックでWebサーバーを再読み込みします。
• 通知メールに頼らず、期限の監視を自分で用意します。

• Let's Encryptのレート制限に引っかかったときの対処
• CertbotでSSL証明書を自動更新する設定