ワイルドカード証明書のサポート

 

トピックの最終更新日: 2012-10-18

Microsoft Lync Server 2010 では、通信の暗号化とサーバーの ID 認証に証明書を使用します。リーバース プロキシ経由の Web 公開など、状況によっては、サービスを提供するサーバーの完全修飾ドメイン名 (FQDN) と一致する厳密なサブジェクトの別名 (SAN) エントリが不要な場合もあります。そのような場合には、ワイルドカード SAN エントリが含まれる証明書 (一般に "ワイルドカード証明書" といいます) を使用でき、それによって、公的証明機関から請求される証明書コストを削減し、証明書の計画プロセスの複雑さを緩和できます。

警告:
統合コミュニケーション (UC) デバイス (電話など) の機能を保持するには、展開された証明書を十分にテストして、ワイルカード証明書を実装した後もデバイスが正しく動作することを確認してください。

サブジェクト名 (共通名 (CN) ともいいます) としてのワイルドカード エントリは、どの役割でもサポートされません。SAN のワイルドカード エントリ使用は、次のサーバーの役割でサポートされます。

• 
  **リバース プロキシ。**ワイルドカード SAN エントリは、簡易 URL 発行元証明書でサポートされます。

• 
  **ディレクター。**ワイルドカード SAN エントリは、ディレクターの Web コンポーネントの簡易 URL でサポートされます。

• 
  **フロントエンド サーバー (Standard Edition) およびフロントエンド プール (Enterprise Edition)。**ワイルドカード SAN エントリは、フロント エンドの Web コンポーネントの簡易 URL でサポートされます。

• 
  **Exchange ユニファイド メッセージング (UM)。**スタンドアロン サーバーとして展開されたサーバーは、SAN エントリを使用しません。

• 
  **Microsoft Exchange Server クライアント アクセス サーバー。**SAN のワイルドカード エントリは、内部と外部のクライアントでサポートされます。

• 
  **同じサーバー上の Exchange ユニファイド メッセージング (UM) および Microsoft Exchange Server クライアント アクセス サーバー。**ワイルドカード SAN エントリがサポートされます。

次のサーバーの役割は、このトピックの対象外です。

• 内部サーバーの役割 (仲介サーバー、アーカイブおよび監視サーバー、存続可能ブランチ アプライアンス、存続可能ブランチ サーバーが含まれますが、これらに限定されません)

• 外部エッジ サーバー インターフェイス

• 内部エッジ サーバー

  注:
  内部エッジ サーバー インターフェイスでは、ワイルドカード エントリは SAN に割り当て可能で、サポートされています。内部エッジ サーバーでは SAN は照会されず、ワイルドカード SAN エントリの効果は限られています。

ワイルドカード証明書の使用例として、一貫性を保つために、「計画」ドキュメントの「関連アーキテクチャ」に使用された証明書ガイダンスを以下に記載します。詳細については、「関連アーキテクチャ」を参照してください。前述のとおり、UC デバイスは厳密な名前の一致に依存しており、FQDN エントリより前にワイルドカード SAN エントリが示されると認証に失敗します。以下の表の順序に従うと、UC デバイスと SAN のワイルドカード エントリに関連して発生する可能性のある問題を抑えることができます。

Lync Server 2010 のワイルドカード証明書の構成

コンポーネント	サブジェクト名	SAN エントリ/順序	証明機関 (CA)	拡張キー使用法 (EKU)	コメント
リバース プロキシ	lsrp.contoso.com	lsweb-ext.contoso.com *.contoso.com	パブリック	サーバー	アドレス帳サービス、配布グループ展開、および Lync IP デバイス公開ルール。サブジェクトの別名には以下が含まれます。 外部 Web サービスの FQDN ワイルドカードは、会議 (meet) とダイヤルイン (dialin) の簡易 URL が次の形式を使用している場合に、会議とダイヤルインの両方の SAN を表します。 <FQDN>/meet <FQDN>/dialin または meet.<FQDN> dialin.<FQDN>
ディレクター	dirpool01.contoso.net	sip.contoso.com sip.fabrikam.com dirweb.contoso.net dirweb-ext.contoso.com <ホスト名>.contoso.net (たとえば、<ホスト名> はプール内のディレクター director01 など) dirpool.contoso.net *.contoso.com	プライベート	サーバー	ディレクター プール内の次のサーバーおよび役割に割り当てます。 プール内の各ディレクター、またはディレクター プールが展開されていない場合スタンドアロン ディレクター ワイルドカードは、会議 (meet) とダイヤルイン (dialin) の簡易 URL が次の形式を使用している場合に、会議とダイヤルインの両方の SAN を表します。 <FQDN>/admin <FQDN>/meet <FQDN>/dialin または admin.<FQDN> meet.<FQDN> dialin.<FQDN>
Enterprise Edition フロント エンド	pool01.contoso.net (負荷分散されたプールの場合)	sip.contoso.com sip.fabrikam.com lsweb.contoso.net lsweb-ext.contoso.com <ホスト名>.contoso.net (たとえば、<ホスト名> はプール内のフロント エンド サーバー fe01 など) pool01.contoso.net *.contoso.com	プライベート	サーバー	次ホップ プール内の次のサーバーおよび役割に割り当てます。 Pool01 内のフロント エンド ワイルドカードは、会議 (meet) とダイヤルイン (dialin) の簡易 URL が次の形式を使用している場合に、会議とダイヤルインの両方の SAN を表します。 <FQDN>/admin <FQDN>/meet <FQDN>/dialin または admin.<FQDN> meet.<FQDN> dialin.<FQDN>
Standard Edition フロント エンド	se01.contoso.net	sip.contoso.com sip.fabrikam.com lsweb.contoso.net lsweb-ext.contoso.com se01.contoso.net *.contoso.com	プライベート	サーバー	次ホップ プール内の次のサーバーおよび役割に割り当てます。 ワイルドカードは、meet と dialin の簡易 URL が次の形式を使用している場合に、meet と dialin の両方の SAN を表します。 <FQDN>/admin <FQDN>/meet <FQDN>/dialin または admin.<FQDN> meet.<FQDN> dialin.<FQDN>

Microsoft Exchange Server 2007 および Exchange Server 2010

Microsoft Exchange Server をインストールして構成すると、自己署名証明書が作成されて実装されます。CA から提供された証明書をサーバーに追加するとき、その新しい証明書を使用するようにすべてのサービスと Web サービスを適切に再構成するまでは、自己署名証明書を削除しないことをお勧めします。何かが適切に動作しなくなった場合、自己署名証明書があれば、必要な全機能には対応できなくても、元の設定を構成し直して元の動作を復元できます。これによって、運用中の機能全体に影響を及ぼさずに構成の問題を解決する時間を確保できます。

Exchange で使用する証明書の詳細については、次のトピックを参照してください。

• デジタル証明書と SSL について : https://go.microsoft.com/fwlink/?linkid=218233&clcid=0x411

• Understanding Client Access Server Namespaces: https://go.microsoft.com/fwlink/?linkid=218234&clcid=0x411

• 自動検出サービスについて: https://go.microsoft.com/fwlink/?linkid=217012&clcid=0x411

Microsoft Exchange Server を Exchange ユニファイド メッセージング (UM) および Exchange クライアント アクセス サーバーと一緒に展開する場合、4 種類の展開シナリオがあります。

• **シナリオ 1:**Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを別個のサーバーに展開し、クライアント アクセス サーバーをインターネットに接続します。

• **シナリオ 2:**Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを同じサーバーに併置し、両方をインターネットに接続します。

• **シナリオ 3:**Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを別個のサーバーに展開し、公開用にリバース プロキシを使用します。

• **シナリオ 4:**Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを同じサーバーに併置し、公開用にリバース プロキシを使用します。

シナリオ 1: Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを別個のサーバーに展開する (クライアント アクセス サーバーをインターネットに接続)

Microsoft Exchange のコンポーネント	サブジェクト名	SAN エントリ/順序	証明機関 (CA)	拡張キー使用法 (EKU)	コメント
Exchange ユニファイド メッセージング (UM) サーバー名: exchum01.contoso.com	exchum01.contoso.com	Exchange UM 役割は SAN エントリを含むことはできません。	プライベート	サーバー	Exchange UM サーバーは、内部のクライアントとサーバーとのみ通信します。 プライベート CA ルート証明書を各 Exchange UM サーバーにインポートします。 Exchange UM サーバーごとに一意の証明書を作成して割り当てます。サブジェクト名はサーバー名と一致する必要があります。 Exchange UM 役割に証明書を割り当てる前に、Exchange UM サーバーでトランスポート層セキュリティ (TLS) を有効にする必要があります。 この証明書を、Outlook Web Access およびインスタント メッセージング (IM) の統合用に Exchange クライアント アクセス サーバーで使用するように割り当てます。
Exchange クライアント アクセス サーバー インターネットに接続する Active Directory サイトのクライアント アクセス サーバー サーバー名: exchcas01.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	パブリック	サーバー	外部 UC デバイスをサポートするには、サブジェクト名と SAN エントリが一致する必要があります。 サブジェクト名と SAN エントリ mail.contoso.com は、Outlook Web Access、Outlook Anywhere、EWS、およびオフライン アドレス帳の参照に使用する名前の例です。要件は、このエントリが DNS レコードと一致すること、および ExternalURL とその他のサービスのエントリを指定の名前で参照できることのみです。 SAN エントリ autodiscover は、外部 UC デバイスのサポートに必要です。
Exchange クライアント アクセス サーバー インターネットに接続しない Active Directory サイトのクライアント アクセス サーバー サーバー名: internalcas01.contoso.net	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	プライベート	サーバー	インターネットに接続しない Active Directory サイトのクライアント アクセス サーバーは、内部のクライアントとサーバーとのみ通信します。この Active Directory サイトでホストされるサービス (メールボックスなど) を照会する要求がユーザーやサービスから行われた場合、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーが代わりに、このクライアント アクセス サーバーと通信します。 インターネットと接続しない Active Directory サイトの EWS およびオフライン アドレス帳サービスは、展開された証明書を使用するように構成します。これには、内部プライベート CA からの証明書を使用できます。プライベート CA のルート証明書は、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーにある [信頼されたサード パーティ ルート証明書] ストアにインポートする必要があります。

シナリオ 2: Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを同じサーバーに併置する (両方をインターネットに接続)

Microsoft Exchange のコンポーネント	サブジェクト名	SAN エントリ/順序	証明機関 (CA)	拡張キー使用法 (EKU)	コメント
Exchange ユニファイド メッセージング (UM) サーバー名: exchcas01.contoso.com	exchcas01.contoso.com	Exchange UM 役割は SAN エントリを含むことはできません。	プライベート	サーバー	Exchange UM サーバーは、内部のクライアントとサーバーとのみ通信します。 プライベート CA ルート証明書を各 Exchange UM サーバーにインポートします。 Exchange UM 役割に証明書を割り当てる前に、Exchange UM サーバーで TLS を有効にする必要があります。 この証明書を、Outlook Web Access および IM の統合用にクライアント アクセス サーバーで使用するように割り当てます。
Exchange クライアント アクセス サーバーと インターネットに接続する Active Directory サイトのクライアント アクセス サーバー サーバー名: exchcas01.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	パブリック	サーバー	外部 UC デバイスをサポートするには、サブジェクト名と SAN エントリが一致する必要があります。 サブジェクト名と SAN エントリ mail.contoso.com は、Outlook Web Access、Outlook Anywhere、EWS、およびオフライン アドレス帳の参照に使用する名前の例です。要件は、このエントリが DNS レコードと一致すること、および ExternalURL とその他のサービスのエントリを指定の名前で参照できることのみです。 SAN エントリ autodiscover は、外部 UC デバイスのサポートに必要です。
Exchange クライアント アクセス サーバー インターネットに接続しない Active Directory サイトのクライアント アクセス サーバー サーバー名: internalcas01.contoso.net	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	プライベート	サーバー	インターネットに接続しない Active Directory サイトのクライアント アクセス サーバーは、内部のクライアントとサーバーとのみ通信します。この Active Directory サイトでホストされるサービス (メールボックスなど) を照会する要求がユーザーやサービスから行われた場合、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーが代わりに、このクライアント アクセス サーバーと通信します。 インターネットと接続しない Active Directory サイトの Exchange Web サービスおよびオフライン アドレス帳サービスは、展開された証明書を使用するように構成します。これには、内部プライベート CA からの証明書を使用できます。プライベート CA のルート証明書は、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーにある [信頼されたサード パーティ ルート証明書] ストアにインポートする必要があります。

シナリオ 3: Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを別個のサーバーに展開し、公開用にリバース プロキシを使用する

Microsoft Exchange のコンポーネント	サブジェクト名	SAN エントリ/順序	証明機関 (CA)	拡張キー使用法 (EKU)	コメント
Exchange ユニファイド メッセージング (UM) サーバー名: exchum01.contoso.com	exchum01.contoso.com	Exchange UM 役割は SAN エントリを含むことはできません。	プライベート	サーバー	Exchange UM サーバーは、内部のクライアントとサーバーとのみ通信します。 プライベート CA ルート証明書を各 Exchange UM サーバーにインポートします。 Exchange UM サーバーごとに一意の証明書を作成して割り当てます。サブジェクト名はサーバー名と一致する必要があります。 Exchange UM 役割に証明書を割り当てる前に、Exchange UM サーバーで TLS を有効にする必要があります。 この証明書を、Outlook Web Access および IM の統合用にクライアント アクセス サーバーで使用するように割り当てます。
Exchange クライアント アクセス サーバー サーバー名: exchcas01.contoso.com	exchcas01.contoso.com	exchcas01.contoso.com mail.contoso.com autodiscover.contoso.com *.contoso.com	プライベート	サーバー	外部 UC デバイスをサポートするには、サブジェクト名と SAN エントリが一致する必要があります。 プライベート CA ルート証明書を各 Exchange クライアント アクセス サーバーにインポートします。 サブジェクト名と SAN エントリ mail.contoso.com は、Outlook Web Access、Outlook Anywhere、EWS、およびオフライン アドレス帳の参照に使用する名前の例です。要件は、このエントリが DNS レコードと一致すること、および ExternalURL とその他のサービスのエントリを指定の名前で参照できることのみです。 SAN エントリ autodiscover は、外部 UC デバイスのサポートに必要です。 コンピューター名のエントリ (この例では exchcas01.contoso.com) は、Outlook Web Access および IM の統合に必要です。
リバース プロキシ サーバー名: rp.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	パブリック	サーバー	サブジェクト名と一致するエントリは、証明書の SAN 内にも存在する必要があります。 リバース プロキシで TLS または SSL を終了した後クライアント アクセス サーバーへ TLS または SSL を再確立すると、UC デバイスが失敗します。TLS または SSL の終了は、Microsoft Internet Security and Acceleration (ISA) Server、Microsoft Forefront Threat Management Gateway などの製品や他のサードパーティ実装の機能になっていますが、UC デバイスをサポートする場合には使用できません。 SAN エントリ autodiscover は、UC デバイスが正しく機能するために必要です。
Exchange クライアント アクセス サーバー インターネットに接続しない Active Directory サイトのクライアント アクセス サーバー サーバー名: internalcas01.contoso.com	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	プライベート	サーバー	インターネットに接続しない Active Directory サイトのクライアント アクセス サーバーは、内部のクライアントとサーバーとのみ通信します。この Active Directory サイトでホストされるサービス (メールボックスなど) を照会する要求がユーザーやサービスから行われた場合、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーが代わりに、このクライアント アクセス サーバーと通信します。 インターネットと接続しない Active Directory サイトの Exchange Web サービスおよびオフライン アドレス帳サービスは、展開された証明書を使用するように構成します。これには、内部プライベート CA からの証明書を使用できます。プライベート CA のルート証明書は、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーにある [信頼されたサード パーティ ルート証明書] ストアにインポートする必要があります。

シナリオ 4: Exchange ユニファイド メッセージング (UM) と Exchange クライアント アクセス サーバーを同じサーバーに併置し、公開用にリバース プロキシを使用する

Microsoft Exchange のコンポーネント	サブジェクト名	SAN エントリ/順序	証明機関 (CA)	拡張キー使用法 (EKU)	コメント
Exchange ユニファイド メッセージング (UM) サーバー名: exchum01.contoso.com	exchum01.contoso.com	Exchange UM 役割は SAN エントリを含むことはできません。	プライベート	サーバー	Exchange UM サーバーは、内部のクライアントとサーバーとのみ通信します。 プライベート CA ルート証明書を各 Exchange UM サーバーにインポートします。 Exchange UM サーバーごとに一意の証明書を作成して割り当てます。サブジェクト名はサーバー名と一致する必要があります。SAN は不要です。 Exchange UM 役割に証明書を割り当てる前に、Exchange UM サーバーで TLS を有効にする必要があります。
Exchange クライアント アクセス サーバー Exchange ユニファイド メッセージング (UM) サーバー名: exchcas01.contoso.com	mail.contoso.com	exchcas01.contoso.com mail.contoso.com autodiscover.contoso.com *.contoso.com	プライベート	サーバー	外部 UC デバイスをサポートするには、サブジェクト名と SAN エントリが一致する必要があります。 プライベート CA ルート証明書を各 Exchange クライアント アクセス サーバーにインポートします。 サブジェクト名と SAN エントリ mail.contoso.com は、Outlook Web Access、Outlook Anywhere、EWS、およびオフライン アドレス帳の参照に使用する名前の例です。要件は、このエントリが DNS レコードと一致すること、および ExternalURL とその他のサービスのエントリを指定の名前で参照できることのみです。 SAN エントリ autodiscover は、外部 UC デバイスのサポートに必要です。 コンピューター名のエントリ (この例では exchcas01.contoso.com) は、Outlook Web Access および IM の統合に必要です。
リバース プロキシ サーバー名: rp.contoso.com	mail.contoso.com	mail.contoso.com autodiscover.contoso.com *.contoso.com	パブリック	サーバー	サブジェクト名と一致するエントリは、証明書の SAN 内にも存在する必要があります。 リバース プロキシで TLS または SSL を終了した後クライアント アクセス サーバーへ TLS または SSL を再確立すると、UC デバイスが失敗します。TLS または SSL の終了は、ISA Server、Forefront Threat Management Gateway (TMG) などの製品や他のサードパーティ実装の機能になっていますが、UC デバイスをサポートする場合には使用できません。 SAN エントリ autodiscover は、UC デバイスが正しく機能するために必要です。
Exchange クライアント アクセス サーバー インターネットに接続しない Active Directory サイトのクライアント アクセス サーバー サーバー名: internalcas01.contoso.com	internalcas01.contoso.com	internalcas01.contoso.com *.contoso.com	プライベート	サーバー	インターネットに接続しない Active Directory サイトのクライアント アクセス サーバーは、内部のクライアントとサーバーとのみ通信します。この Active Directory サイトでホストされるサービス (メールボックスなど) を照会する要求がユーザーやサービスから行われた場合、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーが代わりに、このクライアント アクセス サーバーと通信します。 インターネットと接続しない Active Directory サイトの Exchange Web サービスおよびオフライン アドレス帳サービスは、展開された証明書を使用するように構成します。これには、内部プライベート CA からの証明書を使用できます。プライベート CA のルート証明書は、インターネットに接続する Active Directory サイトのクライアント アクセス サーバーにある [信頼されたサード パーティ ルート証明書] ストアにインポートする必要があります。