Exchange 2013 での証明書の計画


(この記事は 2014 年 3 月 19 日に The Exchange Team Blog に投稿された記事 Certificate Planning in Exchange 2013 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

これまでの記事で、Exchange 2007 や Exchange 2010 を展開済みの Exchange 2013 環境における負荷分散 の原則と 名前空間の計画 の原則、クライアント接続 の方法についてご理解いただけたかと思います。これでアップグレードに際して、必要な証明書を作成して展開できるようになります。

お伝えするまでもありませんが、証明書を作成する際は、以下のルールに従う必要があります。

  1. 使用する証明書の数を最小限にする
  2. 使用するホスト名の数を最小限にする
  3. 証明書でサブジェクトの別名 (SAN) 属性を利用する
  4. Exchange 管理センターの Exchange 証明書ウィザードを使用して証明書を要求する
  5. 1 組のデータセンターに配置されているすべての CAS に同じ証明書を展開する
  6. 証明書のプリンシパル名の値について心配せずに済むように、Vista SP1 以降のクライアントを展開する

また、ワイルドカード証明書も使用可能です。*.contoso.com を指定したワイルドカード証明書は、mail.contoso.com、legacy.contoso.com、autodiscover.contoso.com などの名前空間に対する証明書として利用できます。

ここからは、証明書の要求に含めるべきホスト名についてご理解いただくために、これまでの記事でご説明したアーキテクチャの原則に基づく 3 つのシナリオを取り上げたいと思います。

シナリオ 1

Contoso 社は、ワシントン州レドモンドとオレゴン州ポートランドに拠点を構える企業で、同社のユーザーは Outlook Anywhere、ActiveSync、Outlook Web Access、IMAP クライアントを利用して、両方のサイトに展開された Exchange 2007 プラットフォームに接続しています。

Contoso 社は最近、ネットワークのアップグレードを実施してデータセンター間で使用可能な帯域幅を拡大させると共に、エンド ユーザーにとっての単一障害点を排除しました。これにより、エンド ユーザーは、WAN の障害が発生した場合にもいずれかのデータセンターに接続できるようになりました。負荷分散については、引き続きロード バランサーでの SSL オフロードを使用する予定です。

Exchange 2013 へのアップグレードの一環として、同社ではサイト復元のために、アクティブ/アクティブ構成でデータベース可用性グループを展開する予定です。

上記の選択を受けて、Contoso 社では以下の名前空間が必要になります。

  1. autodiscover.contoso.com – クライアント構成のサポートに必要
  2. legacy.contoso.com – Exchange 2007 クライアントのサポートに必要 (共存している場合)
  3. mail.contoso.com – OWA、ActiveSync、Outlook Anywhere 用のプライマリ名前空間
  4. smtp.contoso.com – SMTP クライアント (IMAP クライアントなど) で使用する名前空間
  5. imap.contoso.com – IMAP クライアントで使用する名前空間

図 1: シナリオ 1 – 無制限モデルに基づくレイヤー 7 負荷分散

Contoso 社は、計画と展開前のテストを済ませてから、Exchange 2013 クライアント アクセス サーバーとメールボックス サーバーを展開します。次に証明書ウィザードを使用して、上記の名前空間が指定された証明書の要求を作成します。証明機関から証明書を受け取ったら、証明書ウィザードを利用して、両方のデータセンターに配置されているすべてのクライアント アクセス サーバーにその証明書をインポートし、IIS、SMTP、IMAP の各サービスで証明書を使用できるようにします。

シナリオ 2

Contoso 社は、ワシントン州レドモンドとメリーランド州ベル エアに拠点を持ちます。同社のユーザーは、Outlook Anywhere、ActiveSync、Outlook Web App を利用して、両方のサイトに展開された Exchange 2010 プラットフォームに接続しています。

データセンター間にはデータベースをレプリケートするための十分な帯域幅がありますが、障害発生時を除き、ユーザーには自分が所属する拠点のデータセンターにあるデータにアクセスしてほしいと考えています。

アップグレードの一環として、同社ではロード バランサーでの SSL オフロードを無効にして、Exchange 2013 で強化された機能を利用することにしました。このため、ロード バランサーで正常性を適切に管理できるように、クライアント別の名前空間を導入する必要があります。

上記の選択を受けて、Contoso 社では以下の名前空間が必要になります。

  1. autodiscover.contoso.com – クライアント構成のサポートに必要
  2. mail-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、OWA 用のプライマリ名前空間
  3. mail-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、OWA 用のプライマリ名前空間
  4. mailfb-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、OWA 用のフェールバック名前空間
  5. mailfb-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、OWA 用のフェールバック名前空間。
  6. eas-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、EAS 用のプライマリ名前空間
  7. eas-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、EAS 用のプライマリ名前空間
  8. oa-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、Outlook Anywhere 用のプライマリ名前空間
  9. oa-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、Outlook Anywhere 用のプライマリ名前空間
  10. ews-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、Exchange Web サービス用のプライマリ名前空間
  11. ews-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、Exchange Web サービス用のプライマリ名前空間
  12. oab-wa.contoso.com – ワシントン州レドモンドのデータセンターにおける、オフライン アドレス帳用のプライマリ名前空間
  13. oab-md.contoso.com – メリーランド州ベル エアのデータセンターにおける、オフライン アドレス帳用のプライマリ名前空間

図 2: シナリオ 2 – 制限モデルに基づくレイヤー 4 負荷分散

Contoso 社は、計画と展開前のテストを済ませてから、Exchange 2013 クライアント アクセス サーバーとメールボックス サーバーを展開します。次に証明書ウィザードを使用して、上記の名前空間が指定された証明書の要求を作成します。証明機関から証明書を受け取ったら、証明書ウィザードを利用して、両方のデータセンターに配置されているすべてのクライアント アクセス サーバーにその証明書をインポートし、IIS サービスで証明書を使用できるようにします。

シナリオ 3

Contoso 社は、ワシントン州レドモンドとオレゴン州ポートランドに拠点を持っています。同社のユーザーは、Outlook Anywhere と Outlook Web App を利用して、両方のサイトに展開された Exchange 2007 プラットフォームに接続しています。

Contoso 社は最近、ネットワークのアップグレードを実施してデータセンター間で使用可能な帯域幅を拡大させると共に、エンド ユーザーにとっての単一障害点を排除しました。これにより、エンド ユーザーは、WAN の障害が発生した場合にもいずれかのデータセンターに接続できるようになりました。負荷分散については、名前空間を Exchange 2013 に移行した後は、ロード バランサーでの SSL オフロードを利用しないことに決定しました。

Exchange 2013 へのアップグレードの一環として、同社ではサイト復元のために、アクティブ/アクティブ構成でデータベース可用性グループを展開する予定です。

上記の選択を受けて、Contoso 社では以下の名前空間が必要になります。

  1. autodiscover.contoso.com – クライアント構成のサポートに必要
  2. legacy.contoso.com – Exchange 2007 クライアントのサポートに必要 (共存している場合)
  3. mail.contoso.com – OWA クライアント用のプライマリ名前空間
  4. oa.contoso.com – Outlook Anywhere クライアントで使用する名前空間
  5. ews.contoso.com – EWS クライアントで使用する名前空間
  6. oab.contoso.com – オフライン アドレス帳のダウンロードに使用する名前空間

図 3: シナリオ 3 – 無制限モデルに基づくレイヤー 4 負荷分散

Contoso 社は、計画と展開前のテストを済ませてから、Exchange 2013 クライアント アクセス サーバーとメールボックス サーバーを展開します。次に証明書ウィザードを使用して、上記の名前空間が指定された証明書の要求を作成します。証明機関から証明書を受け取ったら、証明書ウィザードを利用して、両方のデータセンターに配置されているすべてのクライアント アクセス サーバーにその証明書をインポートし、IIS サービスで証明書を使用できるようにします。

まとめ

この記事をお読みになり、証明書の計画に関して、名前空間の原則と負荷分散の原則がどのように関連するかをご理解いただければ幸いです。ここでお見せした例からおわかりのように、負荷分散、名前空間モデル、DAG アーキテクチャの選択が、証明書で必要になるホスト名の数に大きく影響します。

Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

Skip to main content