DNS認証のTXTレコードを設定したのに証明書が発行されません

DNSの伝播に時間がかかる場合があります（数分〜数時間）。dig TXTコマンドやdnschecker.orgでレコードが世界中に伝播しているか確認してください。また、ホスト名や値のコピーミス、CAAレコードによるブロックも確認ポイントです。

ファイル認証のファイルを設置したのに認証が通りません

認証局がアクセスするURLを直接ブラウザで開き、ファイルの内容が正しく表示されるか確認してください。.well-known ディレクトリがアクセス禁止になっていないか、HTTPSへの転送先でも同じファイルが取得できるか、WAFがブロックしていないかも確認ポイントです。

メール認証の承認メールが届きません

宛先はadmin@、administrator@、hostmaster@、postmaster@、webmaster@（@以降はドメイン名）の標準5アドレス、またはDNSのTXTに公開した連絡先（デジサート _validation-contactemail／サイバートラスト「DNS認証（メール）」）です。迷惑メールフォルダの確認、送信元ドメインの許可リスト追加もお試しください。いずれも受信できない場合はDNS認証またはファイル認証への切り替えをお勧めします。

CNAMEリダイレクトでDCVを設定したのに通りません

CNAME型のDCV（_dnsauth.example.com のCNAMEを認証局指定FQDNに向ける方式）では、CNAMEのリダイレクト先のレコードが解決できる必要があります。CNAME設定後にdig CNAMEとdig TXTで「CNAMEターゲットのレコードが返ってくる」ことまで確認してください。

DNSの伝播はTTLどおりに完了しますか？

理論上はTTL秒で各リゾルバのキャッシュが切れますが、ISPのキャッシュやCDN経由ではTTL通りに更新されないケースがあります。複数の外部リゾルバ（Cloudflare 1.1.1.1, Google 8.8.8.8）で確認するのが確実です。次回DCVに備えて、開始の数日前にTTLを300秒程度へ短縮しておくのが定石です。

Cloudflare配下のドメインでファイル認証が通りません

多くはWAF・Bot対策が認証局のアクセスをブロックしています。「Always Use HTTPS」自体はhttpsへの転送で、転送先でファイルが取得できれば認証は通ります。WAFルールで /.well-known/pki-validation/* を除外し、Page Rule／Redirect Ruleでこのパスが書き換わっていないか確認してください。DNS認証への切り替えが最も確実な代替策です。

CAAレコードでSSL証明書の発行がブロックされていないか確認するには？

dig CAA example.com で確認できます。CAAレコードが設定されていて、発行先の認証局のドメインが含まれていない場合は発行できません。CAAレコードを修正するか、CAAレコードを削除してください。詳細は /ssl/faq/caa-record/ を参照してください。

DCVは更新時もスキップできませんか？

更新時も基本的に毎回DCVが必要です。CA・プランによっては一定期間の「DCV再利用」が可能な場合がありますが、必ず使えるとは限りません。47日化に向けてDCV再利用ポリシーはさらに厳しくなる見込みで、まず弊社API自動注文による自動化を推奨します（ACMEエンドポイントは現時点で未提供）。

☎ 048-837-7778

SSL証明書 > FAQ／情報 > DCV認証が通らないときのチェックリスト — DNS・ファイル・メール認証別の原因と対処

【SSL証明書】FAQ／情報

DCV認証が通らないときのチェックリスト — DNS・ファイル・メール認証別の原因と対処

ページ更新日：2026/10/10

30秒で分かる：DCVトラブル対処

確認①: 認証方法が正しく実装されているか（コピペミス・大文字小文字・ホスト名のドメイン重複）。
確認②: DNS伝播が完了しているか（dig／dnschecker.org で外部から確認）。
確認③: CAA レコードに発行先 CA が含まれているか。
原因：DNS: TTL長すぎ・伝播待ち・CAAブロック。
原因：ファイル: 転送先で認証ファイルが取れない・WAF/CDNブロック・.well-known不可。
原因：メール: 標準アドレス／DNS TXT 連絡先以外を指定・MX未設定・迷惑メール振り分け。
切り替えの判断: メール認証で詰まったらDNS／ファイル認証へ切替が現実的。
CNAME認証: CA・プランによっては DCV 再利用が効く。
緊急の選択肢: 同一 CSR で再申請、別の認証方式へ切替、ドメイン管理者へエスカレーション。
困ったら: 弊社サポートまでお問い合わせください。

SSL証明書の申し込み後、DCV（ドメイン所有権確認）がなかなか完了しないケースがあります。
認証方法（DNS認証・ファイル認証・メール認証）別に、よくある原因と確認ポイントをまとめました。
基本的なDCVの仕組みは DCV（ドメイン所有権確認）の方法をご参照ください。

▲ 確認から切替までの流れ（図はクリックで拡大表示できます）

DNS認証が通らないときの確認ポイント

1. DNSレコードの値・タイプが正しいか確認する

認証局から提供された値を正確にコピーしているか確認してください。スペースや改行が混入することがあります。
TXTレコードとCNAMEレコードで指定方法が異なります。どちらを使うべきかも確認してください。

ホスト名（名前）が正しいか確認する（例：_dnsauth を入力すべきところを _dnsauth.example.com とドメイン名ごと入力してしまうケース）
値（バリュー）のコピーミスがないか確認する
レコードタイプ（TXT / CNAME）が正しいか確認する

2. DNSの伝播（プロパゲーション）を待つ

DNSレコードの変更は世界中に伝播するまで時間がかかります（通常は数分〜数時間、TTLによっては最大24〜48時間）。
dig コマンドまたはオンラインツール（dnschecker.org など）でレコードが正しく伝播しているか確認してください。

dig TXT _dnsauth.example.com

3. CAAレコードを確認する

ドメインのCAAレコードに申し込んだ認証局が含まれていない場合、証明書は発行されません。
CAAレコードの確認方法を参考に確認してください。

4. ワイルドカード証明書はファイル認証が使えない（DNS認証またはメール認証）

ワイルドカード証明書（*.example.com）はファイル認証が使用できません。弊社デジサート（RapidSSL・QuickSSL Premium・スタンダード・サーバID・トゥルービジネスID 等）では DNS認証またはメール認証 をご利用ください。自動更新を行う場合はDNS認証が最適です。

5. CNAMEリダイレクト先のDNS設定を見落としている

認証局によっては DCV 値を _dnsauth.example.com の CNAME として「認証局指定の対象FQDN」に向ける方式（CNAME型 DCV）を提供しています。この場合、CNAMEのターゲットに認証局が用意したレコードが必要です。CNAMEを設定して終わりではなく、CNAMEリダイレクト先のレコードが解決できることまで確認してください。

6. TTL が長すぎて変更が伝播していない

既存のレコードが長いTTL（例：86400秒＝24時間）で公開されていると、変更後もキャッシュが残ります。次回の DCV を見越して、DCV 開始の数日前に TTL を300秒程度に短縮しておくのが定石です。

7. ネガティブキャッシュ（NXDOMAIN キャッシュ）が残っている

過去に存在しなかったレコード（_dnsauth.example.com）の NXDOMAIN 結果が DNS リゾルバ側にキャッシュされる場合があります。SOA レコードの minimum（ネガティブキャッシュTTL）を超えるまで待つ、または別リゾルバ（1.1.1.1 / 8.8.8.8）で再確認してください。

ファイル認証が通らないときの確認ポイント

1. ファイルのURL・内容を確認する

認証局がアクセスするURLは http://www.example.com/.well-known/pki-validation/[ファイル名] です。
実際にそのURLをブラウザで開いて、ファイルの内容（認証局から指定された文字列）が表示されるか確認してください。

ファイル名を正確に設定しているか確認する（大文字・小文字の違いに注意）
ファイルの内容が正しいか確認する（余分な改行・スペースが入っていないか）
Content-Type の制限がある場合、text/plain として返される必要があります

2. .well-known ディレクトリへのアクセスが許可されているか確認する

Webサーバーの設定によって .well-known ディレクトリがアクセス禁止になっている場合があります。
よくあるのは、.htaccess や .git などのドットで始まるパスを一律に拒否する RewriteRule・RedirectMatch・Require all denied が .well-known にも当たっているケースです。

# .htaccess の場合：ドットで始まるパスを拒否するルールより前に、.well-known を除外する
RewriteEngine On
RewriteRule ^\.well-known/ - [L]
# （この下に既存の RewriteRule "^\." - [F] などの拒否ルール）

# httpd.conf / VirtualHost の場合：実際のファイルシステム上のパスで許可する
<Directory "/var/www/html/.well-known">
    Require all granted
</Directory>

※ <Directory> は .htaccess には記述できません（記述すると 500 エラーになります）。パスは DocumentRoot 配下の実パスに置き換えてください。

3. 転送先で認証ファイルが取得できるか確認する

認証局は http:// でアクセスし、301・302・307 の転送には追従します。http:// → https:// の転送があっても、転送先で同じパスの認証ファイルが取得できれば問題ありません（HTTPS 強制を外す必要はありません）。
失敗するのは、認証局の許容条件（認証対象のドメインから始まり、同じベースドメイン内で http/https の標準ポートへ、など）を満たさない転送や、転送先がトップページやログイン画面になってファイルの内容が返らない場合です。転送を追って最終応答を確認してください。

curl -L -i http://www.example.com/.well-known/pki-validation/[ファイル名]
# 最終応答が 200 で、本文が認証局から指定された文字列になっていれば OK

4. 認証局のIPアドレスをファイアウォールで拒否していないか

WAF・ファイアウォール・Cloudflareなどがボットアクセスをブロックしている場合、認証局からのアクセスが拒否されることがあります。
一時的にアクセス制限を緩和するか、認証局のIPアドレスを許可リストに追加してください。

メール認証の承認メールが届かないときの確認ポイント

1. 受信できるメールアドレスか確認する

メール認証の宛先は、認証局の標準5アドレス、または DNS の TXT レコードに公開した連絡先です。

admin@example.com
administrator@example.com
hostmaster@example.com
postmaster@example.com
webmaster@example.com
DNS TXT に公開した連絡先：デジサートは _validation-contactemail.example.com、サイバートラストは「DNS認証（メール）」（いずれも注文フォームで選択できます）

上記以外（任意の個人アドレスなど）には送れません。受信できる環境を準備するか、DNS認証・ファイル認証に切り替えてください。

2. 迷惑メールフォルダを確認する

認証局からのメールが迷惑メールフォルダに振り分けられている場合があります。
送信元ドメイン（DigiCertの場合 @digicert.com または @rapidssl.com など）を許可リストに追加してください。

3. メールサーバーのMXレコードを確認する

ドメインのMXレコードが正しく設定されていないと、メールが届きません。

dig MX example.com

4. WHOIS 連絡先宛のメール認証は廃止済み

WHOIS に登録されたメールアドレス宛の DCV は、デジサートで 2025年5月、CA/Browser Forum 全体でも 2025年7月に廃止されました。WHOIS の公開・非公開はメール認証に影響しません。宛先は上記の標準アドレスか DNS TXT に公開した連絡先です。

5. admin@ などを受信できない場合

標準アドレスのメールボックスを用意できないときは、DNS の TXT に公開した連絡先宛（デジサート _validation-contactemail／サイバートラスト「DNS認証（メール）」）を選ぶか、DNS認証・ファイル認証へ切り替えてください。

よくある誤解

❌ DCVは1回成功すれば、次回更新でもスキップされる: ✅ 更新時も毎回 DCV が必要です（CA・プランによっては一定期間の DCV 再利用が可能ですが、必ずしも使えるとは限りません）。47日化以降は再利用ポリシーがさらに厳しくなる見込み。
❌ DNS伝播はTTL分待てば必ず完了する: ✅ ISPのキャッシュリゾルバや CDN 経由の場合、TTLどおりに更新されないケースがあります。複数の外部リゾルバ（Cloudflare 1.1.1.1, Google 8.8.8.8）で確認するのが確実。
❌ HTTPS へ強制リダイレクトしているとファイル認証は失敗する: ✅ 認証局は HTTP（80）でアクセスしますが、301・302・307 の転送には追従します。転送先の https:// で同じパスの認証ファイルが取得できれば通ります。失敗するのは、認証局の許容条件（同じベースドメイン内など）を満たさない転送や、転送先で認証ファイルを取得できない場合です。
❌ Cloudflare の「Always Use HTTPS」を有効にしているとファイル認証は動かない: ✅ 「Always Use HTTPS」は https へ転送するだけなので、転送先でファイルが取得できれば動きます。止まるのは WAF・Bot 対策がブロックする場合や、Page Rule／Redirect Rule で .well-known/pki-validation/* のパスが書き換わる場合です。

よくある質問

Q. DNS認証のTXTレコードを設定したのに証明書が発行されません: A. DNSの伝播に時間がかかる場合があります（数分〜数時間）。dig TXT コマンドや dnschecker.org でレコードが世界中に伝播しているか確認してください。また、ホスト名や値のコピーミス、CAAレコードによるブロックも確認ポイントです。
Q. ファイル認証のファイルを設置したのに認証が通りません: A. 認証局がアクセスするURLを直接ブラウザで開き、ファイルの内容が正しく表示されるか確認してください。.well-known ディレクトリがアクセス禁止になっていないか、HTTPS への転送先でも同じファイルが取得できるか、WAFがブロックしていないかも確認ポイントです。
Q. メール認証の承認メールが届きません: A. 宛先は admin@、administrator@、hostmaster@、postmaster@、webmaster@（@以降はドメイン名）の標準5アドレス、または DNS の TXT に公開した連絡先（デジサート _validation-contactemail／サイバートラスト「DNS認証（メール）」）です。迷惑メールフォルダの確認、送信元ドメインの許可リスト追加もお試しください。いずれも受信できない場合はDNS認証またはファイル認証への切り替えをお勧めします。
Q. CNAMEリダイレクトでDCVを設定したのに通りません: A. CNAME型のDCV（_dnsauth.example.com のCNAMEを認証局指定FQDNに向ける方式）では、CNAMEのリダイレクト先のレコードが解決できる必要があります。CNAME設定後に dig CNAME と dig TXT で「CNAMEターゲットのレコードが返ってくる」ことまで確認してください。
Q. DNSの伝播はTTLどおりに完了しますか？: A. 理論上はTTL秒で各リゾルバのキャッシュが切れますが、ISPのキャッシュやCDN経由ではTTL通りに更新されないケースがあります。複数の外部リゾルバ（Cloudflare 1.1.1.1, Google 8.8.8.8）で確認するのが確実です。次回DCVに備えて、開始の数日前にTTLを300秒程度へ短縮しておくのが定石です。
Q. Cloudflare配下のドメインでファイル認証が通りません: A. 多くは WAF・Bot 対策が認証局のアクセスをブロックしています。「Always Use HTTPS」自体は https への転送で、転送先でファイルが取得できれば認証は通ります。WAF ルールで /.well-known/pki-validation/* を除外し、Page Rule／Redirect Rule でこのパスが書き換わっていないか確認してください。DNS認証への切り替えが最も確実な代替策です。
Q. CAAレコードでSSL証明書の発行がブロックされていないか確認するには？: A. dig CAA example.com で確認できます。CAAレコードが設定されていて、発行先の認証局のドメインが含まれていない場合は発行できません。CAAレコードを修正するか、CAAレコードを削除してください。詳細は CAAレコード解説を参照してください。
Q. DCVは更新時もスキップできませんか？: A. 更新時も基本的に毎回DCVが必要です。CA・プランによっては一定期間の「DCV再利用」が可能な場合がありますが、必ず使えるとは限りません。47日化に向けてDCV再利用ポリシーはさらに厳しくなる見込みで、まず弊社API自動注文による自動化を推奨します（ACME は弊社では現時点で未提供）。