ワイルドカードSSL（*.example.com）のドメイン認証（DCV）は、基本的に DNS レコードを追加する方法で行います。サーバーにファイルを置く HTTP 認証はワイルドカードには使えないため、通常の証明書と同じ感覚で進めるとここでつまずきます。この記事では、認証方式の選び方、Let's Encrypt と有償認証局それぞれの手順、認証が通らないときの確認方法を順に説明します。
DCV とは何か、なぜワイルドカードは DNS 認証になるのか
DCV（Domain Control Validation）は、証明書を申請した人がそのドメインを実際に管理しているかを認証局が確かめる手続きです。方式は大きく次の3つです。
- DNS 認証: 認証局が指定する TXT または CNAME レコードを DNS に追加する
- HTTP（ファイル）認証: 指定されたファイルを
/.well-known/以下に置き、認証局が取りに来る - メール認証:
admin@やwebmaster@など決められた宛先に届く承認メールのリンクを踏む
認証局の業界ルール（CA/Browser Forum の Baseline Requirements）では、HTTP 認証はワイルドカードの検証に使えないことになっています。/.well-known/ にファイルを置けるのは特定のホスト名だけで、配下のサブドメインすべてを管理している証明にはならないためです。結果として、ワイルドカードでは DNS 認証が第一の選択肢になります。有償の認証局では、ベースドメイン宛てのメール認証を選べる場合もありますが、メールを使う方式はルール改定で段階的に縮小される流れにあるため、新規に組むなら DNS 認証に寄せておくのが無難です（2026年10月現在）。最新の扱いは各認証局の案内を確認してください。
申請前に確認しておくこと
証明書に入れる名前
*.example.com は www.example.com や shop.example.com には一致しますが、ベースドメインの example.com 自体と、a.b.example.com のような2階層下の名前には一致しません。ベースドメインも使うなら、SAN に example.com を一緒に入れて申請します。多くの有償ワイルドカード証明書はベースドメインを含めて発行されますが、商品によって違うため申請画面で確かめてください。
DNS を実際に管理している場所
TXT レコードを追加する先は、ドメインのネームサーバーとして指定されている DNS です。レジストラの DNS ではなく Cloudflare やレンタルサーバーの DNS を使っている場合、レジストラ側に追加しても反映されません。
dig NS example.com +shortここに表示されたネームサーバーを管理している画面でレコードを追加します。
CAA レコード
ドメインに CAA レコードを設定している場合、ワイルドカード証明書には issuewild タグが使われます。issuewild があると、ワイルドカードの発行可否は issue ではなく issuewild の内容で判断されます。申請する認証局が許可されているかを先に見ておきます。
dig CAA example.com +shortLet’s Encrypt でワイルドカード証明書を取る（DNS-01）
Let's Encrypt では、ワイルドカード証明書は DNS-01 チャレンジでのみ取得できます。certbot を手動モードで使う場合は次のようになります。
sudo certbot certonly --manual --preferred-challenges dns \
-d example.com -d '*.example.com'実行すると、_acme-challenge.example.com に設定する TXT の値が表示されます。example.com と *.example.com を同時に申請すると、同じ名前に2つの TXT 値を追加するよう求められることがあります。この場合は1つを上書きせず、2つのレコードを並べて登録します。
レコードを追加したら、Enter を押す前に外部から見えているかを確認します。
dig TXT _acme-challenge.example.com +short @8.8.8.8
dig TXT _acme-challenge.example.com +short @1.1.1.1手動モードで取った証明書は、そのままでは自動更新できません。更新のたびに TXT の値が変わるからです。運用に乗せるなら、使っている DNS サービスに対応した certbot の DNS プラグイン（例: Cloudflare 用の certbot-dns-cloudflare）や、API で TXT を書き換えられる ACME クライアント（acme.sh など）を使い、更新まで自動化します。DNS の API トークンはゾーン編集の権限だけに絞り、ファイルの権限を 600 にしておくと、漏れたときの影響を抑えられます。
DNS の API を使えないサービスの場合は、_acme-challenge の名前だけを API に対応した別ゾーンへ CNAME で委任する方法もあります。
有償認証局で DNS 認証する
Sectigo、DigiCert、GlobalSign などの有償証明書は、販売店（レンタルサーバーや SSL 販売サイト）の申請画面で認証方式を選びます。DNS 認証を選ぶと、追加すべきレコードの種類・名前・値が表示されます。
- 認証局によって TXT を求めるものと CNAME を求めるものがあります
- レコード名は
_で始まるランダムな文字列になることが多いです - 値は申請ごとに発行されるため、過去の申請の値は使い回せません
表示されたとおりに登録したら、販売店の画面で「再確認」や「認証を実行」といった操作が必要な場合があります（画面の表記は販売店ごとに異なります）。認証局は定期的にも DNS を見に来ますが、すぐ進めたいときは手動で再チェックをかけます。
認証が通らないときの確認順
認証の失敗は、ほとんどが「認証局から見て、指定どおりのレコードが見えていない」ことが原因です。可能性の高い順に確認します。
1. レコード名が二重になっている
DNS 管理画面の多くは、名前欄にゾーン名を自動で補います。名前欄に _acme-challenge.example.com と入力すると、実際には _acme-challenge.example.com.example.com になってしまうことがあります。dig で正しい名前を引き、何も返らない場合は名前欄を _acme-challenge だけにして登録し直します。
2. 別のネームサーバーに登録している
前述の dig NS で表示されたネームサーバーと、レコードを追加した画面が一致しているかを確かめます。権威サーバーに直接問い合わせると切り分けが早くなります。
dig TXT _acme-challenge.example.com +short @ns1.example-dns.com権威サーバーで見えていて公開リゾルバで見えない場合は、キャッシュの問題です。過去に同じ名前を引いたときの TTL が残っていることがあるため、TTL 分待つか、TTL を短くして登録し直します。
3. 値の形式が違う
値の前後に余分な空白や引用符が入っていないか、CNAME を求められているのに TXT で登録していないかを見ます。管理画面によっては引用符を自動で付けるものと付けないものがあり、二重引用符になっているケースもあります。
4. 地域によって見え方が違う
認証局は現在、複数の地点から DNS を確認する仕組み（マルチパースペクティブ検証）を採用しています。地域ごとに応答を変える GeoDNS や、社内と社外で応答が違う構成では、一部の地点からレコードが見えずに失敗することがあります。認証の間だけでも、すべての地点から同じ応答が返る状態にしておきます。
5. DNSSEC の設定不備
DNSSEC を有効にしているのに署名や DS レコードに不整合があると、検証するリゾルバからはドメイン全体が名前解決できなくなります。dig +dnssec や外部の DNSSEC 検証ツールで、ゾーンが正しく検証されるかを確かめます。
発行後の作業と更新の注意
発行された証明書は、Web サーバー（Apache や Nginx）またはレンタルサーバーの管理画面に、中間証明書を含めて設定します。WordPress のマルチサイトをサブドメイン型で運用している場合、ワイルドカード証明書1枚ですべてのサブサイトを HTTPS 化できますが、前述のとおり2階層下のサブドメインは対象外です。
証明書の有効期間は業界ルールで段階的に短くなっており、DCV の結果を再利用できる期間も短縮されています（2026年10月現在、具体的な日数は認証局の案内を確認してください）。手作業で TXT を書き換える運用は、更新頻度が上がるほど漏れやすくなります。DNS 認証を API で自動化しておくことが、ワイルドカード証明書を安定して使ううえでいちばん効果のある対策です。認証用に追加した TXT や CNAME は、自動化の仕組みが再利用するもの以外は、発行後に削除して構いません。
まとめ
- ワイルドカード証明書の DCV は DNS 認証が基本で、HTTP（ファイル）認証は使えない
*.example.comはベースドメインと2階層下を含まないため、必要なら SAN に追加する- 申請前に
dig NSで DNS の管理場所を、dig CAAでissuewildの有無を確認する - 失敗の多くはレコード名の二重化、別のネームサーバーへの登録、値の形式違い、キャッシュ
- 有効期間の短縮が進んでいるため、DNS の API を使って更新まで自動化しておく