次の方法で共有

ドメイン セキュリティのためにエッジ トランスポート サーバーの PKI を有効にする方法

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2007-08-28

ドメイン セキュリティは、認証について相互トランスポート層セキュリティ (TLS) に依存しています。正常な相互 TLS 認証は、ドメイン セキュリティに使用される TLS 証明書について、信頼されている検証済みの X.509 証明書チェーンに依存します。

したがって、ドメイン セキュリティを正常に展開する前に、エッジ トランスポート サーバーと X.509 公開キー基盤 (PKI) を構成して、信頼する証明書と証明書の検証を用意する必要があります。

important重要 :
暗号化および証明書テクノロジの詳細な説明と概念については、このトピックでは説明しません。信頼、認証、暗号化、公開キーおよび秘密キー交換は暗号化に関連しているため、暗号化と X.509 証明書を使用するセキュリティ ソリューションを展開する前に、これらの基本概念について理解しておくことをお勧めします。詳細については、このトピックの最後の一覧を参照してください。

ルート証明機関の構成

特定の X.509 証明書を検証するには、証明書を発行したルート証明機関 (CA) を信頼する必要があります。ルート CA は最も信頼される CA であり、CA の最上位に位置します。ルート CA は自己署名入りの証明書を持っています。証明書の認証に依存するアプリケーションを実行するときに、各証明書はローカル コンピュータの信頼されたルート コンテナにある証明書で終わる証明書チェーンを持っている必要があります。信頼されたルート コンテナには、ルート証明機関からの証明書が含まれています。

セキュリティで保護されたドメインの電子メールを正常に送信するには、受信側のサーバーの X.509 証明書を検証できる必要があります。同様に、セキュリティで保護されたドメインの電子メールを組織に送信するには、送信側のサーバーが組織の証明書を検証できる必要があります。

ドメイン セキュリティの実装に使用できる信頼されたルート CA には、2 種類があります。それは、組み込みのサード パーティ ルート CA とプライベート ルート CA です。

サード パーティ ルート証明機関

Microsoft Windows には、一組の組み込みサード パーティ ルート CA が含まれています。これらのサード パーティ ルート CA が発行した証明書を信頼する場合、これらの CA が発行した証明書を検証できることを意味します。組織とパートナー組織が既定の Windows インストールを使用していて、組み込みのサード パーティ ルート CA を信頼する場合、信頼は自動的に行われます。このシナリオでは、追加の信頼構成は不要です。

プライベートな信頼されたルート証明機関

プライベートな信頼されたルート CA は、プライベートまたは内部 PKI により展開されたルート CA です。たとえば、組織やセキュリティで保護されたドメインの電子メールを交換する組織が独自のルート証明書を使用して内部 PKI を展開している場合は、追加の信頼構成を作成する必要があります。

プライベート ルート CA を使用する場合、ドメイン セキュリティが正しく機能するには、エッジ トランスポート サーバーにある Windows の信頼されたルート証明書ストアを更新する必要があります。

信頼の構成方法は 2 つあります。それは、直接ルート信頼と相互証明です。トランスポート サービスは、証明書を取得するたびに、その証明書を使用する前に検証することを理解しておく必要があります。したがって、プライベート ルート CA を使用して証明書を発行している場合は、セキュリティで保護されたドメインの電子メールを送受信する各エッジ トランスポート サーバーにある信頼されたルート証明書ストアにプライベート ルート CA を含める必要があります。

直接ルート信頼

プライベート ルート CA により発行された証明書を信頼する場合は、ルート証明書をエッジ トランスポート サーバー コンピュータの信頼されたルート証明書ストアに手動で追加できます。証明書をローカル証明書ストアに手動で追加する方法の詳細については、Microsoft 管理コンソール (MMC) の証明書マネージャ スナップインのヘルプ ファイルを参照してください。

相互証明

相互証明は、ある CA が別の CA により生成された証明書に署名するときに生じます。相互証明は、ある PKI と別の PKI との信頼を構築するために使用されます。ドメイン セキュリティのコンテキストでは、自分の PKI を持っている場合、内部 PKI を持つパートナーのルート機関の直接手動信頼を使用する代わりに、ルート機関の下でパートナー CA の直接証明を作成する場合があります。この場合、相互証明のチェーンが最終的に信頼されたルートに戻るため、信頼が確立されます。

内部 PKI を持っていて、相互証明を使用している場合は、各エッジ トランスポート サーバーが相互証明を通じて信頼したパートナーから電子メールを受信したときに証明書を検証できるように、セキュリティで保護されたドメインの電子メールを受信する各エッジ トランスポート サーバーのルート証明書ストアを手動で更新する必要があることを理解しておく必要があります。

証明書をローカル証明書ストアに手動で追加する方法の詳細については、MMC の証明書マネージャ スナップインのヘルプ ファイルを参照してください。

証明書失効リストへのアクセスの構成

トランスポート サービスは、証明書を取得するたびに、証明書チェーンを検証し、証明書を検証します。証明書の検証は証明書の多くの属性を確認する処理です。これらの属性のほとんどは、証明書を要求するアプリケーションを使用してローカル コンピュータで確認できます。たとえば、証明書の用途、証明書の期限日、および同様の属性は PKI のコンテキストの外部で検証できます。ただし、証明書が失効していないという検証は、証明書を発行した CA が行う必要があります。したがって、ほとんどの CA は失効ステータスを検証できるように証明書失効リスト (CRL) を作成して公開しています。

ドメイン セキュリティを正常に使用するには、ユーザーまたはユーザーのパートナーが使用する CA の CRL をセキュリティで保護されたドメインの電子メールを送受信するエッジ トランスポート サーバーで使用できる必要があります。失効チェックが失敗すると、受信側の Exchange サーバーはメッセージの一時的なプロトコル拒否を発行します。一時的な拒否エラーが発生する可能性があります。たとえば、CRL の発行に使用される Web サーバーが失敗する可能性があります。または、エッジ トランスポート サーバーと CRL 配布ポイントとの間の一般的なネットワーク接続の問題により、失効チェックに失敗する可能性があります。したがって、送信側サーバーが後で再試行するため、一時的な失効エラーのみにより一時的なメール配信の遅延が発生します。ただし、セキュリティで保護されたドメインの電子メール転送が正常に実行されるには、CRL 検証が必要です。

以下のシナリオを有効にする必要があります。

  • エッジ トランスポート サーバーが外部 CA の CRL にアクセスできる必要がある   セキュリティで保護されたドメインの電子メールを交換する各パートナーは、組織のエッジ トランスポート サーバーが接続できる公式に使用可能な CRL を持っている必要があります。場合によっては、CRL は LDAP (ライトウェイト ディレクトリ アクセス プロトコル) でのみ使用可能です。ほとんどの場合、外部 CA と共に、CRL が HTTP により公開されています。エッジ トランスポート サーバーが CRL に接続できるように適切な送信ポートおよびプロキシが構成されていることを確認してください。CRL 配布ポイントが受け付けるプロトコルは、MMC の証明書を開くか、"CRL 配布ポイント" フィールドを参照して判断できます。
  • 証明書を発行する CA の CRL を公式に使用できるようにする必要がある   エッジ トランスポート サーバーはユーザー自身の組織から証明書を取得する場合でも、証明書チェーンを検証して証明書を検証することを理解しておく必要があります。したがって、CA の CRL はユーザー自身のエッジ トランスポート サーバーで使用可能である必要があります。さらに、セキュリティで保護されたドメインの電子メールを交換するすべてのパートナーは証明書を発行する CA の CRL にアクセスできる必要があります。

WinHTTP のプロキシ設定の構成

Exchange 2007 トランスポート サーバーは、Microsoft Windows を基盤とする HTTP サービスに依存して、すべての HTTP および HTTPS トラフィックを管理します。ハブ トランスポート サーバーとエッジ トランスポート サーバーの両方が、HTTP を使用して Microsoft Exchange 2007 Standard のスパム対策フィルタの更新プログラム、Microsoft Forefront Security for Exchange Server スパム対策更新サービス、および CRL 検証のための更新にアクセスできます。

詳細については、「WinHTTP のプロキシ設定を構成する方法」を参照してください。

PKI およびプロキシ構成のテスト

特定のエッジ トランスポート サーバーの PKI およびプロキシ構成を検証するには、Certutil.exe を使用してエッジ トランスポート サーバー証明書の証明書チェーンを検証します。Certutil.exe はコマンドライン ツールです。証明書サービスの一部として Windows Server 2003 オペレーティング システムにインストールされています。詳細については、「PKI およびプロキシの構成をテストする方法」を参照してください。

詳細情報

Exchange 固有の Web サイトを現在運用している証明機関の詳細については、マイクロソフト サポート技術情報の記事番号 929395Exchange 2007 および Communications Server 2007 の統合コミュニケーション証明書のパートナーに関するページを参照してください (このサイトは英語の場合があります)。

暗号および証明書のテクノロジと概念の詳細については、以下の出版物を参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。