ワイルドカード証明書 Let's Encrypt 取得手順

この記事でわかること

• Let's Encrypt でワイルドカード証明書を取るには DNS-01 チャレンジ（DNS で所有権を証明する方式）が必須である理由
• certbot を使った発行の流れと、追加する DNS TXT レコードの形
• 90 日有効・自動更新を運用に乗せるときの注意点

ワイルドカード証明書を取る前提の確認

ワイルドカード証明書は *.example.com のように、サブドメインをまとめて 1 枚でカバーする SSL/TLS 証明書（通信を暗号化する電子証明書）です。app.example.com も mail.example.com も、同じ 1 枚で保護できます。

Let's Encrypt は無料でこのワイルドカード証明書を発行しており、本記事ではその取得手順に絞って解説します。サブドメインが何枚あれば導入メリットが出るか、といった「そもそもワイルドカードが必要かどうか」の判断はワイルドカード証明書が必要になるケースで扱っているので、迷っている方は先にそちらをご覧ください。本記事は「導入すると決めた人が、つまずかずに取得を終える」ことを目的にします。

なお、複数ドメインや証明書の枚数管理で悩んでいる場合は複数ドメインの SSL 証明書管理も参考になります。

なぜ DNS-01 チャレンジが必須なのか

Let's Encrypt で証明書を取るには「そのドメインを本当に自分が管理しているか」を証明する手続き（チャレンジ）が要ります。チャレンジには主に次の方式があります。

• HTTP-01: Web サーバー上の指定パスにファイルを置いて証明する方式
• TLS-ALPN-01: TLS 接続を使って証明する方式
• DNS-01: DNS に指定された TXT レコードを追加して証明する方式

このうちワイルドカード証明書を発行できるのは DNS-01 だけです。Let's Encrypt の公式ドキュメントは、HTTP-01 について「この方式ではワイルドカード証明書を発行できない」と明記しています。TLS-ALPN-01 も同様にワイルドカードには使えません。

理由はシンプルで、*.example.com は無数のサブドメインを表すため、特定のサーバーにファイルを置く HTTP-01 では「ワイルドカード全体の管理権」を示せないからです。DNS-01 ならドメインそのものの DNS を操作できる事実を示せるため、ワイルドカードの所有権証明として成立します。

DNS-01 では _acme-challenge.<あなたのドメイン> という名前の TXT レコードに、指定された値を入れます。この仕組みはワイルドカード対応とあわせて ACMEv2（証明書発行を自動化する標準プロトコルの第 2 版）で利用できるようになりました。

certbot でワイルドカード証明書を取得する流れ

ここでは代表的なクライアントである certbot を使った流れを示します。手順の骨子はどのクライアントでも共通です。

1. 手動で TXT レコードを追加する場合

DNS の操作を自分の手で行う最もシンプルな方法です。certbot に DNS-01 を使うよう指示して発行を始めます。代表的なコマンドは次の形です。

certbot certonly --manual --preferred-challenges=dns -d '*.example.com'

--manual を付けると、certbot は途中でいったん止まり、「この値を _acme-challenge.example.com の TXT レコードに追加してください」と表示します。

その指示どおりに、契約している DNS の管理画面（ドメイン取得業者や Cloudflare などの設定画面）で TXT レコードを追加します。追加した値が DNS に反映される（伝播する）まで少し待ってから、certbot の画面で Enter を押すと検証に進みます。検証が通れば証明書が発行され、/etc/letsencrypt/live/example.com/ 配下に保存されます。

apex ドメイン（example.com そのもの）も同じ証明書でカバーしたい場合は、-d 'example.com' -d '*.example.com' のように 2 つ指定します。ワイルドカードは example.com 自体を含まない点に注意してください。

2. DNS プラグインで自動化する場合

DNS 事業者の API を使える環境なら、TXT レコードの追加と削除を certbot が自動で行うプラグインを利用できます。たとえば Cloudflare 向けのプラグインは、公式ドキュメントによれば DNS-01 チャレンジの完了を自動化し、TXT レコードの作成とその後の削除を Cloudflare API 経由で行うと説明されています。

このプラグインを使うには API の認証情報を書いた設定ファイルが必要で、権限は対象ゾーンの DNS 編集のみに絞ることが推奨されています。手動で毎回 TXT を貼り替える手間がなくなるため、後述する自動更新まで見据えるなら API 自動化が現実的です。プラグインは標準では同梱されないため、certbot 公式サイトで自分の環境と「Wildcard」を選んで導入方法を確認してください。

90 日有効と自動更新の注意点

Let's Encrypt の証明書は有効期間が 90 日です（2026 年 5 月時点の標準）。公式 FAQ は「90 日の証明書は 60 日ごとの更新を推奨する」としています。期限の 30 日前から更新を始める運用にしておくと安全です。

更新自体は certbot renew で行えます。certbot は更新用の仕組みを 1 日 2 回動かし、期限が 30 日以内に迫った証明書を自動で更新します。ここで重要なのが、ワイルドカードの更新でも毎回 DNS-01 チャレンジが必要だという点です。

手動で TXT を追加して取得した証明書は、更新のたびに人が TXT を貼り替える必要があり、自動更新が止まりがちです。そのため、ワイルドカードを継続運用するなら前述の DNS プラグインによる自動化を組み合わせるのが定石になります。自動化していれば certbot renew が DNS の TXT 追加・検証・削除まで一気通貫で処理します。更新の自動化全般の考え方や、更新が失敗したときの確認ポイントはSSL 証明書の自動更新を止めない設定にまとめています。

なお Let's Encrypt は将来的に有効期間を短縮する方針を公表しています。現在は 90 日が標準ですが、段階的に短い有効期間へ移行する計画が示されています。期間が短くなるほど手動更新は破綻しやすくなるため、いずれにせよ自動更新を前提に組んでおくのが安全です。

よくあるつまずきポイント

TXT レコードが見つからないと言われる

DNS への反映（伝播）を待たずに検証を進めると失敗します。追加した TXT が公開 DNS に反映されているか確認してから Enter を押してください。確認は社内ネットワークではなく、外部から名前解決した結果で見るのが確実です。

ワイルドカードに apex が含まれていない

*.example.com は app.example.com などのサブドメインを表しますが、example.com そのものは含みません。トップページにもアクセスがあるサイトでは、発行時に example.com と *.example.com の両方を指定する必要があります。

サブドメインの「孫」はカバーされない

*.example.com は a.example.com をカバーしますが、b.a.example.com のような 2 階層下はカバーしません。階層が深いサブドメインがある場合は、その階層用に別途指定するか、設計を見直してください。

まとめ

• ワイルドカード証明書（*.example.com）は DNS-01 チャレンジでのみ取得でき、HTTP-01 では取れない
• DNS-01 では _acme-challenge.<ドメイン> の TXT レコードに指定値を入れて所有権を証明する
• certbot なら手動 TXT 追加か DNS プラグイン自動化のどちらかで発行できる
• 有効期間は 90 日（2026 年 5 月時点）。更新でも毎回 DNS-01 が必要なため、継続運用は自動化が前提

自社の証明書、抜けや期限切れがないか確認しませんか

ワイルドカード証明書を導入しても、apex の指定漏れや自動更新の停止で「一部のサブドメインだけ警告が出る」事故は起こります。ドメイン番人の無料診断なら、対象ドメインの証明書の状態を数秒でチェックできます。設定や更新の運用設計で迷う場合は、お問い合わせフォームから状況をお知らせください。専門家が一緒に整理いたします。