次の方法で共有

デジタル証明書と SSL

  • [アーティクル]

製品: Exchange Server 2013

Secure Sockets Layer (SSL) は、クライアントとサーバー間の通信をセキュリティで保護するための方法です。 Exchange Server 2013 では、サーバーとクライアント間の通信をセキュリティで保護するために SSL が使用されます。 クライアントには、携帯電話、組織のネットワーク内のコンピューター、組織のネットワーク外のコンピューターが含まれます。

既定では、Exchange 2013 をインストールすると、Outlook Web App、Exchange ActiveSync、Outlook Anywhere を使用する場合、クライアント通信は SSL を使用して暗号化されます。

SSL では、デジタル証明書を使用する必要があります。 このトピックでは、さまざまな種類のデジタル証明書と、これらの種類のデジタル証明書を使用するように Exchange 2013 を構成する方法について説明します。

デジタル証明書の概要

デジタル証明書は、オンライン パスワードのように動作し、ユーザーまたはコンピューターの ID を確認する電子ファイルです。 これらは、クライアント通信に使用される SSL 暗号化チャネルを作成するために使用されます。 証明書は、証明機関 (CA) によって発行されたデジタルステートメントであり、証明書所有者の ID を保証し、暗号化を使用して関係者が安全な方法で通信できるようにします。

デジタル証明書は次の 2 つの働きをします。

  • 所有者 (ユーザー、Web サイト、さらにはルーターなどのネットワーク リソース) が、本当に誰であるか、何であると主張しているのかを認証します。

  • オンラインで交換されたデータを盗難や改ざんから保護します。

デジタル証明書は、証明書サービスを使用して信頼されたサード パーティ CA または Windows 公開キー インフラストラクチャ (PKI) によって発行することも、自己署名することもできます。 証明書の種類ごとに長所と短所があります。 各種類のデジタル証明書は改ざん防止であり、偽造することはできません。

証明書はさまざまな目的で使用するために発行できます。 これらの用途には、Web ユーザー認証、Web サーバー認証、Secure/多目的インターネット メール拡張機能 (S/MIME)、インターネット プロトコル セキュリティ (IPsec)、トランスポート層セキュリティ (TLS)、コード署名などがあります。

証明書には公開キーが含まれ、その公開キーを対応する秘密キーを保持するユーザー、コンピューター、サービスの ID に結び付けます。 公開キーと秘密キーは、送信前にデータを暗号化するためにクライアントとサーバーによって使用されます。 Windows ベースのユーザー、コンピューター、サービスの場合、信頼されたルート証明書ストアにルート証明書のコピーがあり、証明書に有効な認定パスが含まれている場合、CA への信頼が確立されます。 証明書を有効にするには、証明書を失効させず、有効期間の有効期限が切れていない必要があります。

証明書の種類

デジタル証明書には、自己署名証明書、Windows PKI で生成された証明書、サード パーティの証明書の 3 種類があります。

自己署名入りの証明書

Exchange 2013 をインストールすると、メールボックス サーバーに自己署名証明書が自動的に構成されます。 自己署名証明書は、それを作成したアプリケーションによって署名されます。 サブジェクトと証明書の名前が一致します。 発行者とサブジェクトは、証明書で定義されます。 この自己署名証明書は、クライアント アクセス サーバーとメールボックス サーバー間の通信を暗号化するために使用されます。 クライアント アクセス サーバーは、メールボックス サーバー上の自己署名証明書を自動的に信頼するため、メールボックス サーバーでサード パーティの証明書は必要ありません。 Exchange 2013 をインストールすると、自己署名証明書もクライアント アクセス サーバーに作成されます。 この自己署名証明書を使用すると、一部のクライアント プロトコルで通信に SSL を使用できます。 Exchange ActiveSyncとOutlook Web Appは、自己署名証明書を使用して SSL 接続を確立できます。 Outlook Anywhere は、クライアント アクセス サーバー上の自己署名証明書では機能しません。 自己署名証明書は、クライアント コンピューターまたはモバイル デバイス上の信頼されたルート証明書ストアに手動でコピーする必要があります。 クライアントが SSL 経由でサーバーに接続し、サーバーが自己署名証明書を提示すると、証明書が信頼された機関によって発行されたことを確認するように求められます。 クライアントは、発行元の機関を明示的に信頼する必要があります。 クライアントが信頼を確認した場合は、SSL 通信を続行できます。

注:

既定では、メールボックス サーバーまたはサーバーにインストールされているデジタル証明書は自己署名証明書です。 組織内のメールボックス サーバー上の自己署名証明書を信頼されたサード パーティの証明書に置き換える必要はありません。 クライアント アクセス サーバーは、メールボックス サーバー上の自己署名証明書を自動的に信頼し、メールボックス サーバー上の証明書に他の構成は必要ありません。

多くの場合、小規模な組織では、サード パーティの証明書を使用しないか、独自の PKI をインストールして独自の証明書を発行しないことを決定します。 これらのソリューションのコストが高すぎる、管理者が独自の証明書階層を作成する経験と知識がない、またはその両方の理由から、この決定を行う可能性があります。 自己署名証明書を使用する場合、コストは最小限で、セットアップは簡単です。 ただし、自己署名証明書を使用する場合、証明書のライフサイクル管理、更新、信頼管理、失効のためのインフラストラクチャを確立することははるかに困難です。

Windows 公開キー インフラストラクチャ証明書

2 番目の種類の証明書は、Windows PKI で生成された証明書です。 PKI は、公開キー暗号化を使用して電子トランザクションに関与する各当事者の有効性を検証および認証するデジタル証明書、証明機関、および登録機関 (RU) のシステムです。 Active Directory を使用する組織に PKI を実装する場合は、証明書のライフサイクル管理、更新、信頼管理、失効のためのインフラストラクチャを提供します。 ただし、Windows PKI で生成された証明書を作成および管理するためのサーバーとインフラストラクチャの展開には、いくつかの追加コストが必要です。

証明書サービスは、Windows PKI を展開するために必要であり、コントロール パネルの [プログラムの追加と削除] を使用してインストールできます。 証明書サービスは、ドメイン内の任意のサーバーにインストールできます。

ドメインに参加している Windows CA から証明書を取得する場合は、CA を使用して、ネットワーク上の独自のサーバーまたはコンピューターに発行する証明書を要求または署名できます。 これにより、サードパーティの証明書ベンダーに似た PKI を使用できますが、コストは低くなります。 これらの PKI 証明書は、他の種類の証明書と同様に、パブリックに展開することはできません。 ただし、PKI CA が秘密キーを使用して要求者の証明書に署名すると、要求者が検証されます。 この CA の公開キーは、証明書の一部です。 信頼されたルート証明書ストアにこの証明書を含むサーバーは、その公開キーを使用して、要求元の証明書の暗号化を解除し、要求元を認証できます。

PKI で生成された証明書を展開する手順は、自己署名証明書を展開するために必要な手順と似ています。 引き続き、信頼されたルート証明書のコピーを PKI から、Microsoft Exchange への SSL 接続を確立できるようにするコンピューターまたはモバイル デバイスの信頼されたルート証明書ストアにインストールする必要があります。

Windows PKI を使用すると、組織は独自の証明書を発行できます。 クライアントは、内部ネットワーク上の Windows PKI から証明書を要求および受信できます。 Windows PKI は、証明書を更新または取り消すことができます。

信頼されたサード パーティの証明書

サード パーティまたは商用証明書は、サード パーティまたは商用 CA によって生成され、ネットワーク サーバーで使用するために購入された証明書です。 自己署名証明書と PKI ベースの証明書の問題の 1 つは、証明書がクライアント コンピューターまたはモバイル デバイスによって自動的に信頼されないため、クライアント コンピューターとデバイスの信頼されたルート証明書ストアに証明書をインポートする必要があるということです。 サード パーティまたは商用証明書には、この問題はありません。 証明書が既に信頼されたルート証明書ストアに存在するため、ほとんどの商用 CA 証明書は既に信頼されています。 発行者は信頼されているため、証明書も信頼されます。 サード パーティの証明書を使用すると、デプロイが大幅に簡略化されます。

証明書をパブリックに展開する必要がある大規模な組織や組織の場合、証明書に関連するコストがある場合でも、サード パーティまたは商用証明書を使用することをお勧めします。 商用証明書は、小規模および中規模の組織にとって最適なソリューションではない可能性があり、使用可能な他の証明書オプションのいずれかを使用することを決定する場合があります。

証明書の種類の選択

インストールする証明書の種類を選択する場合は、いくつかの点を考慮する必要があります。 有効にするには、証明書に署名する必要があります。 自己署名または CA によって署名できます。 自己署名証明書には制限があります。 たとえば、すべてのモバイル デバイスで、ユーザーが信頼されたルート証明書ストアにデジタル証明書をインストールできるわけではありません。 モバイル デバイスに証明書をインストールする機能は、モバイル デバイスの製造元とモバイル サービス プロバイダーによって異なります。 一部の製造元とモバイル サービス プロバイダーは、信頼されたルート証明書ストアへのアクセスを無効にします。 この場合、自己署名証明書も Windows PKI CA からの証明書もモバイル デバイスにインストールできません。

既定の Exchange 証明書

既定では、Exchange は、すべてのネットワーク通信が暗号化されるように、クライアント アクセス サーバーとメールボックス サーバーの両方に自己署名証明書をインストールします。 すべてのネットワーク通信を暗号化するには、すべての Exchange サーバーに使用できる X.509 証明書が必要です。 クライアント アクセス サーバー上のこの自己署名証明書は、クライアントによって自動的に信頼される証明書に置き換える必要があります。

"自己署名" とは、証明書が作成され、Exchange サーバー自体によってのみ署名されたことを意味します。 一般的に信頼されている CA によって作成および署名されていないため、既定の自己署名証明書は、同じ組織内の他の Exchange サーバーを除くソフトウェアによって信頼されません。 既定の証明書は、すべての Exchange サービスで有効になっています。 これには、インストールされている Exchange サーバーのサーバー名に対応するサブジェクト代替名 (SAN) があります。 サーバー名とサーバーの完全修飾ドメイン名 (FQDN) の両方を含む SAN の一覧もあります。

Exchange 組織内の他の Exchange サーバーは、この証明書を自動的に信頼しますが、Web ブラウザー、Outlook クライアント、携帯電話、その他の電子メール クライアントなどのクライアントは、外部の電子メール サーバーに加えて、その証明書を自動的に信頼しません。 そのため、この証明書を Exchange クライアント アクセス サーバー上の信頼されたサード パーティの証明書に置き換えることを検討してください。 独自の内部 PKI があり、すべてのクライアントがそのエンティティを信頼している場合は、自分で発行する証明書を使用することもできます。

サービス別の証明書要件

証明書は、Exchange の複数のものに使用されます。 ほとんどのお客様は、複数の Exchange サーバーで証明書を使用しています。 一般に、証明書の数が少ないほど、証明書の管理が容易になります。

IIS

次のすべての Exchange サービスは、特定の Exchange クライアント アクセス サーバーで同じ証明書を使用します。

  • Outlook Web App

  • Exchange 管理センター (EAC)

  • Exchange Web サービス

  • Exchange ActiveSync

  • Outlook Anywhere

  • 自動検出

  • Outlook アドレス帳の配布

Web サイトに関連付けることができる証明書は 1 つだけであり、これらのサービスはすべて既定で 1 つの Web サイトで提供されるため、これらのサービスのクライアントが使用するすべての名前は証明書に含まれている (または証明書のワイルドカード名に該当する) 必要があります。

POP/IMAP

POP または IMAP に使用される証明書は、IIS に使用される証明書とは別に指定できます。 ただし、管理を簡略化するために、IIS 証明書に POP または IMAP サービス名を含め、これらのサービスすべてに 1 つの証明書を使用することをお勧めします。

SMTP

構成する受信コネクタごとに、個別の証明書を使用できます。 証明書には、SMTP クライアント (またはその他の SMTP サーバー) がそのコネクタに到達するために使用する名前を含める必要があります。 証明書管理を簡略化するには、TLS トラフィックをサポートする必要があるすべての名前を 1 つの証明書に含めることを検討してください。

デジタル証明書とプロキシ

プロキシは、あるサーバーが別のサーバーにクライアント接続を送信する方法です。 Exchange 2013 の場合、これは、クライアント アクセス サーバーが、クライアントのメールボックスのアクティブなコピーを含むメールボックス サーバーに受信クライアント要求をプロキシするときに発生します。

クライアント アクセス サーバーのプロキシ要求では、暗号化には SSL が使用されますが、認証には使用されません。 メールボックス サーバー上の自己署名証明書は、クライアント アクセス サーバーとメールボックス サーバー間のトラフィックを暗号化します。

リバース プロキシと証明書

多くの Exchange 展開では、リバース プロキシを使用して Exchange サービスをインターネットに公開しています。 リバース プロキシは、SSL 暗号化を終了し、サーバー上のクリア内のトラフィックを調べ、リバース プロキシ サーバーからその背後にある Exchange サーバーへの新しい SSL 暗号化チャネルを開くように構成できます。 これは SSL ブリッジングと呼ばれます。 リバース プロキシ サーバーを構成するもう 1 つの方法は、SSL 接続をリバース プロキシ サーバーの背後にある Exchange サーバーに直接渡すことです。 どちらの展開モデルでも、インターネット上のクライアントは、Exchange アクセスのホスト名 (mail.contoso.com など) を使用してリバース プロキシ サーバーに接続します。 その後、リバース プロキシ サーバーは、Exchange クライアント アクセス サーバーのマシン名など、別のホスト名を使用して Exchange に接続します。 証明書に Exchange クライアント アクセス サーバーのマシン名を含める必要はありません。ほとんどの一般的なリバース プロキシ サーバーは、クライアントで使用されている元のホスト名を Exchange クライアント アクセス サーバーの内部ホスト名と一致させることができます。

SSL と分割 DNS

スプリット DNS は、送信元の DNS 要求の送信元に応じて、同じホスト名に異なる IP アドレスを構成できるテクノロジです。 スプリット ホライズン DNS、スプリット ビュー DNS、またはスプリット ブレイン DNS とも呼ばれます。 スプリット DNS を使用すると、クライアントの接続経路 (インターネットまたはイントラネット) に関わらず同じホスト名を使用して Exchange に接続することを許可することで、Exchange で管理する必要のあるホスト名の数を減らすことができます。 分割 DNS を使用すると、イントラネットから送信された要求は、インターネットから送信された要求とは異なる IP アドレスを受信できます。

通常、小規模な Exchange 展開では分割 DNS は不要です。ユーザーはイントラネットまたはインターネットから取得した場合でも、同じ DNS エンドポイントにアクセスできるためです。 ただし、大規模なデプロイでは、この構成により、送信インターネット プロキシ サーバーとリバース プロキシ サーバーの負荷が高すぎます。 大規模なデプロイの場合は、外部ユーザーが mail.contoso.com にアクセスし、内部ユーザーが internal.contoso.com にアクセスできるように、分割 DNS を構成します。 この構成に分割 DNS を使用すると、ユーザーが配置されている場所に応じて異なるホスト名を使用する必要がなくなります。

リモート Windows PowerShell

Kerberos 認証と Kerberos 暗号化は、Exchange 管理センター (EAC) と Exchange 管理シェルの両方から、リモート Windows PowerShell アクセスに使用されます。 そのため、リモート Windows PowerShellで使用するように SSL 証明書を構成する必要はありません。

デジタル証明書のベスト プラクティス

組織のデジタル証明書の構成は、組織の特定の要件によって異なりますが、ベスト プラクティスに関する情報が含まれており、要件に合うデジタル証明書の構成を選択できます。

ベスト プラクティス: 信頼されたサード パーティの証明書を使用する

信頼されていない証明書に関するエラーをクライアントが受け取らないようにするには、Exchange サーバーで使用される証明書を、クライアントが信頼するユーザーが発行する必要があります。 ほとんどのクライアントは、任意の証明書または証明書発行者を信頼するように構成できますが、Exchange サーバーで信頼されたサード パーティの証明書を使用する方が簡単です。 これは、ほとんどのクライアントが既にルート証明書を信頼しているためです。 Exchange 用に構成された証明書を提供するサード パーティの証明書発行者がいくつかあります。 EAC を使用して、ほとんどの証明書発行者と連携する証明書要求を生成できます。

証明機関を選択する方法

証明機関 (CA) は、証明書を発行し、証明書の有効性を保証する会社です。 クライアント ソフトウェア (たとえば、Microsoft Internet Explorer などのブラウザー、Windows や Mac OS などのオペレーティング システム) には、信頼できる CA の一覧が組み込まれています。 この一覧は通常、CA を追加および削除するように構成できますが、その構成は多くの場合、面倒です。 証明書を購入する CA を選択する場合は、次の条件を使用します。

  • EXCHANGE サーバーに接続するクライアント ソフトウェア (オペレーティング システム、ブラウザー、携帯電話) によって CA が信頼されていることを確認します。

  • Exchange サーバーで使用するために "ユニファイド コミュニケーション証明書" がサポートされていることを示す CA を選択します。

  • CA で使用する証明書の種類がサポートされていることを確認します。 サブジェクト代替名 (SAN) 証明書の使用を検討してください。 すべての CA が SAN 証明書をサポートしているわけではありません。また、他の CA では必要な数のホスト名がサポートされていません。

  • 証明書に対して購入するライセンスで、使用するサーバーの数に証明書を配置できることを確認します。 一部の CA では、証明書を 1 つのサーバーにのみ配置できます。

  • CA 間で証明書の価格を比較します。

ベスト プラクティス: SAN 証明書を使用する

Exchange 展開でサービス名を構成する方法によっては、Exchange サーバーで複数のドメイン名を表す証明書が必要になる場合があります。 *.contoso.com などのワイルドカード証明書は、この問題を解決できますが、多くのお客様は、任意のサブドメインに使用できる証明書を維持することのセキュリティへの影響に不快感を持っています。 より安全な方法として、必要な各ドメインを証明書の SAN として一覧表示する方法があります。 既定では、この方法は、Exchange によって証明書要求が生成されるときに使用されます。

ベスト プラクティス: Exchange 証明書ウィザードを使用して証明書を要求する

Exchange には、証明書を使用する多くのサービスがあります。 証明書を要求するときの一般的なエラーは、正しいサービス名のセットを含めずに要求を行う場合です。 Exchange 管理センターの証明書ウィザードを使用すると、証明書要求に正しい名前の一覧を含めることができます。 ウィザードを使用すると、証明書を操作する必要があるサービスを指定できます。また、選択したサービスに基づいて、証明書に必要な名前が含まれているため、それらのサービスで使用できます。 Exchange 2013 サーバーの初期セットを展開し、展開に使用するさまざまなサービスに使用するホスト名を決定したら、証明書ウィザードを実行します。 理想的には、Exchange を展開する Active Directory サイトごとに証明書ウィザードを 1 回だけ実行する必要があります。

購入した証明書の SAN リストでホスト名を忘れることを心配する代わりに、無料で証明書を返し、いくつかの追加のホスト名で同じ新しい証明書を要求できる猶予期間を提供する証明機関を使用できます。

ベスト プラクティス: 可能な限り少数のホスト名を使用する

できるだけ少ない証明書を使用するだけでなく、できるだけ少ないホスト名も使用する必要があります。 この方法により、コストを節約できます。 多くの証明書プロバイダーは、証明書に追加するホスト名の数に基づいて料金を請求します。

必要なホスト名の数を減らすために実行できる最も重要な手順、したがって、証明書管理の複雑さは、証明書のサブジェクトの代替名に個々のサーバー ホスト名を含めないようにすることです。

Exchange 証明書に含める必要があるホスト名は、クライアント アプリケーションが Exchange に接続するために使用するホスト名です。 Contoso という名前の会社に必要となる一般的なホスト名の一覧を次に示します。

  • Mail.contoso.com: このホスト名は、Microsoft Outlook、Outlook Web App、Outlook Anywhere、オフライン アドレス帳、Exchange Web サービス、POP3、IMAP4、SMTP、Exchange コントロール パネル、ActiveSync など、Exchange へのほとんどの接続を対象としています。

  • Autodiscover.contoso.com: このホスト名は、Microsoft Office Outlook 2007 以降のバージョン、Exchange ActiveSync、Exchange Web サービス クライアントなど、自動検出をサポートするクライアントによって使用されます。

  • Legacy.contoso.com: このホスト名は、Exchange 2007 と Exchange 2013 との共存シナリオで必要です。 Exchange 2007 と Exchange 2013 にメールボックスを持つクライアントがある場合、レガシ ホスト名を構成すると、アップグレード プロセス中にユーザーが 2 つ目の URL を学習する必要がありません。

ワイルドカード証明書について

ワイルドカード証明書は、ドメインと複数のサブドメインをサポートするように設計されています。 たとえば、*.contoso.com のワイルドカード証明書を構成すると、mail.contoso.com、web.contoso.com、および autodiscover.contoso.com に対して機能する証明書になります。