マルチドメインSSL（SAN証明書）のドメイン認証（DCV）は、証明書に含めるホスト名の一つひとつについて「メール」「DNS」「HTTP（ファイル）」のいずれかで管理権限を示す手続きです。すべてのホスト名の認証が完了するまで証明書は発行されないため、ホスト名ごとに通しやすい方法を先に決め、1件ずつ完了を確認していくのが近道です。この記事では、3つの認証方法の仕組みと手順、ホスト名の組み合わせに応じた選び方、認証が通らないときの確認方法を説明します。証明書の更新作業の全体の流れではなく、DCV の部分に絞った内容です。
DCV の3つの方法と向き・不向き
DCV の方法は CA/Browser フォーラムの基準で決められており、どの認証局（CA）でもおおむね次の3種類から選びます。画面上の名称や細かな手順は CA ごとに異なります。
メール認証
CA が決まった形式のアドレスに確認メールを送り、本文のリンクや承認コードで承認します。使えるアドレスは admin@、administrator@、webmaster@、hostmaster@、postmaster@ に、ドメイン名を付けたものです。shop.example.com の認証で admin@example.com を選べるなど、上位のドメインのアドレスを使えることもあります。
DNS や Web サーバーを触らずに済む反面、これらのアドレスを受信できる設定が必要です。なお、WHOIS に登録された連絡先メールアドレスを使う方法は、CA/Browser フォーラムの決定で2025年に廃止されています。以前の更新で WHOIS のアドレスを使っていた場合は、別の方法に切り替える必要があります。
DNS 認証
CA が指定する TXT レコード（CA によっては CNAME レコード）を DNS に追加します。上位のドメイン（example.com）で DNS 認証を済ませると、その配下のサブドメインもまとめて認証済みとして扱われることが多く、ホスト名が多い証明書では最も効率のよい方法です。Web サーバーの構成やリダイレクトの影響を受けない点も利点です。
HTTP（ファイル）認証
CA が指定する内容のファイルを、http://ホスト名/.well-known/pki-validation/ 配下に置きます（CA によっては https でも確認します）。DNS を操作できない場合に使えますが、認証されるのはそのホスト名だけで、サブドメインには広がりません。また、Web サーバーがまだ立っていないホスト名や、CDN・WAF の背後にあるホスト名では失敗しやすい方法です。
手順1：ホスト名ごとに方法を割り当てる
証明書に含めるホスト名を一覧にし、それぞれ「DNS を誰が操作できるか」「Web サーバーにファイルを置けるか」「決まった形式のメールを受け取れるか」を確認して、方法を割り当てます。
| ホスト名の例 | 状況 | 向いている方法 |
|---|---|---|
| example.com / www.example.com | DNS を自社で管理 | DNS 認証（example.com で1回） |
| shop.example.net | DNS は外部委託、サーバーは自社 | HTTP 認証 |
| campaign.example.org | DNS もサーバーも別部署 | メール認証（受信できるか事前確認） |
同じドメイン配下のホスト名は、上位のドメインを DNS 認証かメール認証で1回済ませれば足りることが多いため、まず「ドメイン単位」にまとめてから方法を決めると、作業の回数を減らせます。どの範囲が認証済みになるかは CA の管理画面で確認してください。
手順2：DNS 認証の進め方
CA の管理画面で、ホスト名ごとに追加すべきレコードの名前・種類・値が表示されます。値は注文や CSR ごとに異なり、CA によっては CSR から値を作るため、CSR を作り直すと値も変わります。表示された値を DNS に追加したら、反映を確認してから CA に認証を依頼します。
# 管理画面に表示されたレコード名に置き換えて確認
dig +short TXT example.com
dig +short TXT _dnsauth.example.com @8.8.8.8
# CNAME を指定された場合
dig +short CNAME _xxxxxxxx.example.comDNS をどの事業者で管理しているかは dig +short NS example.com で確認できます。レジストラの管理画面にレコードを追加したのに、実際のネームサーバーは別の事業者だった、という失敗はよくあります。認証が完了した後、TXT レコードは削除してかまわないことが一般的ですが、CNAME 方式で再認証にも使う CA もあるため、CA の案内に従います。
手順3：HTTP 認証の進め方
指定されたファイル名と内容のファイルを、ホスト名ごとに置きます。WordPress などが動いているサーバーでも、.well-known ディレクトリを作ってファイルを置けば、通常は静的ファイルとして返されます。
sudo mkdir -p /var/www/html/.well-known/pki-validation
sudo cp ABCDEF1234.txt /var/www/html/.well-known/pki-validation/
# 外部から取得できるか確認（ステータスと内容）
curl -i http://shop.example.net/.well-known/pki-validation/ABCDEF1234.txtcurl で HTTP 200 と指定どおりの内容が返れば準備完了です。次のような点でつまずきやすいので、あわせて確認します。
- リダイレクト: HTTP から HTTPS への転送や、
wwwの有無の統一で別のホスト名に飛ばしていると、CA によっては失敗します。.well-known/pki-validation/だけ転送の対象外にすると安定します。 - アクセス制限: WAF、Basic 認証、海外 IP の遮断があると CA の確認アクセスが届きません。CA は複数の地点からアクセスして確認する仕組みを導入しているため、国内からの
curlで取得できても失敗することがあります。 - ファイルの中身: 改行コードや余分な空白が入ると不一致になる場合があります。CA から渡されたファイルをそのまま置きます。
手順4：メール認証の進め方
申請時に、ホスト名ごとに使うアドレスを選びます。選択肢は前述の決まった形式のものに限られるため、申請前にそのアドレス宛てのテストメールを送り、受信できることを確かめておきます。存在しないアドレスへの送信は、受信側のメールサーバーで破棄されて気付けないことがあります。承認メールのリンクには期限があるため、届いたら早めに承認します。
手順5：全ホスト名の完了を確認してから次に進む
CA の管理画面で、ホスト名ごとの認証状態がすべて完了になっていることを確認します。1件でも保留のままなら発行されません。期限が迫っている場合は、保留になっているホスト名だけ別の方法に切り替えられないかを確認します。それでも間に合わないときは、そのホスト名を外して先に発行し、後から追加する（商品によっては再発行）という判断もあります。
認証が通らないときの確認順
- CAA レコード:
dig +short CAA example.comで、申請先の CA が許可されているかを確認します。サブドメインに個別の CAA がある場合はそちらが優先されます。 - DNS の管理先: レコードを追加した場所と、
dig NSで分かる実際のネームサーバーが一致しているか。 - 値の取り違え: 別の注文や作り直す前の CSR の値を使っていないか。
- HTTP 認証の到達性: リダイレクトやアクセス制限がないか、HTTP 200 で内容が返るか。
- メールの受信: 選んだアドレスが実在し、迷惑メール扱いになっていないか。
認証結果の再利用と今後の変化
一度済ませた DCV の結果は、一定期間内であれば次の発行で再利用されることがあります。ただし、CA/Browser フォーラムの決定でこの再利用期間と証明書の最長有効期間は段階的に短くなっており、2026年3月以降の発行分は証明書が最長200日程度です（2026年10月現在）。今後は更新のたびに DCV をやり直す前提で、DNS 認証を中心にした方法や、ACME による自動化を検討しておくと運用が楽になります。
まとめ
- マルチドメイン証明書は、含めるすべてのホスト名で DCV が完了するまで発行されません。
- DNS 認証は上位ドメインで1回済ませると配下にも広がることが多く、ホスト名が多いときに向きます。HTTP 認証はそのホスト名だけが対象です。
- HTTP 認証はリダイレクトとアクセス制限、DNS 認証は追加先のネームサーバー、メール認証は受信できるかが主なつまずきどころです。WHOIS の連絡先を使う方法はもう使えません。
- 通らないときは CAA、DNS の管理先、値の取り違え、到達性、メール受信の順に確認します。