2026年6月5日

ワイルドカードSSLの更新が失敗したときの原因と対処：DNS認証・自動更新・対象範囲の確認

ドメイン管理

ワイルドカードSSL（*.example.com）の更新が失敗する原因は、ほとんどが DNS を使ったドメイン認証にあります。ワイルドカード証明書は Web サーバーにファイルを置く HTTP 認証では発行できないため、DNS の TXT レコードを自動で書き換える仕組み（API の認証情報や DNS プラグイン）が壊れると、更新がそこで止まります。この記事では、Let's Encrypt（Certbot）の場合を中心に、ログの読み方と原因の確認順、商用の認証局（CA）で更新する場合の注意点を説明します。

まずログとエラーメッセージを確認する

Certbot で更新している場合は、本番の更新を待たずに、試験用の更新を実行してエラーを確かめます。--dry-run は Let's Encrypt の試験環境を使うため、本番の発行回数の上限を消費しません。

sudo certbot renew --dry-run --cert-name example.com
sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log

あわせて、その証明書がどの方法で更新される設定になっているかを確認します。

sudo cat /etc/letsencrypt/renewal/example.com.conf

[renewalparams] の authenticator の値が手がかりになります。manual なら手作業で TXT レコードを追加して取得した証明書、dns-cloudflare などなら DNS プラグインで取得した証明書です。この値によって、次に見る原因が変わります。

エラーメッセージは、おおむね次のように読み分けられます（文言は Certbot や ACME サーバーの版によって異なります）。

手動プラグインには認証用スクリプトが必要、という趣旨のエラー: 原因1（手動で取得した証明書）
認証情報ファイルや API 呼び出しのエラー（401、403 など）: 原因2（API の認証情報）
TXT レコードが見つからない、値が違う、という趣旨のエラー: 原因3（反映待ち・追加先の誤り）
CAA レコードが発行を禁止している、という趣旨のエラー: 原因4

原因1：手動（manual）で取得していて自動更新できない

最も多いのがこのケースです。初回に --manual --preferred-challenges dns で TXT レコードを手で追加して取得した証明書は、更新のときも同じ作業が必要です。cron や systemd タイマーによる自動更新では人が TXT レコードを追加できないため、毎回失敗します。

対処は、使っている DNS 事業者の Certbot 用 DNS プラグインに切り替えることです。Cloudflare の場合は certbot-dns-cloudflare があり、Route 53 や Google Cloud DNS などにも公式のプラグインがあります。対応するプラグインがない DNS 事業者なら、TXT レコードを書き換える処理を --manual-auth-hook に指定するか、後述の CNAME 委任を使います。

# Cloudflare の DNS プラグインで取り直す例（認証情報ファイルは次の原因2を参照）
sudo certbot certonly --cert-name example.com \
  --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

取り直すと /etc/letsencrypt/renewal/example.com.conf の authenticator が書き換わり、以後は certbot renew で自動更新されるようになります。取り直しの前には /etc/letsencrypt ディレクトリ全体をバックアップしておきます。

原因2：DNS の API 認証情報が無効になっている

DNS プラグインを使っていても、API トークンの失効・削除、権限の変更、DNS 事業者側のアカウント整理などで認証情報が使えなくなると更新は失敗します。前任者の個人アカウントで発行したトークンを使っていて、退職時にアカウントごと消えた、という例もあります。

Cloudflare の場合、認証情報ファイルは次の形式です。トークンには対象ゾーンの DNS を編集できる権限だけを与え、ファイルは root 以外が読めないようにします。

# /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your-api-token

sudo chmod 600 /root/.secrets/cloudflare.ini

ファイルの権限が緩いと Certbot が警告を出します。トークンを作り直したらこのファイルを更新し、certbot renew --dry-run で通ることを確認します。認証情報は Git リポジトリやバックアップの公開領域に含めないように管理してください。

原因3：TXT レコードの反映待ち・追加先の誤り

Let's Encrypt は _acme-challenge.example.com の TXT レコードを確認します。ワイルドカード（*.example.com）と頂点（example.com）を同じ証明書に含める場合、どちらも同じ _acme-challenge.example.com に別々の値が追加されるため、TXT レコードが2つ並ぶのが正常な状態です。古い値を上書きしてしまう自作スクリプトや DNS 事業者の仕様だと、片方の認証が失敗します。

# 権威DNSサーバーを調べ、そこに直接問い合わせる
dig +short NS example.com
dig +short TXT _acme-challenge.example.com @ns1.example-dns.net

権威 DNS サーバーに値があるのに失敗する場合は、反映前に認証が始まっている可能性があります。DNS プラグインには待ち時間を延ばすオプションがあり、Cloudflare プラグインなら --dns-cloudflare-propagation-seconds で指定できます。

ネームサーバーを別の事業者に移したのに、DNS プラグインが古い事業者の API を書き換えている、というケースもあります。dig NS の結果と、プラグインが操作している事業者が一致しているかを確認してください。

CNAME 委任を使っている場合

DNS の API を公開したくない場合に、_acme-challenge.example.com を、API で操作できる別のゾーンのホスト名へ CNAME で向ける方法があります。この CNAME が DNS の整理で消されると、それ以降の更新が失敗します。

dig +short CNAME _acme-challenge.example.com

原因4：CAA の issuewild で制限している

CAA レコードには、通常の証明書用の issue と、ワイルドカード用の issuewild があります。issuewild を置いていると、ワイルドカード証明書の発行可否はそちらで判断されます。issue には Let's Encrypt を入れたのに、issuewild に別の CA だけを書いている、という設定だとワイルドカードだけ発行できません。

dig +short CAA example.com
# 例: 0 issue "letsencrypt.org" / 0 issuewild "letsencrypt.org"

原因5：そもそもワイルドカードの対象外のホスト名

更新後に一部のホスト名だけ証明書エラーになる場合は、範囲の問題を疑います。ワイルドカード証明書がカバーするのは1階層のサブドメインだけです。

*.example.com は www.example.com や shop.example.com をカバーします。
頂点の example.com は含まれません。証明書に example.com を別に入れる必要があります。
dev.app.example.com のような2階層のサブドメインは含まれません。*.app.example.com を別に入れるか、個別の証明書を用意します。

商用 CA で更新している場合

商用 CA のワイルドカード証明書でも、ドメイン認証は DNS 認証かメール認証で行うのが一般的で、HTTP（ファイル）認証は使えないことが多いです。メール認証は admin@ などの決まったアドレスを受信できることが前提で、WHOIS に載った連絡先を使う方法は2025年に廃止されています。DNS 認証で指定される値やホスト名は CA ごとに違うため、管理画面の指示どおりに追加し、上記の dig で反映を確かめてから認証を依頼します。

なお、公開サーバー証明書の最長有効期間は段階的に短くなっており、2026年3月以降の発行分は最長200日程度です（2026年10月現在）。手作業の更新が年に複数回になるため、商用 CA でも ACME で自動化できるかを確認しておく価値があります。

更新後の確認

更新できたら、ワイルドカード証明書を使っているすべてのサーバーで Web サーバーを再読み込みし、代表的なホスト名で有効期限を確認します。Certbot の場合、自動更新後に再読み込みが走るよう --deploy-hook を設定しておくと、更新されたのに古い証明書を配信し続ける状態を防げます。

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

まとめ

ワイルドカード証明書は DNS 認証が前提で、更新失敗の多くは TXT レコードの自動書き換えができないことが原因です。
まず certbot renew --dry-run とログ、renewal 設定の authenticator を確認します。manual なら DNS プラグインに切り替えます。
API トークンの失効、TXT の反映待ちや追加先の誤り、CNAME 委任の消失、CAA の issuewild を順に確認します。
ワイルドカードは頂点ドメインと2階層以上のサブドメインを含みません。更新後はすべてのサーバーで再読み込みし、有効期限を確認します。