はじめに
本ドキュメントの目的
本ドキュメントは、SSLマルチドメイン証明書をわかりやすく解説することを目的としています。複数のドメインやサブドメインを一つの証明書で保護する仕組みや、導入時のポイントを技術的な概要と実務的な観点からまとめます。
誰が読むべきか
- ウェブサイト運営者やシステム管理者の方
- 複数サイトをまとめて管理したい担当者
- SSL導入の基礎を知りたい初心者の方
具体例としては、example.com と example.net を同時に管理する人が当てはまります。
本書で学べること
- マルチドメイン証明書の基本概念と利点
- 仕組みの概略（専門用語は最小限）
- 導入手順の流れと実務上の注意点
- 代替手段と選び方の比較
前提知識と進め方
DNSやサーバーの基本的な用語が分かれば読みやすい構成です。専門用語は必要な範囲で平易に説明します。各章は実務で使える手順や事例に重点を置いています。
注意点
本書は概説と実務的なヒントを提供しますが、証明書発行機関（CA）の最新手順や契約条件は各社で異なります。導入前に必ず利用するCAやホスティングの案内を確認してください。
SSLマルチドメイン証明書について
概要
SSLマルチドメイン証明書（UCCやSAN証書とも呼ばれます）は、1枚の証明書で複数のドメインやサブドメインを保護できるサーバー証明書です。例えば example.com、shop.example.com、example.net を一つの証明書でカバーできます。管理する証明書枚数を減らせる点が特徴です。
利点
- 管理が簡単：複数のサイトに対して個別に証明書を発行・更新する手間を省けます。
- コスト削減：単体で複数ドメインを含められるため、合計費用が下がることがあります。
- 導入の柔軟性：同一のサーバーやロードバランサー上で複数ドメインを扱う際に便利です。
使いどころ（具体例）
- 企業が複数ブランドのサイトを運営している場合
- 複数ドメインを一つのホスティング環境で運用する場合
- テスト環境と本番環境を同じ証明書で運用したい場合
注意点
- 証明書に含められるドメイン数に上限があります。
- ワイルドカード機能（*.example.com）との組み合わせに制約がある場合があります。
- ひとつの証明書が失効すると、含まれるすべてのドメインに影響します。
必要に応じて、導入手順や選び方についても章で詳しく説明します。
特徴と仕組み
概要
マルチドメイン証明書は、1枚の証明書で複数のドメインを保護します。たとえば example.com、mail.example.com、shop.example.com を同じ証明書で使えます。管理がシンプルになり、証明書の数を減らせます。
有効期限と検証レベルの共有
すべてのドメインは同じ有効期限を共有します。更新はまとめて行います。検証レベル（DV/OV/EV）も証明書全体に適用されますので、検証方法は個別ではなく一括になります。
SANフィールドとCSRの指定
証明書署名要求（CSR）には、保護したいすべてのドメイン名をSAN（Subject Alternative Name）に列挙します。申請時に漏れがあると、そのドメインは保護されません。例として、CSRに example.com と shop.example.com を明記します。
対応する証明書の種類
DV（ドメイン確認）、OV（組織確認）、EV（企業実在確認）など、ほとんどの種類でマルチドメイン機能を利用できます。用途に応じて検証レベルを選んでください。
運用上の注意
1枚で複数をまとめるため、1つで問題が生じると影響範囲が広がります。ドメインの追加や削除は再発行が必要になる点に注意してください。
導入手順
以下はSSLマルチドメイン証明書の導入手順を、わかりやすく順を追って説明したものです。
- ドメインの棚卸し
- セキュリティを必要とするすべてのドメインとサブドメインを一覧にします。例: example.com、api.example.com、shop.example.net。
-
将来追加する可能性のあるドメインもメモしておくと便利です。
-
所有権確認と検証レベルの決定
-
各ドメインの所有者が誰か確認します。個人か組織かで必要な検証（DV、OV、EV）を決めます。例: コーポレートサイトはOV/EVを検討します。
-
CSR作成と申請
- CSR（証明書署名要求）に含めるドメインをすべて指定します（SAN欄）。
-
証明書局の指示に従い、ドメイン検証を完了します。一般的な方法はメール、DNS（TXTレコード）、HTTP（指定ファイル）です。
-
既存証明書のバックアップとインストール
- 既存の証明書と秘密鍵を必ずバックアップします。万が一の復旧に備えます。
-
新しい証明書をサーバーに配置し、設定ファイルを更新して適用します。必要ならサーバーを再起動します。
-
DNSや中間証明書の確認
- DNSのA/CNAME/TXTレコードが正しいか確認します。検証でTXT追加が必要な場合は削除しないでください。
-
中間証明書（チェーン）が正しく設定されているか確認します。
-
テストと検証
- ブラウザで各ドメインにアクセスして鍵マークが出るか確認します。
- オンラインのSSLチェッカーやopensslコマンドで証明書の期限、チェーン、サポートする暗号を確認します。
- 問題があれば設定を見直し、必要に応じて証明書局に問い合わせます。
運用ヒント: 証明書の有効期限をカレンダーや監視ツールで管理し、更新を自動化できるなら自動化を検討してください。
代替方法
複数ドメインを保護する際、マルチドメイン証明書のほかに代表的な選択肢が二つあります。用途や運用体制に応じて選んでください。
ワイルドカード証明書（*.example.com）
- 特徴: 同一ドメインの多くのサブドメインを一枚で保護できます。例: *.example.com は app.example.com や mail.example.com をカバーします。
- メリット: サブドメイン追加時の手続きを省けるため管理が楽です。
- デメリット: 異なるドメイン（example.org など）には使えません。秘密鍵が漏れると影響範囲が広くなります。
個別の複数証明書
- 特徴: ドメインごとに別々の証明書を発行します。例: example.com と example.org を個別に管理します。
- メリット: ドメイン単位で権限を限定でき、セキュリティを細かく管理できます。
- デメリット: 証明書の数が増えると更新や配布の手間が増します。自動化ツールで負担を軽減します。
選び方のポイント
- 同一ドメインの多数のサブドメインがあるか
- 異なるドメインを横断するか
- 管理リソースとセキュリティ要件
運用上の注意
- 更新を自動化し、有効期限切れを防いでください
- 秘密鍵は厳重に管理してください
- 可能ならサービスごとに鍵や証明書を分け、影響範囲を限定してください
要点は、簡単さを優先するならワイルドカード、細かい権限制御や異なるドメイン対応が必要なら個別証明書を選ぶことです。
