SSLならセクティゴ・コモドのEV・企業・ドメイン認証

最も大きな違いは、「DNS-01 チャレンジ」が必須であることです。

※1. 認証方式は「DNS-01」一択

HTTP-01チャレンジはワイルドカードの場合はご利用できません

通常の証明書では、Webサーバーの特定のパスにファイルを置く「HTTP-01 チャレンジ」が使えますが、ワイルドカード証明書の場合はDNS-01 チャレンジしか認められていません。

仕組み	ACMEクライアントが提示する特定の文字列(トークン)を、対象ドメインのDNSレコード(_acme-challenge.example.com)に TXTレコード として追加し、認証局がそれを外部から確認することで所有権を証明します。
注意点	Webサーバー上の操作HTTPチャレンジは不可、ワイルドカードではかならずDNSサーバーの操作権限DNSチャレンジが必要になります。

※2. 自動更新の難易度(APIの有無)

証明書の有効期限(90日)ごとに手動でDNSレコードを書き換えるのは現実的ではありません。そのため、DNSレコードをAPI経由で自動操作できる環境が必須となります。

推奨環境	Cloudflare, AWS Route53, Google Cloud DNS, Azure DNSなどの主要クラウドや、APIを提供しているDNSプロバイダー
非推奨環境	管理画面からしかレコード編集ができない古いレジストラやレンタルサーバー提供のGUIのみのDNS操作。これらを使用している場合、ワイルドカードの自動更新は非常に困難(または不可能)です。

※3. 「ベースドメイン」の含め方

ワイルドカード証明書(*.example.com)を取得しても、ベースドメイン(example.com 自体)は保護対象に含まれないという点に注意してください。

証明書をリクエストする際、必ず「*.example.com」と「example.com」の両方をサブジェクト別名(SANs)に含める必要があります。

例(Certbotの場合): -d example.com -d "*.example.com"

※4. セキュリティ上のリスク

ワイルドカード証明書は便利ですが、管理上のリスクも伴います。

秘密鍵の使い回し	複数のサーバー(www.example.com と mail.example.com など)で同じワイルドカード証明書と秘密鍵を共有する場合、1台のサーバーが侵害されると、全サブドメインの通信が盗聴・改ざんされるリスクがあります
管理の分散	証明書取得サーバから各サーバーに秘密鍵をコピーして配布する運用等になるため、フックスクリプトで鍵ペアを自動送信するなどの管理が煩雑になりがちです。