ドメイン認証SSLのDCV手順：メール認証・DNS認証・ファイル認証のやり方と選び方

SSL証明書のドメイン認証（DCV）は、認証局が指定した「値」を、メール・DNSレコード・Webサーバー上のファイルのいずれかで示し、そのドメインを管理していることを証明する手続きです。DNSを操作できるならDNS認証、Webサーバーにファイルを置けるならファイル認証が、待ち時間が短く失敗の原因も追いやすい方式です。この記事では、3つの方式の違いと選び方、それぞれの具体的な手順、認証が通らないときの確認ポイントを説明します。

DCVはドメイン認証（DV）証明書だけでなく、組織認証（OV）やEV証明書でも必要な工程です。ここで説明する手順は証明書の種類を問わず使えます。

ドメイン認証（DCV）とは

認証局は証明書を発行する前に、申請者がそのドメインを実際に管理しているかを確認します。この確認がDCV（Domain Control Validation）です。具体的な方式は、認証局とブラウザ事業者でつくるCA/ブラウザフォーラムの基準で決められており、各認証局はその範囲で方式を提供しています。

近年はこの基準の見直しが続いています。主な変化は次のとおりです（2026年10月現在）。

• WHOISに登録された連絡先メールアドレスを使う認証は、2025年に使えなくなりました。
• 認証局は複数の地点のネットワークから確認を行う方式（マルチパースペクティブ検証）を採るようになりました。
• 一度済ませた認証結果を使い回せる期間は、2026年3月から段階的に短縮されています。

最後の点により、証明書を更新するたびにDCVをやり直す場面が増えています。どの方式を選ぶかは、一度きりではなく「毎回この作業をする」前提で考えるのが現実的です。

3つの方式の違いと選び方

ワイルドカード証明書（*.example.com）では、ファイル認証は使えません。複数のサーバーにまたがる構成や、まだサイトを公開していないドメインでは、DNS認証が扱いやすい方式です。メール認証は手軽ですが、承認メールの受け口を用意する手間があり、今後も方式の見直しが議論されている分野なので、長く使う運用にはDNS認証かファイル認証を勧めます。

DNS認証の手順

1. 認証局や販売代理店の注文画面で「DNS」の方式を選び、登録するレコードの種類（TXTやCNAME）、名前、値を控えます。
2. ドメインのDNSを管理しているサービス（レジストラ、DNSサービス、レンタルサーバーなど）の管理画面で、そのレコードを追加します。
3. 権威DNSサーバーに直接問い合わせ、値が見えることを確認してから、注文画面で認証を実行します。

# どのDNSサーバーがこのドメインを管理しているか
dig NS example.com +short

# 権威DNSサーバーに直接、指定された名前のTXTを問い合わせる
dig TXT （指定されたレコード名） @（上で表示されたネームサーバー） +short

つまずきやすいのは、レコード名の入力です。多くの管理画面はホスト名の欄にドメイン名を自動で付け足すため、_example-token.example.com と全部入力すると _example-token.example.com.example.com になってしまうことがあります。上の dig で、指定どおりの名前で値が返るかを確かめれば判別できます。

ネームサーバーの切り替え直後は、古いDNSサービスにレコードを登録してしまう誤りもよくあります。dig NS の結果に表示されたサービスで作業しているかを確認してください。DNSSECを有効にしている場合、署名の設定に誤りがあると認証局側で名前解決が失敗するため、DNSSECの状態も併せて確認します。

Let's Encrypt などのACMEでは、_acme-challenge.example.com にTXTレコードを置くDNS-01という方式が使われます。DNSサービスがAPIを提供していれば、この登録を自動化できます。

ファイル認証の手順

1. 注文画面で「ファイル」や「HTTP」の方式を選び、指定されたファイル名と、ファイルに書く内容を控えます。
2. ドメインのドキュメントルートに .well-known/pki-validation/ ディレクトリを作り、指定どおりのファイルを置きます。内容は改行や空白を加えず、指定された文字列のとおりにします。
3. 外部からファイルを取得できることを確認してから、認証を実行します。

curl -i http://example.com/.well-known/pki-validation/（指定されたファイル名）

HTTP/1.1 200 OK が返り、本文が指定の内容と一致していれば準備完了です。確認は、サーバー内部からではなく外部のネットワークから行います。

つまずきやすいのは次の点です。

• 置く場所の間違い: WordPressをサブディレクトリにインストールし、サイトをドメイン直下で表示している構成では、WordPressのディレクトリではなくドメインのドキュメントルートに置きます。
• ドットで始まるディレクトリの拒否: nginx の設定でドットファイルへのアクセスを一律に拒否していると、.well-known も403になります。認証用のパスだけ許可する設定が必要です。
• アクセス制限: Basic認証、国別のアクセス制限、特定IPだけを許可するファイアウォールがあると、認証局の確認が届きません。認証局は複数の地点から確認するため、国内だけ許可する設定でも失敗します。
• リダイレクト: 別のホストへのリダイレクトがあると失敗することがあります。認証局が許容するリダイレクトの条件は限られているため、認証用のパスはリダイレクトしないのが無難です。

メール認証の手順

メール認証では、認証局が決められたアドレスに承認メールを送り、本文のリンクやコードで承認します。使えるアドレスは、ドメインに admin、administrator、webmaster、hostmaster、postmaster を付けたものが一般的です（選べる宛先は認証局の画面で確認してください）。

1. 申請前に、選ぶアドレスでメールを受け取れることを確かめます。メールボックスがなければ、普段使っているアドレスへの転送を設定します。
2. 注文画面で宛先を選び、承認メールを送ってもらいます。
3. 届いたメールのリンクから承認します。リンクには有効期限があるため、届いたら早めに処理します。

ドメインにMXレコードがない、または受信サーバーがそのアドレスを受け付けないと、メールは届きません。迷惑メールフィルターに振り分けられることもあるため、届かないときはまずそこを確認します。

認証が終わった後の後片付け

証明書が発行されたら、認証用に置いたファイルやTXTレコードは、認証局から残すよう指示がない限り削除して構いません。値は申請ごとに変わることが多く、残しておいても次回には使えないためです。一方、自動更新のためにCNAMEで委任している構成では、そのレコードを消すと次回の更新が止まります。何のために置いたレコードかを記録しておくと、後で判断に迷いません。

作業でDNSやWebサーバーの設定を変える場合は、事前に現在の設定を控えておき、問題があれば戻せるようにしてください。

まとめ

• DCVは、認証局が指定した値をメール・DNS・ファイルのいずれかで示し、ドメインの管理権限を証明する手続きです。OVやEVの証明書でも必要です。
• 認証結果の再利用期間が短くなっているため、毎回の作業になる前提で、DNS認証かファイル認証を選ぶのが現実的です。ワイルドカードではファイル認証は使えません。
• DNS認証は権威DNSサーバーへの dig、ファイル認証は外部からの curl で、認証を実行する前に値が見えることを確かめます。
• 国別制限やIP制限は、複数地点から確認する認証局の通信を遮断することがあります。

• digコマンドでDNSの設定を調べる方法
• CAAレコードでSSL証明書を発行できる認証局を制限する方法