多言語サイトでサブドメインを使用する場合、どのSSL証明書を購入すればよいですか？

多言語サイトで en.example.com、de.example.com、fr.example.com のように同じ階層のサブドメインを使用し、今後も言語サイトを追加する場合は、ワイルドカード証明書のほうが通常は管理しやすくなります。ただし、購入前に、証明書にメインドメイン example.com も含まれているか、またサイト構築プラットフォーム、CDN、サーバーがその証明書の導入に対応しているかを必ず確認してください。

固定された少数の言語サイトしかない場合は、マルチドメイン証明書や、個別に発行した単一ドメイン証明書でも要件を満たせます。選定を左右するのは言語数そのものではなく、保護が必要なすべてのホスト名、ドメインの階層、そしてHTTPS接続をどこで終端するかです。

保護が必要なドメインを洗い出す

SSL証明書が検証するのはアクセス先のホスト名であり、ページの言語、ウェブサイトのディレクトリ、サーバーのIPアドレスではありません。そのため、example.com/en/ と example.com/de/ は同じホスト名を共有しているため、言語が異なるからといって証明書のカバー範囲を増やす必要はありません。一方、en.example.com と de.example.com は別々のホスト名です。

ドメインを整理する際は、各言語のトップページだけでなく、メインドメイン、www のアドレス、実際に使用しているECサイトや問い合わせフォームなどの独立したサブドメインも含めてください。リダイレクト専用のアドレスであっても、有効な証明書が必要です。HTTPSアドレスにアクセスすると、ブラウザーはリダイレクト指示を受け取る前にTLSハンドシェイクを完了するため、リダイレクトで証明書の不一致を解消することはできません。

ワイルドカードがカバーするのは指定された階層のみで、ドメインツリー全体ではない

*.example.com は en.example.com、de.example.com、www.example.com には一致しますが、example.com には一致せず、shop.en.example.com にも一致しません。

ワイルドカード証明書の中にはメインドメインも含む製品がありますが、これは発行時のドメイン設定によるもので、ワイルドカードが本来備えている機能ではありません。商品名に「ワイルドカード」とあるかどうかだけでなく、証明書のサブジェクト代替名（SAN）リストを確認してください。

ウェブサイトで en.example.com を使用し、ECサイトで shop.en.example.com を使用する場合は、両方の階層をカバーする必要があります。固定された少数のECサイト用アドレスであれば、各ホスト名をそのまま追加すればよく、階層ごとにワイルドカード証明書を購入する必要はありません。

言語サイトは固定か、それとも継続的に増えるのか？

固定されたサブドメインが数個だけの場合は、メインドメイン、www、各言語のサブドメインを1枚のマルチドメイン証明書に追加できます。この証明書では、アクセスを許可するホスト名をSANに個別に記載するため、カバー範囲が明確です。ただし、新しい言語サイトを追加する際は、ドメインリストを更新し、証明書を再発行して導入する必要があります。

言語サイトが継続的に増える予定で、すべて同じ階層のドメインにある場合は、ワイルドカード証明書のほうが管理の手間を減らせます。es.example.com を追加する際も、DNS、サイト設定、証明書の導入が適切であれば、そのホスト名のために証明書を再発行する必要はありません。ただし、ワイルドカードによってサブドメインが自動作成されたり、新しいサイトでHTTPSが自動的に有効になったりするわけではありません。

言語ごとに example.de、example.fr などの独立したドメインを使用する場合、*.example.com ではカバーできません。この場合は、マルチドメイン証明書を使用するか、各サイトで個別に証明書を発行できます。どちらを選ぶかは、導入場所と管理責任を踏まえて判断し、証明書の枚数を最小限にすることだけを優先しないでください。

購入前に、プラットフォームがすでに証明書を提供しているか確認する

ホスティング型のサイト構築プラットフォームやCDNでは、証明書の自動発行と自動更新に対応している場合があります。サービスがすべての言語サブドメインをカバーしているなら、証明書を別途購入する必要はないかもしれません。また、自分で購入した証明書をアップロードできないプラットフォームもあります。まず、対応するドメイン、ワイルドカードへの対応状況、証明書サービスが現在のプランに含まれているかを確認してください。

CDNを使用する場合は、ブラウザーからCDNまでの接続と、CDNからオリジンサーバーまでの接続を分けて考える必要があります。CDNエッジの証明書が正常でも、オリジンサーバーの証明書が正しいとは限りません。オリジンサーバーで使用する証明書は、CDNの暗号化要件と証明書検証要件を満たす必要があります。CDNからオリジンサーバーへの接続専用の証明書は、ブラウザーが信頼する公開証明書としてそのまま使用することはできません。

複数の言語サイトを別々のサーバーに配置する場合、ワイルドカード証明書を共用するには、対応する秘密鍵を各サーバーに配布する必要があります。1か所で秘密鍵が漏えいすると、同じ鍵を使用するほかのサイトにも影響する可能性があります。異なるチームやサービスプロバイダーが管理するサイトでは、証明書を分けることでリスクを分離しやすくなり、チーム間の更新調整も減らせます。

認証レベルとカバー範囲を混同しない

DV、OV、EVは本人確認の方式を示し、単一ドメイン、マルチドメイン、ワイルドカードはドメインのカバー方式を示します。これは異なる2つの軸です。OV証明書を購入しても、保護できる言語サブドメインが自動的に増えるわけではありません。また、同じTLS設定であれば、認証レベルだけで暗号化強度を判断することもできません。

言語サイトでHTTPSを正常に利用することが目的であれば、ブラウザーに信頼され、ドメイン名が一致するDV証明書で基本的な要件を満たせます。OVやEVを採用するかどうかは、企業の本人確認、契約、社内管理上の要件に基づいて判断してください。海外向けのウェブサイトだからといって、より高い認証レベルの証明書が必須になるわけではありません。

無料証明書でもHTTPSの要件を満たせますが、確実な更新の仕組みが必要です。Let’s Encryptを例にすると、ワイルドカード証明書の発行にはDNS認証が必要です。自動更新を行う場合は、DNSサービスが必要な自動化に対応しているか確認し、DNSインターフェースの認証情報に付与する権限を適切に制限してください。

公開前に各アドレスを個別に確認する

証明書の申し込みやプラットフォーム証明書の有効化の前に、実際のホスト名一覧、SANのカバー範囲、導入場所、更新の責任者を確認してください。「SSLに対応している」ことだけを確認し、発行失敗、期限切れのアラート、再導入を誰が担当するのかが不明確なままにしてはいけません。

公開後は、メインドメイン、www、各言語サブドメインに個別にアクセスし、ドメイン名の一致、証明書チェーン、HTTPSへのリダイレクトを確認するとともに、HTTPで読み込まれているリソースがページに残っていないかを調べてください。証明書の警告が表示されないからといって、ページ全体がHTTPSで完全かつ安全に読み込まれているとは限りません。

「メインドメインと同じ階層の言語サブドメイン」という構成では、メインドメインを含むワイルドカード証明書が拡張しやすい選択肢です。一方、固定された少数のサイトや分散して配置されたサイトでは、マルチドメイン証明書や個別の証明書のほうが適している場合もあります。購入は、ドメイン一覧と導入条件を確認してから行ってください。先に証明書を購入し、それに合わせてウェブサイトを変更するべきではありません。