サブサブドメインをSSL化する方法｜ワイルドカード証明書が効かない理由と正しい発行手順

api.dev.example.com のような2階層目のサブドメイン（サブサブドメイン）は、*.example.com のワイルドカード証明書ではカバーされません。HTTPS にするには、その名前を含む証明書を個別に発行するか、*.dev.example.com という1段下のワイルドカード証明書を用意する必要があります。この記事では、まずワイルドカードが効かない理由を説明し、Let's Encrypt（certbot）での発行手順、Cloudflare を使っている場合の注意、設定後の確認方法を順に解説します。

ワイルドカード証明書がサブサブドメインに効かない理由

ワイルドカード証明書の *（アスタリスク）は、ちょうど1階層分のラベルにしか一致しません。これは証明書の照合ルールとして決められているもので、認証局やブラウザの違いで変わるものではありません。

*.*.example.com のように複数階層をまとめるワイルドカードも発行できません。そのため、サブサブドメインを HTTPS にする選択肢は次の3つです。

1. その名前だけの証明書（api.dev.example.com）を発行する
2. 1段下のワイルドカード（*.dev.example.com）を発行し、dev.example.com 配下をまとめて扱う
3. 複数名を並べた証明書（SAN）に、必要なサブサブドメインを列挙する

数が少なく増える予定もないなら 1、検証環境のように dev.example.com の下に名前が次々増えるなら 2 が向いています。

事前準備：DNS レコードを作る

証明書を発行する前に、サブサブドメインが名前解決できる状態にします。方法は2通りあります。

• 同じゾーンにレコードを作る：example.com のゾーンに、名前を api.dev として A レコード（または CNAME）を追加します。DNS 事業者の画面で名前欄に api.dev と入力できれば、それで足ります。
• **dev.example.com を別ゾーンとして委任する**：example.com のゾーンに dev の NS レコードを置き、別の DNS サーバーで dev.example.com を管理します。チームごとに DNS を分けたい場合の方法ですが、構成が複雑になるため、必要がなければ前者で十分です。

dig +short api.dev.example.com A

サーバーの IP が返れば準備完了です。dev.example.com 自体にレコードが無くても、api.dev.example.com のレコードは作れます。

方法1：個別の証明書を発行する（HTTP-01）

サーバーが外部から 80 番ポートで到達できるなら、もっとも手軽な方法です。Web サーバーに、そのサブサブドメイン用の設定（Nginx の server ブロックや Apache の VirtualHost）をあらかじめ作っておきます。

server {
    listen 80;
    server_name api.dev.example.com;
    root /var/www/api-dev;
}

設定を読み込んだら certbot で発行します。

sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d api.dev.example.com

Apache なら --apache を使います。certbot は発行後に server ブロックへ証明書の設定を追記し、自動更新のタイマーも用意します（ディストリビューションや導入方法で仕組みが異なるため、systemctl list-timers などで確認してください）。

つまずきやすいのは、80番ポートがファイアウォールで閉じている、DNS がまだ反映されていない、別の server ブロックが先に応答している、の3点です。エラーが出たら curl -I http://api.dev.example.com/ で、意図したサーバーから応答が返るかを見ます。

方法2：1段下のワイルドカードを発行する（DNS-01）

ワイルドカード証明書は、Let's Encrypt では DNS-01 チャレンジ（DNS に TXT レコードを置いて所有を示す方法）でしか発行できません。手動でも発行できますが、自動更新できないため、DNS 事業者の API に対応した certbot のプラグインを使うのが現実的です。

Cloudflare で DNS を管理している場合の例です。

# プラグインの導入（導入方法は環境に合わせて。snap 版 certbot ならプラグインも snap で入れる）
sudo apt install python3-certbot-dns-cloudflare

# API トークンを保存（権限は対象ゾーンの DNS 編集だけに絞る）
sudo install -d -m 700 /root/.secrets
sudo install -m 600 /dev/null /root/.secrets/cloudflare.ini
echo 'dns_cloudflare_api_token = your-api-token' | sudo tee /root/.secrets/cloudflare.ini > /dev/null

# *.dev.example.com と dev.example.com をまとめて発行
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d '*.dev.example.com' -d dev.example.com

トークンを書いたファイルは root だけが読める権限にしておきます。API トークンは Web から見える場所や Git リポジトリに置かないでください。ほかの DNS 事業者向けにもプラグインがあるので、certbot の公式ドキュメントで対応状況を確認してください（2026年10月現在）。

certonly で発行した証明書は自分で Web サーバーに設定します。

server {
    listen 443 ssl;
    server_name *.dev.example.com dev.example.com;
    ssl_certificate     /etc/letsencrypt/live/dev.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dev.example.com/privkey.pem;
}

live/ の下のディレクトリ名は、最初に指定した名前から作られます。実際の名前は sudo certbot certificates で確認できます。

ワイルドカード証明書は1つの秘密鍵を多くのホストで共有することになります。検証環境用のワイルドカードと本番用の証明書は分けておくと、万一鍵が漏れたときの影響範囲を限定できます。

Cloudflare のプロキシを使っている場合の注意

Cloudflare の無料プランで自動的に用意される証明書（Universal SSL）は、ルートドメインと1階層目のサブドメインが対象です。サブサブドメインをプロキシ有効（オレンジの雲）にすると、訪問者と Cloudflare の間で証明書エラーになることがあります。

対応は次のいずれかです。

• サブサブドメインのレコードを「DNS のみ」にして、オリジンサーバーの証明書（上記の方法1・2）で直接 HTTPS にする
• Cloudflare の有料オプション（高度な証明書の管理機能）で、サブサブドメインを含む証明書を発行する

対象範囲やプラン構成は変わることがあるため、Cloudflare の公式ドキュメントで確認してください。

WordPress をサブサブドメインで動かす場合

検証用に stg.dev.example.com で WordPress を動かす場合は、証明書を設定したあと、管理画面の「設定」→「一般」で WordPress アドレスとサイトアドレスを https:// に変更します。管理画面に入れない場合は、wp-config.php に WP_HOME と WP_SITEURL の定数を書いて指定できます。本番のデータベースを複製した検証環境では、本文中の URL を置き換える前にデータベースのバックアップを取ってください。

設定後の確認

証明書に目的の名前が含まれているかを、サーバーに直接問い合わせて確かめます。

echo | openssl s_client -connect api.dev.example.com:443 -servername api.dev.example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -enddate

subjectAltName に api.dev.example.com か *.dev.example.com が含まれていれば正しく設定できています。*.example.com しか表示されない場合は、別の server ブロックの証明書が返っているので、server_name の指定を見直します。最後に sudo certbot renew --dry-run で更新の予行演習が通ることも確認しておきます。

まとめ

• *.example.com は1階層分にしか一致せず、api.dev.example.com には効きません。
• サブサブドメインの HTTPS 化は、個別の証明書、*.dev.example.com のワイルドカード、SAN 証明書のいずれかで行います。
• 個別の証明書は HTTP-01 で手軽に発行でき、ワイルドカードは DNS-01 と DNS 事業者のプラグインで自動更新まで組みます。
• Cloudflare の無料の証明書はサブサブドメインを対象にしていないため、プロキシ設定に注意します。
• openssl s_client で SAN を確認し、certbot renew --dry-run で更新を確かめます。

• Let's Encrypt証明書の自動更新を設定する
• SNIで複数ドメインの証明書を1台のサーバーで扱う