ワイルドカードSSL証明書は、ドメインとそのすべてのサブドメインを1つの証明書で保護します。www.example.com、blog.example.com、api.example.comに別々の証明書を取得する代わりに、1つの*.example.comワイルドカードですべてをカバーします。
ワイルドカードの仕組み
ワイルドカード文字*は任意の単一レベルのサブドメインに一致します:
| 証明書 | カバー | カバーしない |
|---|---|---|
*.example.com | www.example.com、blog.example.com、api.example.com、anything.example.com | example.com(ベアドメイン)、sub.blog.example.com(ネスト) |
*.example.com + example.com | すべてのサブドメイン + ベアドメイン | ネストされたサブドメイン |
*.sub.example.com | a.sub.example.com、b.sub.example.com | sub.example.com、example.com |
主な制限: ワイルドカードは1レベルのみに一致します。*.example.comはa.b.example.comをカバーしません。
ワイルドカード vs マルチドメイン(SAN)
| ワイルドカード | マルチドメイン(SAN) | |
|---|---|---|
| カバー | 1レベルのすべてのサブドメイン | 特定のリストされたドメイン |
| 柔軟性 | 任意のサブドメインが自動的に動作 | 各ドメインを明示的にリストする必要あり |
| 新しいサブドメイン | 即座にカバー | 新しい証明書が必要 |
| クロスドメイン | なし(1つのベースドメイン) | はい(example.com + other.com) |
| DNS-01が必要 | ✅ はい | いいえ(HTTP-01またはDNS-01) |
ワイルドカードを使う場合: 多くのサブドメインがある、または頻繁に新しいものを追加する場合。 SANを使う場合: 特定のドメイン/サブドメインの小さな固定セットがある場合。
ワイルドカード証明書を使うべき場面
適したユースケース:
- 多くのサブドメイン(
app.、api.、docs.、blog.、staging.など)を運営しており、各サブドメインに別々の証明書を管理したくない場合 - 新しいサブドメインを頻繁に追加 — 再発行なしで自動的にカバー
- サブドメイン名が頻繁に変わる開発/ステージング環境
ワイルドカードが適さない場合:
- 異なるベースドメインをカバーする必要がある(
example.com+example.org) — 代わりにSAN証明書を使用 - サブドメインごとの分離が必要 — 1つのサブドメインの鍵が侵害されると、ワイルドカード証明書はすべてのサブドメインをカバー
- DNSレコードを変更できない — ワイルドカード発行にはDNSアクセスが必要なDNS-01が必要
セキュリティの考慮事項
ワイルドカード証明書は1つの秘密鍵がすべてのサブドメインを保護することを意味します。鍵が侵害された場合、攻撃者は1つだけでなく任意のサブドメインになりすますことができます。
緩和策:
- 秘密鍵アクセスを制限 — 必要なサーバーのみが鍵ファイルを持つべき
- 短命証明書を使用 — Let’s Encryptの90日の有効期間が露出ウィンドウを制限
- 高セキュリティサブドメインには個別証明書を検討(例:
admin.example.comには独自の証明書が妥当)
無料ワイルドカード証明書の取得
Let’s EncryptはDNS-01チャレンジ経由で無料のワイルドカード証明書をサポートしています。ほとんどの競合(ZeroSSL、SSL For Free)はワイルドカードを有料プランに制限しています。
GetHTTPSの場合:
*.example.com(ベアドメインも必要なら +example.com)を入力- GetHTTPSが提供するDNS TXTレコードを追加
- DNS伝播を待つ(GetHTTPSが事前チェック)
- 検証して証明書ファイルをダウンロード
ワイルドカード証明書のインストール
通常の証明書と同じです — サーバーはワイルドカードであることを知りません:
Nginx:
server {
listen 443 ssl http2;
server_name *.example.com example.com;
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
}
Apache:
<VirtualHost *:443>
ServerName example.com
ServerAlias *.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/cert.pem
SSLCertificateKeyFile /etc/ssl/privkey.pem
SSLCertificateChainFile /etc/ssl/chain.pem
</VirtualHost>
よくある質問
ワイルドカードにHTTP-01を使えないのはなぜですか?
HTTP-01はhttp://hostname/.well-known/acme-challenge/...にファイルを配置して特定のホスト名を検証します。ワイルドカードは無限のサブドメインをカバーします — ファイルを配置する単一のサーバーがありません。DNS-01はゾーンレベルのTXTレコードを通じてドメイン全体の管理を証明します。
*.example.comはexample.comをカバーしますか?
いいえ。ベアドメインは別途リストする必要があります。GetHTTPSとCertbotは1つの証明書で*.example.comとexample.comの両方をサポートしています。
ZeroSSLから無料のワイルドカードを取得できますか?
いいえ。ZeroSSLはワイルドカード証明書を有料プラン($10/月以上)に制限しています。Let’s Encryptはワイルドカードを無料で提供しています。
同じドメインに複数のワイルドカード証明書を持てますか?
はい。技術的な制限はありません。*.example.comと*.staging.example.comを別々の証明書として持つことができます。Let’s Encryptのレート制限は登録ドメインあたり週50証明書です。
ワイルドカード証明書はネストされたサブドメインをカバーしますか?
いいえ。*.example.comはwww.example.comとapi.example.comをカバーしますが、dev.api.example.comはカバーしません。ネストされたサブドメインには*.api.example.comのような別のワイルドカードが必要です。
ワイルドカード証明書が特定のサブドメインで動作しているかテストするには?
サブドメインのDNSをサーバーに向けてからテスト:
echo | openssl s_client -connect subdomain.example.com:443 -servername subdomain.example.com 2>/dev/null | openssl x509 -noout -subject -dates
証明書はCN=*.example.comまたはSANフィールドに*.example.comを表示するはずです。接続エラーが出る場合、サブドメインのDNSがワイルドカード証明書をホストするサーバーを指していません。
ワイルドカード証明書を複数のサーバーで使えますか?
はい。サブドメインを処理するすべてのサーバーに同じfullchain.pemとprivkey.pemをインストールしてください。証明書はどのサーバーにあるか知りません — ホスト名を検証するだけです。