EV SSL証明書の発行には、組織の実在確認とは別に、申請者がそのドメインを管理していることを示すDCV（Domain Control Validation、ドメイン認証）が必要です。DCVの確認は、選んだ方式（メール・DNSレコード・Webサーバー上のファイル）ごとに「認証局が見に来る場所に、指定どおりの値があるか」をコマンドで確かめるのが近道です。この記事では、EV審査の中でDCVが占める位置、方式別の確認方法、通らないときの原因と直し方、発行後にEV証明書かどうかを確認する方法を説明します。
EV SSLの審査とDCVの関係
EV（Extended Validation）証明書の審査は、大きく2つに分かれます。
- 組織の確認: 法人の登記、所在地、事業の実態、申請者の権限などを認証局が確認する。書類の提出や電話での確認が行われる
- DCV: 証明書に載せるドメインを申請者が管理していることを確認する。DV証明書やOV証明書と同じ仕組み
EVだからといってDCVが省略されることはありません。発行が止まっているときは、まず認証局の管理画面や通知で、止まっているのが組織の確認なのかDCVなのかを確認します。組織側の書類待ちであれば、サーバーをいくら調べても進みません。
なお、EV証明書はワイルドカード（*.example.com）では発行できません。複数のホスト名を載せたい場合は、SAN（サブジェクト代替名）に個別に列挙し、それぞれにDCVが必要になります。
DCVの方式と選び方
方式は業界の基準（CA/Browser Forumのベースライン要件）で定められており、認証局はその中から選べる方式を提供しています。主に使われるのは次の3つです。
- メール認証: 認証局が送るメールのリンクを開くか、記載のコードを入力する。宛先は
admin@、administrator@、webmaster@、hostmaster@、postmaster@のような決められたアドレスから選ぶ形が一般的です。WHOISに載ったメールアドレスを使う方式は、廃止に向けた見直しが進んでいます - DNS認証: 認証局が指定するTXTレコード、またはCNAMEレコードをDNSに追加する
- ファイル認証（HTTP認証）: 認証局が指定するファイルを
/.well-known/pki-validation/に置く
サーバーを触れる人とDNSを触れる人が別、というのは企業サイトでよくあることなので、作業できる担当者に合わせて方式を選びます。複数のホスト名や定期的な再認証を考えると、DNS認証が扱いやすい場面が多いです。
方式別の確認方法
DNS認証
追加したレコードが、外部から見える状態になっているかを確認します。キャッシュの影響を避けるため、自分のDNSサーバー（権威DNS）に直接問い合わせます。
# 権威DNSサーバーを調べる
dig +short NS example.com
# 権威DNSに直接問い合わせる（ホスト名と値は認証局の指示どおりに）
dig @ns1.example-dns.com +short TXT example.com
dig @ns1.example-dns.com +short CNAME _token.example.com
# 一般的なリゾルバからも見えるか
dig @1.1.1.1 +short TXT example.comよくある間違いは、管理画面の「ホスト名」欄にドメイン名を重ねて入力し、_token.example.com.example.com になってしまうケースです。また、TXTの値の前後に空白や改行が入っていたり、引用符を二重に付けていたりすると一致しません。DNSのホスティングを別のサービスに移していて、レジストラ側の画面にレコードを追加している（実際には使われていないDNSに書いている）こともあります。dig +short NS の結果と、レコードを追加した画面が同じサービスかを確認してください。
ファイル認証
認証局が取りに来るURLを、外部から開けるかを確認します。
curl -i http://example.com/.well-known/pki-validation/your-file-name.txtステータスが200で、本文が指定どおりの内容であれば正常です。WordPressのサイトでは次の原因で失敗しがちです。
- Webサーバーがドットで始まるパスを拒否している: Nginxで
location ~ /\. { deny all; }のような設定があると、/.well-known/も拒否されます。下の例のように^~を付けた/.well-known/用のlocationを追加すると、正規表現のlocationより優先され、このパスだけを許可できます - WordPressの404ページが返る: ファイルの置き場所がドキュメントルートと違う。WordPressを
/wp/のようなサブディレクトリに置いている場合は特に注意します - セキュリティプラグインやWAF、国外アクセスの制限: 認証局は複数の拠点から確認する仕組みを導入しているため、海外からのアクセスを止めているとDCVが失敗することがあります
- リダイレクト: HTTPからHTTPSへのリダイレクトや別ホストへの転送をどこまで許容するかは、方式と認証局によって異なります
location ^~ /.well-known/ {
allow all;
}メール認証
宛先のアドレスで実際にメールを受け取れるかが問題です。
# メールを受け取るサーバー（MX）があるか
dig +short MX example.comadmin@ などの決められたアドレスが存在しない、転送設定が無い、迷惑メールとして隔離されている、といった理由で届かないことがあります。社内のメールシステムで外部からの自動送信メールを止めていないかも、情報システム部門に確認します。
DCVが通らないときの原因（多い順）
- 値やホスト名の入力ミス: 認証局の画面に表示された値と、
digやcurlの結果を1文字ずつ照合します - 反映待ち: DNSのTTLや、認証局側の再チェックの間隔によって、追加してすぐには通らないことがあります。管理画面に「再確認」の操作があれば使います
- 実際に使われていない場所に設定している: DNSの権威サーバーや、ドキュメントルートの取り違えです
- CAAレコードで認証局が許可されていない: CAAを設定している場合、申請先の認証局が
issueに含まれていないと発行できません
dig +short CAA example.com- アクセス制限: ファイル認証で、WAFや国別の制限、メンテナンスモードのプラグインが認証局のアクセスを止めています
発行後にEV証明書かどうかを確認する
現在の主要ブラウザは、アドレスバーに組織名を表示しなくなっています（2026年10月現在）。EVかどうかは、証明書の中身で確認します。
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -ext certificatePoliciesポリシーに 2.23.140.1.1 が含まれていればEV証明書です（OVは 2.23.140.1.2.2、DVは 2.23.140.1.2.1）。subjectには組織名に加え、法人の登録番号や設立国などの項目が入ります。古いOpenSSLで -ext が使えない場合は -text で全体を表示し、Certificate Policiesの部分を見ます。
再認証に備える
DCVの結果を再利用できる期間と、証明書の有効期間は、業界の基準で2026年から段階的に短縮されています。これまでより頻繁にDCVをやり直すことになるため、一度通した方式の手順を記録しておき、DNS認証のレコードは認証局の指示に従って管理します。証明書の期限は認証局からの通知だけに頼らず、openssl での定期確認や監視サービスでも把握しておくと安心です。
まとめ
- EV審査は「組織の確認」と「DCV」の2本立てで、DCVはDV・OVと同じ仕組み
- 発行が止まったら、止まっているのが組織側かDCV側かを最初に確認する
- DNS認証は権威DNSへの
dig、ファイル認証は外部からのcurl、メール認証はMXと受信設定で確かめる - 失敗の原因は入力ミス・反映待ち・設定場所の取り違え・CAA・アクセス制限の順に多い
- 発行後はCertificate PoliciesのOIDでEVかどうかを確認できる