Sectigo の証明書を申請すると、発行前にドメインの管理権限を示すDCV（Domain Control Validation）が求められます。方法は主にメール・HTTPファイル設置・DNS CNAME の3つで、Webサーバーの設定に左右されにくいDNS CNAME方式が、多くの場合もっとも安定します。この記事では、各方式の手順と、認証が通らないときに確認すべき点を、起こりやすい順に解説します。
Sectigo の証明書は販売代理店（リセラー）経由で購入することが多く、申請画面の見た目や項目名は代理店ごとに異なります。ここでは仕組みと確認方法を中心に説明するので、画面の表記は利用中の代理店の案内に読み替えてください。
DCVの3つの方式と選び方
メール認証
Sectigo が指定するアドレス宛てに承認メールが届き、本文のリンクから承認する方式です。宛先は admin@、administrator@、hostmaster@、postmaster@、webmaster@ にドメインを付けた定型アドレスから選ぶのが一般的です。以前は WHOIS に登録されたアドレスも使えましたが、業界ルールの変更で WHOIS 経由のアドレスは使えなくなっています（2026年10月現在）。
手軽に見えますが、そのメールボックスが実在しないと承認できません。メールを別サービスで運用している場合は、事前に受信できるか確かめておきます。
HTTPファイル認証
指定された名前のテキストファイルを、Webサーバーの /.well-known/pki-validation/ の下に置く方式です。Sectigo のファイル名と中身はCSRから計算されたハッシュ値をもとに作られるため、CSRを作り直すとファイル名も中身も変わります。再申請時に古いファイルを置いたままにして失敗する例がよくあります。
制約として、ワイルドカード証明書（*.example.com）にはこの方式を使えません。また、Webサーバーがまだ用意できていない段階では使えません。
DNS CNAME認証
指定されたホスト名に CNAME レコードを追加する方式です。ホスト名は _ で始まるハッシュ値、値は sectigo.com で終わる長い文字列という形になるのが一般的です。Webサーバーが無くても使え、ワイルドカード証明書にも対応します。DNSを自分で編集できるならこの方式を選ぶと、Webサーバー側の設定やセキュリティ製品の影響を受けません。
手順1: CSRを作り、申請時に方式を選ぶ
openssl req -new -newkey rsa:2048 -nodes \
-keyout example.com.key -out example.com.csr \
-subj "/CN=example.com"
chmod 600 example.com.key代理店の申請画面でCSRを貼り付けると、DCV方式の選択画面が表示されるのが一般的です。選んだ方式に応じて、承認メールの宛先、ファイル名と中身、CNAMEのホスト名と値のいずれかが表示されます。表示された値は手で打ち直さず、コピーして使ってください。1文字違うだけで認証は通りません。
手順2: 方式ごとの設置と確認
HTTPファイルの場合
ファイルを置いたら、外部から取得できるかを確認します。
curl -i http://example.com/.well-known/pki-validation/XXXXXXXX.txt確認するのは次の3点です。
- ステータスが 200 であること。404 なら置き場所、403 ならアクセス制限を疑います。
- 中身が指定どおりで、余分な空白やBOM（文字コードの先頭記号）が無いこと。Windows のメモ帳で作ると改行コードや文字コードが変わることがあります。
- 別ドメインへのリダイレクトが起きていないこと。HTTPからHTTPSへの同一ドメイン内のリダイレクトは通常問題になりませんが、www の有無で別ホストへ飛ばす設定や、ログインページへの転送があると失敗する場合があります。
DNS CNAMEの場合
レコード追加後、権威DNSサーバーに反映されているかを確認します。
dig +short CNAME _xxxxxxxx.example.com
dig +short CNAME _xxxxxxxx.example.com @8.8.8.8値が返らなければ、ホスト名の入力ミスを疑います。DNS管理画面によっては、ホスト欄にドメイン名を含めると _xxxxxxxx.example.com.example.com のように二重になります。ホスト欄にはドメインより前の部分だけを入れる画面が多いので、入力後の表示を確認してください。
メールの場合
承認メールが届かないときは、迷惑メールフォルダ、受信サーバーの拒否設定、そのアドレスが実在するかを順に確認します。再送は代理店の管理画面から依頼できることが一般的です。
認証が通らないときの確認（起こりやすい順）
1. CSRを作り直したのに古い値を使っている
HTTPファイル・DNS CNAME ともに、値はCSRに依存します。申請をやり直した場合は、最新の申請画面に表示されている値と、設置済みの値を突き合わせてください。
2. WordPress やWebサーバーの設定がファイルを返していない
WordPress の標準の .htaccess は、実在するファイルにはそのままアクセスさせる書き方なので、通常は問題ありません。問題になりやすいのは次のような設定です。
- Nginx で「ドットで始まるパスをすべて拒否する」設定があり、
/.well-known/まで拒否している。 - セキュリティプラグインやWAFが、見慣れないパスへのアクセスをブロックしている。
- サイト全体にBasic認証をかけている（ステージング環境で起きやすい）。
Nginx でドットファイルを拒否している場合は、.well-known だけを先に許可します。
location ^~ /.well-known/pki-validation/ {
allow all;
default_type text/plain;
}
location ~ /\. {
deny all;
}^~ を付けた前方一致は正規表現の location より優先されるため、この順番で拒否設定と共存できます。変更後は nginx -t で構文を確かめてから再読み込みしてください。
3. CAAレコードで Sectigo が許可されていない
ドメインに CAA レコードがある場合、そこに記載された認証局しか証明書を発行できません。
dig +short CAA example.com何も返らなければ制限はありません。レコードがあるのに sectigo.com が含まれていなければ、0 issue "sectigo.com" を追加します。ワイルドカード証明書では issuewild の指定も確認します。
4. DNSの反映待ち・キャッシュ
DNSの変更直後は、認証局側のリゾルバーに古い情報が残っていることがあります。権威DNSサーバーに直接問い合わせて正しい値が返るなら、少し時間を置いてから代理店の画面で再チェックを依頼します。
5. CDNやプロキシが間に入っている
Cloudflare などのプロキシ経由で配信していると、ボット対策機能がDCVの取得をブロックすることがあります。その場合はDNS CNAME方式に切り替えるのが近道です。
発行後に行うこと
証明書が発行されたら、中間証明書と一緒にサーバーへ設置し、openssl s_client -connect example.com:443 -servername example.com で新しい証明書が返ることを確認します。
設置したDCV用のファイルは、発行後に削除してかまいません。CNAMEレコードも削除できますが、認証の再利用期間内の再発行や更新で同じ値を使う運用をしている代理店もあるため、案内を確認してから判断してください。なお、業界ルールの変更でドメイン認証結果を再利用できる期間は段階的に短くなる予定で、更新のたびにDCVが求められる前提で考えておくのが現実的です（2026年10月現在）。
まとめ
- DCVはメール・HTTPファイル・DNS CNAMEの3方式。DNSを編集できるならCNAME方式が安定しやすい。
- HTTPファイルとCNAMEの値はCSRから作られるため、CSRを作り直したら値も作り直す。
- ファイル方式で失敗したら、curl でステータス・中身・リダイレクトを確認し、Nginx のドットファイル拒否やセキュリティ製品を疑う。
- CAAレコードがある場合は
sectigo.comが許可されているか確認する。 - 値はコピーして使い、権威DNSやcurlで外から見えることを確かめてから再チェックを依頼する。