Exchange 2007 Server での証明書の使用

  • [アーティクル]

 

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

トピックの最終更新日: 2008-05-19

Microsoft Exchange Server 2007 は証明書を使用して、電子メール通信の多くのパスをセキュリティで保護できるようにします。このトピックでは、Exchange 2007 で証明書をエンド ツー エンドで使用するための概要について紹介します。ここでは、次の内容について説明します。

  • Exchange 2007 で証明書を使用する方法。
  • サード パーティ パブリック証明機関 (CA) から発行された証明書を購入する必要があるかどうか、また、どういう場合が、既定の自己署名入り証明書で十分なのかを判断する方法。
  • Exchange 2007 コンポーネントによる証明書属性の使用方法、および証明書のプロパティと X.509 証明書の拡張フィールドとの関連付け。
  • 証明書の信頼と検証。
  • Exchange 2007 証明書を作成、インポート、および有効化する方法。
  • Exchange コンポーネントが個人用コンピュータ ストアから証明書を選択する方法。

このトピックの各セクションには、Exchange 2007 の証明書関連のドキュメントへの参照とリンクが含まれています。

謝辞   このトピック内容はほとんどが、サポート エンジニアの Stuart Presley によって収集および提供されたマイクロソフト内のメモやドキュメントを元に作成されています。

目次

  • 証明書を使用してセッションを暗号化または認証する Exchange 2007 コンポーネント
  • パブリック CA によって発行された証明書を使用するか、自己署名入りの証明書を使用するかを決定する方法
  • 証明書の属性と Exchange 2007 での各属性の使用方法について
  • 証明書の信頼と検証
  • 証明書の作成、インポート、および有効化
  • 証明書の選択
  • 詳細情報

証明書を使用してセッションを暗号化または認証する Exchange 2007 コンポーネント

Exchange 2007 は、X.509 証明書を使用して、HTTPS、SMTP、POP と IMAP などのプロトコルのために、セキュリティで保護されたトランスポート層セキュリティ (TLS) および SSL (Secure Sockets Layer) トランスポートの通信チャネルをネゴシエートします。

TLS は、ネットワーク経由で通信する 2 つのアプリケーション間で通信のプライバシーとセキュリティを実現するための、インターネット技術標準化委員会 (IETF) の標準プロトコルです。TLS を使用すると、通信が暗号化され、クライアントはサーバーを認証でき、オプションでサーバーがクライアントを認証できます。TLS は、TLS の基になる SSL プロトコルのセキュリティを強化したバージョンです。SSL は、TLS の前に Netscape によって開発されました。この両方のプロトコルは機能的に同等です。また、ほとんどの実装では、古い SSL のみのクライアントとの下位互換性のために、両方のプロトコルがサポートされています。

TLS によってセキュリティ保護された通信は、機密保持 (暗号化) のためにのみ、または機密保持と認証の両方のために使用できます。X.509 証明書は、自己署名入り (自己発行ともいう) の証明書でも、X.509 CA によって発行された証明書でもかまいません。X.509 CA は、証明書を発行するサード パーティ パブリック証明機関か、または組織内に展開されている公開キー基盤 (PKI) のどちらかです。特に記載のない限り、このトピックでは両方のソリューションを証明機関 (CA) と呼びます。サード パーティ パブリック CA は、パブリック CA として知られています。

次の Exchange 2007 コンポーネントは、証明書を使用してセッションを暗号化または認証します。

  • SMTP   証明書は、パートナー組織間のドメイン セキュリティの暗号化と認証のために使用されます。また、ハブ トランスポート サーバーとエッジ トランスポート サーバーの間の直接信頼接続のために使用されます。さらに、SMTP セッションを暗号化するためにハブ トランスポート サーバー間でも使用されます。Exchange 2007 の場合、直接信頼とは、Active Directory ディレクトリ サービスまたは Active Directory アプリケーション モード (ADAM) ディレクトリ サービスに証明書が存在するかどうかによって証明書を検証する認証機能です。Active Directory は、信頼されたストレージ メカニズムと見なされます。証明書はまた、組織間の便宜的な TLS セッションでも使用されます。詳細については、「Exchange 2007 の TLS 機能と関連用語」を参照してください。
  • EdgeSync 同期   Microsoft Exchange EdgeSync サービスが Active Directory からエッジ トランスポート サーバー上の ADAM インスタンスにデータをレプリケートした後、エッジ トランスポート サーバー上の ADAM インスタンスと内部の Active Directory サーバーの間の LDAP 通信セッションを暗号化するために、Exchange 2007 によって作成された自己署名入りの証明書が使用されます。自己署名入りの証明書は、証明書の作成者によって署名された証明書です。Microsoft Exchange EdgeSync サービスは、構成データを Active Directory から購読済みエッジ トランスポート サーバーに定期的にレプリケートするデータ同期サービスです。詳細については、「EdgeSync 同期プロセスについて」を参照してください。
  • POP3 と IMAP4   証明書は、POP3 (Post Office Protocol Version 3) および IMAP4 (Message Access Protocol version 4rev1) クライアントと Exchange サーバーの間のセッションを認証および暗号化するために使用されます。詳細については、「POP3 および IMAP4 のセキュリティの管理」を参照してください。
  • ユニファイド メッセージング   証明書は、ハブ トランスポート サーバーへの SMTP セッション、およびユニファイド メッセージング (UM) IP ゲートウェイと Microsoft Office Communications Server 2007 への SMTP セッションを暗号化するために使用されます。詳細については、「ユニファイド メッセージング VoIP セキュリティについて」を参照してください。
  • 自動検出   証明書は、クライアントとクライアント アクセス サーバーの間の HTTP パスを暗号化するために使用されます。詳細については、「White Paper: Exchange 2007 Autodiscover Service」(英語) を参照してください。
  • クライアント アクセス アプリケーション   証明書は、クライアント アクセス サーバーと、Outlook Anywhere や Microsoft Outlook Web Access のほか、Microsoft Exchange ActiveSync をサポートするデバイスなどの、さまざまな HTTP クライアントの間のパスを暗号化するために使用されます。詳細については、「クライアント アクセスのセキュリティの管理」を参照してください。

Exchange 2007 でデータ パスを暗号化および認証する方法の詳細については、「データ パス セキュリティ リファレンス」を参照してください。

ページのトップへ

パブリック CA によって発行された証明書を使用するか、自己署名入りの証明書を使用するかを決定する方法

このセクションは、Exchange 2007 での証明書の使用方法について簡単に説明することを目的としています。このセクションを読み終えると、有効にしている Exchange コンポーネントとサポート対象のクライアントに基づいて、パブリック CA からどのような種類の証明書を購入する必要があるかを理解できます。また、以降で説明する技術的な内容に関する一般的な背景についても紹介します。

このセクションは、パブリック CA に関する全体的な証明書のニーズをすばやく決定できるようにすることを目的としているため、簡潔に記述されている点を理解することが重要です。簡潔にするため、このセクションの Exchange 2007 での証明書の使用に関する説明では、証明書や関連するテクノロジが一般化されています。このセクションで説明されている概念を理解できない場合は、このトピックの他の部分や参照ドキュメントに必ず目を通してください。

一般には、Kerberos、直接信頼、または NTLM 認証を使用するすべての Exchange 2007 コンポーネントが、自己署名入りの証明書を暗号化で使用できます。このトピックでは、このようなコンポーネントは内部の Exchange 2007 コンポーネントと呼ばれます。内部とは、データ パスが Exchange 2007 サーバー間や、Active Directory によって定義された企業ネットワーク内に存在することを指しています。

ユーザーが、企業のファイアウォールの外部からの認証と暗号化が必要な Exchange コンポーネントにアクセスしている場合は常に、パブリック CA によって発行された証明書を展開することをお勧めします。たとえば、クライアント アクセス サーバーの役割がサポートする、Exchange ActiveSync、POP3、IMAP4、Outlook Anywhere などの各種クライアントはすべて、パブリック CA によって発行された証明書を使用してセキュリティ保護する必要があります。このトピックでは、このようなコンポーネントは外部の Exchange 2007 コンポーネントと呼ばれます。外部とは、クライアントと Exchange 2007 サーバーの間のデータ パスが、企業のファイアウォールを通過してインターネットに延びていることを指しています。

内部コンポーネントによる自己署名入りの証明書の使用

先に説明したように、Exchange 2007 内の多くのコンポーネントが証明書を使用します。一般には、証明書によってセキュリティ保護される内部の Exchange データ パスのすべてに、パブリック CA によって発行された証明書が必要なわけではありません。

内部の SMTP および UM トラフィックはすべて、Exchange 2007 Server のセットアップ プログラムを実行したときにインストールされる自己署名入りの証明書によってセキュリティ保護されます。これらの証明書は New-ExchangeCertificate コマンドレットを使用して毎年更新する必要がありますが、既定の内部の Exchange メッセージング コンポーネントを実行するために、パブリック CA によって発行された証明書を保持する必要はありません。

note注 :
Exchange によって作成された自己署名入りの証明書は、1 年で期限が切れます。既定の自己署名入り証明書に依存する内部コンポーネントは、自己署名入り証明書の期限が切れた場合でも引き続き動作します。ただし、自己署名入り証明書の期限が切れると、イベントがイベント ビューアのログに記録されます。ベスト プラクティスとして、期限が切れる前に自己署名入りの証明書を更新することをお勧めします。

Exchange 2007 には、TLS 証明書を作成、要求、および管理するための一連のコマンドレットが含まれています。これらのコマンドレットの詳細については、後の「証明書コマンドレット」を参照してください。既定では、これらの証明書は自己署名入りです。このトピックで既に説明したように、自己署名入りの証明書は、証明書の作成者によって署名された証明書です。Exchange 2007 では、自己署名入りの証明書は、基になる Windows 証明書 API (CAPI) を使用して Microsoft Exchange を実行しているコンピュータによって作成されます。これらの証明書は自己署名入りの証明書であるため、作成された証明書は一般に、CA によって生成された証明書に比べて信頼性に劣ります。そのため、自己署名入りの証明書は、次の内部のシナリオのためにのみ使用することをお勧めします。

  • ハブ トランスポート サーバー間の SMTP セッション : 証明書が、SMTP セッションの暗号化のためにのみ使用されます。認証は、Kerberos プロトコルによって提供されます。
  • ハブ トランスポート サーバーとエッジ トランスポート サーバーの間の SMTP セッション : 証明書が、STMP セッションの暗号化、および直接信頼証明書のために使用されます。
  • エッジ トランスポート サーバーと Active Directory の間の EdgeSync 同期 : Microsoft Exchange EdgeSync サービスが Active Directory からエッジ トランスポート サーバー上の ADAM インスタンスにデータをレプリケートした後、エッジ トランスポート サーバー上の ADAM インスタンスと内部の Active Directory サーバーの間の LDAP 通信セッションを暗号化するために証明書が使用されます。
  • ユニファイド メッセージング通信 : UM サーバーや UM IP ゲートウェイ、IP 構内交換機 (PBX)、および Office Communications Server 2007 を実行しているコンピュータ間のセッション開始プロトコル (SIP) およびリアルタイム転送プロトコル (RTP) トラフィックを暗号化するために証明書が使用されます。この証明書はまた、ボイス メールまたは FAX メッセージが UM サーバーからハブ トランスポート サーバーに送信されるときに SMTP トラフィックを暗号化するためにも使用されます。
  • 内部クライアントからのみアクセスされるクライアント アクセス サーバー。

Exchange への外部クライアント アクセスにはパブリック CA によって発行された証明書が必要

自己署名入りの証明書は認証のためには使用されないため、内部の Exchange コンポーネントはこれらの証明書に依存できます。ほとんどの Exchange コンポーネントに対する認証は、Kerberos または NTLM によって提供されます。エッジ トランスポート サーバーとハブ トランスポート サーバーの間の通信では、直接信頼証明書が使用されます。この認証は、証明書と、エッジ トランスポート サーバーの公開キーが、信頼されているストアである Active Directory に格納されているという事実によって実現されます。それ以外の場合、自己署名入りの証明書は、Exchange コンポーネント間のデータ パスを暗号化するための短期キーを提供するために使用されます。

ただし、インターネットから、Exchange がホストされているネットワークへの外部クライアント アクセスには、従来から行われている証明書の信頼の検証が必要になります。ベスト プラクティスとして、信頼の検証にはパブリック CA によって発行された証明書を使用することをお勧めします。実際、証明書の認証が必要な場合、自己署名入りの証明書を使用することはベスト プラクティスではありません。この方法は使用しないことを強くお勧めします。パブリック CA からの証明書は、次の目的に使用することをお勧めします。

  • Exchange への POP3 および IMAP4 クライアント アクセス
  • Outlook Web Access
  • Outlook Anywhere
  • Exchange ActiveSync
  • 自動検出
  • ドメイン セキュリティ

これらのすべての場合におけるベスト プラクティスは、既定ですべてのクライアントによって信頼されているパブリック CA を使用することです。

証明書を発行するサード パーティ パブリック CA の仕様に従った証明書要求を生成するには、New-ExchangeCertificate コマンドレットを使用します。

詳細については、以下のトピックを参照してください。

このセクションの他の部分では、購入する必要のあるパブリック証明書の種類、および組織で Exchange 2007 へのアクセスに使用するクライアントをセキュリティで保護するために複数の証明書を購入する必要があるかどうかを決定する方法について説明します。

展開に必要なパブリック CA によって発行された証明書の種類と数の決定

組織に必要なパブリック CA によって発行された適切な証明書の選択は、次の要因によって異なります。

  • 証明書内のワイルドカード名のクライアント サポート   サポートするクライアントについて確認します。先に説明したように、ここでの "クライアント" は、インターネットから Exchange にアクセスするクライアントを指します。
  • 組織の名前空間   インターネットに直接接続されたインターネット インフォメーション サービス (IIS) 名前空間の構成を確認します。
  • 証明書のソース   どこから証明書を取得するか、選択したパブリック CA が、"サブジェクト" または "サブジェクトの別名 (SAN)" フィールドでのワイルドカード文字の使用をサポートしているかどうか、サポートしていない場合は、SAN の使用をサポートしているかどうかを確認します。

以下のセクションでは、これらの要因をより詳細に検証します。

証明書内のワイルドカード名のクライアント サポート

X.509 証明書のサブジェクトまたは SAN 拡張子でワイルドカード名が使用されることがあります。ワイルドカード名の詳細については、後の「証明書の属性と Exchange 2007 での各属性の使用方法について」にある「CertificateDomains」を参照してください。

組織でどのクライアントをサポートするかを決定したら、それらのクライアントが、クライアントが接続するサーバー証明書にワイルドカード名が使用されている証明書をサポートしているかどうかを特定すると役立ちます。

クライアントが証明書でのワイルドカード名の使用をサポートしている場合は、組織の全体的な証明書の計画が大幅に簡略化されます。すべてのクライアントが証明書内のワイルドカード名をサポートし、組織で 1 つのドメイン名を使用している場合は、証明書の展開戦略のために名前空間の計画を検討する必要はありません。代わりに、ワイルドカード文字が含まれた名前空間をサポートする 1 つの証明書を作成することができます。たとえば、Outlook Web Access を実行しているクライアントがメールへのアクセスに mail.contoso.com/owa を使用し、POP3 クライアントがメールへのアクセスに pop.contoso.com を使用している場合は、*.contoso.com というワイルドカードのサブジェクトを含む 1 つの証明書によって両方のクライアントがサポートされます。

次の Microsoft クライアントは、証明書内のワイルドカード名をサポートしています。

  • Outlook

    note注 :
    ワイルドカード証明書がクライアント アクセスの役割を実行している Exchange サーバー間で展開される場合、Outlook 2007 クライアントが正しく接続できるようにするためのいくつかの構成が自動検出設定で必要となります。この問題の詳細と解決方法については、「ワイルドカード証明書による Outlook Anywhere へのクライアント接続の問題」を参照してください。

  • Internet Explorer (Outlook Web Access)

  • Exchange エッジ トランスポート サーバー (ドメイン セキュリティ)

important重要 :
Windows Mobile 5.0 を実行しているクライアントは、証明書にワイルドカード名が使用されているサーバーへの暗号化されたチャネルをサポートしていません。

組織でサポートしているクライアントがサーバー証明書内のワイルドカード名をサポートしておらず、複数のクライアント名前空間をサポートする必要がある場合は、次のいずれかを行う必要があります。

  1. SAN 拡張子に mail.contoso.com、pop.contoso.com、mobile.contoso.com などの複数の名前を含む証明書を購入する。
  2. クライアントが接続する名前空間内の各エンティティの証明書を購入する。

組織の名前空間の計画

すべてのクライアントには、接続先の URL または完全修飾ドメイン名 (FQDN) が必要です。クライアントが接続する各パスは、そのクライアントが接続するホストのホスト名、NetBIOS 名、FQDN、または共通名を含む有効な証明書に関連付けられている必要があります。証明書に含める名前の一覧を決めることは、名前空間の計画のプロセスです。

一般に、さまざまなクライアントをサポートしており、複数のサーバーが含まれた複数の地域にまたがる大規模な組織の名前空間の計画は、小規模な組織の名前空間の計画に比べて複雑です。

Exchange 2007 への受信接続をセキュリティで保護するために使用する証明書の SAN 拡張子にどのホスト名を含めればよいかがわかるように、証明書の名前空間の計画について理解する必要があります。

詳細については、「Exchange Server 2007 の名前空間の計画について」を参照してください。

どの機関から証明書を取得するか

先に説明したように、外部クライアント アクセスのためには、サード パーティ パブリック CA から証明書を購入することをお勧めします。

証明機関を評価する場合は、次の条件を考慮してください。

  • CA で証明書内のワイルドカード名が許可されているかどうか。クライアントが証明書内のワイルドカード名をサポートできる場合は、ワイルドカード名をサポートしている CA からの証明書の購入が、セキュリティで保護されたクライアントを展開するための最も簡単な方法です。
  • CA で SAN 拡張子がサポートされているかどうか。次の条件に当てはまる場合は、SAN 内の複数の名前をサポートしている証明書を使用すると有効なことがあります。
    • 証明書内のワイルドカード名をサポートしていないクライアントをサポートする必要がある。
    • クライアントが接続する必要のあるホスト パスが複数存在する。
      マイクロソフトはパブリック CA と提携して、統合コミュニケーション証明書を提供しています。統合コミュニケーション証明書をサポートしている CA の最新の一覧については、マイクロソフト サポート技術情報の記事 929395「統合通信は、Exchange 2007 と通信サーバー 2007 の Partner を証明書」を参照してください。
  • 高いレベルの正当性チェックを CA が提供しているかどうか。CA の中には非常に安価なものがあります。一方、1 つの証明書に年間数百ドルのコストがかかる CA もあります。組織への受信トラフィックの認証はこの証明書の完全性に依存しているため、コストだけでパブリック CA を選択しないようにすることをお勧めします。決定する前に、各 CA が提供しているサービスと各 CA の評判を慎重に評価し、比較してください。

ページのトップへ

証明書の属性と Exchange 2007 での各属性の使用方法について

証明書のさまざまな属性を理解しておくと、Exchange で証明書を使用する方法を理解するのに役立ちます。この理解がさらに、Exchange 組織での証明書のニーズを計画する際に役立ちます。また、これは問題のトラブルシューティングにも役立ちます。

X.509 証明書には、次の 2 種類の属性があります。

  • 証明書フィールドは、X.509 証明書自体の署名されたデータ内の属性です。これらのフィールドは署名によって完全性が保護されており、証明書に署名し直すか、または証明書を再発行しない限りその値を変更することはできません。
  • 証明書のプロパティは、証明書または秘密キーのメタデータである属性です。証明書の拇印など、プロパティの中には証明書または秘密キーに組み込まれているものがあります。ただし、多くのプロパティは、証明書に署名し直さなくても変更できます。
    たとえば、Enable-ExchangeCertificate コマンドレットを使用すると、証明書が作成された後でそのプロパティにサービスを追加することができます。証明書を IIS (Outlook Web Access や Exchange ActiveSync など)、SMTP (直接信頼やドメイン セキュリティなど)、IMAP、POP、およびユニファイド メッセージングで使用できるようにすることが可能です。証明書を特定のサービスに対して有効にすると、証明書のプロパティが更新されます。詳細については、「Enable-ExchangeCertificate」を参照してください。

これらの属性は、特定の証明書に関する |FL 引数を指定して Get-ExchangeCertificate コマンドレットを実行することで表示できます。Exchange 2007 RTM を実行している場合、すべての属性データを表示するには |FL* 引数を指定してこのコマンドレットを実行する必要があります。

Get-ExchangeCertificate コマンドレットで指定された一部のフィールドおよびプロパティでは、Microsoft 管理コンソール (MMC) の証明書マネージャを使用して表示できる X.509 の拡張フィールドへのマップが出力されます。証明書マネージャの詳細については、「Microsoft 管理コンソールに証明書マネージャを追加する方法」を参照してください。Get-ExchangeCertificate コマンドレットの詳細については、「Get-ExchangeCertificate」を参照してください。

証明書フィールド

先に説明したように、証明書フィールドは X.509 証明書自体の署名されたデータ内の属性です。ここでは、Microsoft Exchange サービスによって使用され、Get-ExchangeCertificate コマンドレットの出力で表示される証明書フィールドについて説明します。

これらのフィールドの中には、New-ExchangeCertificate コマンドレットを使用して新しい証明書または証明書要求を作成するときに設定できるパラメータであるものもあります。New-ExchangeCertificate コマンドレットの詳細については、「New-ExchangeCertificate」を参照してください。

このセクションで示されている各証明書フィールドは、Get-ExchangeCertificate コマンドレットの出力に従って一覧表示されています。このセクションで示されている各 Exchange 証明書フィールドの名前は、X.509 証明書拡張名に対応しています。

発行者

このフィールドには、証明書の発行者を識別するための共通名が含まれています。セットアップ中、または New-ExchangeCertificate コマンドレットを使用して Exchange によって作成された自己署名入りの証明書には、cn=hostname が表示されます。hostname はローカル サーバーの名前です。

CA によって発行された証明書では、通常、"発行者名" フィールドに CA の完全な共通名が表示されます。

X.509 証明書拡張名も Issuer です。

"発行者名" フィールドには、New-ExchangeCertificate コマンドレットで設定できる対応するパラメータはありません。"発行者名" フィールドは、証明書を発行するエンティティによって指定されます。

サブジェクト

このフィールドは、証明書のサブジェクトを識別します。サブジェクトは、通常、証明書を使用するサービスにアクセスするために使用される 1 つの名前を表す X.500 文字列です。証明書が New-ExchangeCertificate コマンドレットによって作成されるときにサブジェクトが明示的に指定されない場合は、サブジェクトが、New-ExchangeCertificate コマンドレットの実行時に DomainName パラメータに指定される最初の値になります。次の X.500 フィールドが存在する可能性があります。

  • C = 国
  • ST = 都道府県
  • L = 場所
  • O = 組織
  • OU = 組織単位
  • CN = 共通名

これらのフィールドの中には、サード パーティ CA に対する証明書要求を生成するときに必要なものがあります。"サブジェクト" フィールドの詳細については、「TLS の証明書または証明書の要求の作成」を参照してください。

ブリッジのために Exchange の前で Microsoft Internet Security and Acceleration (ISA) Server 2006 を実行している場合は、複数の SAN エントリを含む証明書による ISA Server の Web 公開の中断についてのページのブログ投稿 (このサイトは英語の場合があります) に必ず目を通して、サブジェクト名と ISA Server 動作の詳細を確認してください。

note注 :
Wiki およびブログの内容とその URL は、将来予告なしに変更されることがあります。

Exchange がユーザーの引数なしで自己署名入りの証明書を生成する場合は、サブジェクト名 CN=hostname を含む証明書が作成されます。

X.509 証明書拡張名も Subject です。

"サブジェクト" フィールドは、New-ExchangeCertificate コマンドレットで SubjectName パラメータを指定することによって設定します。

CertificateDomains

CertificateDomains フィールドは、証明書に関連付けられたすべての DNS ドメイン名を識別します。DNS ドメイン名はサブジェクトの共通名 (cn=) 属性、または証明書の SAN 拡張子のいずれかで指定できます。Get-ExchangeCertificate コマンドレットの出力には、"サブジェクト" フィールド内のドメインと、SAN 内のすべてのドメインを結合した内容が表示されます。

CertificateDomains フィールド内の値には、サーバーにアクセスするために使用されるホスト名または FQDN が含まれている可能性があります。証明書を使用するには、その証明書の CertificateDomains フィールドに、クライアントがサーバーに接続するために使用する FQDN が指定されている必要があります。

たとえば、クライアントが mail.fourthcofee.com をサーバー名にして POP3 を使用してサーバーに接続している場合は、その POP3 設定に関連付けられた証明書の CertificateDomains フィールドに mail.fourthcofee.com が含まれている可能性があります。

また、*.fourthcofee.com などのワイルドカード名を使用して証明書を検索することもできます。これは許容可能なドメインです。ただし、従来のクライアントやモバイル デバイスの中には、証明書上のワイルドカード名をサポートしていないものもあるため、ワイルドカード ドメインの使用がサポートされていない可能性があることに注意する必要があります。

note注 :
SAN フィールドは、直接 Exchange によっては公開されません。このフィールドは、MMC の証明書マネージャか、またはインターネット インフォメーション サービス (IIS) マネージャを介してのみ表示できます。また、Outlook Web Access、Exchange ActiveSync、または自動検出のために IIS によって使用される証明書などの、Web サイトにバインドされた証明書も IIS マネージャで表示できます。

証明書で SAN やワイルドカード名を使用する方法の詳細については、「TLS の証明書または証明書の要求の作成」を参照してください。また、Exchange チームのブログ、サード パーティの CA で証明書を生成する方法についてのページにも、複数の SAN を含む証明書要求を作成する方法に関する実際的なアドバイスが含まれています (このサイトは英語の場合があります)。

note注 :
Wiki およびブログの内容とその URL は、将来予告なしに変更されることがあります。

X.509 証明書拡張名は Subject Alternative Name ですが、先に説明したように、Get-ExchangeCertificate コマンドレットの出力でも、サブジェクト証明書拡張に含まれている値が CertificateDomains フィールド内の名前の一覧に追加されます。

CertificateDomains フィールドは、New-ExchangeCertificate コマンドレットで DomainName および Subject パラメータを指定することによって設定します。

NotBefore と NotAfter

NotBefore フィールドと NotAfter フィールドの値は、証明書が有効に使用できる日付の範囲を表します。現在の日付が NotAfter の日付より後である場合、証明書は期限が切れていると見なされます。Microsoft Exchange は期限が切れた証明書を引き続き使用できますが、クライアントでは警告が生成され、サーバーではイベント ログに対応するイベントが記録されます。

NotBefore の値に対応する X.509 証明書拡張名は Valid from です。NotAfter に対応する X.509 証明書拡張名は Valid to です。

NotBefore フィールドと NotAfter フィールドには、New-ExchangeCertificate コマンドレットで設定できる対応するパラメータはありません。これらのフィールドは、証明書を発行するエンティティによって定義されます。Exchange セットアップまたは New-ExchangeCertificate コマンドレットによって生成される自己署名入りの証明書は 1 年間有効です。

CertificateRequest

この値は、まだ要求の状態にある証明書にのみ存在します。証明書要求は有効な X.509 証明書ではないため、Exchange では使用されません。

CertificateRequest フィールドは、New-ExchangeCertificate コマンドレットで GenerateRequest パラメータ スイッチを指定することによって有効になります。

証明書のプロパティ

先に説明したように、証明書のプロパティは、証明書または秘密キーのメタデータである属性です。証明書の拇印などの一部のプロパティは証明書または秘密キーに組み込まれていますが、多くのプロパティは、証明書に署名し直さなくても変更できます。

Thumbprint プロパティを除き、X.509 証明書拡張に対応する Exchange 証明書のプロパティはありません。

ここでは、証明書のプロパティについて説明します。

IsSelfSigned

IsSelfSigned プロパティは、証明書が自己署名入りの証明書かどうかを示します。自己署名入りの証明書は、通常、ルート証明書です。これは、証明書チェーンに他の証明書が含まれていない証明書です。Exchange での自己署名入りの証明書は、通常、次の種類の証明書を指します。

  • 有効な証明書が存在しないサーバーに Exchange がインストールされたときに生成される証明書。
  • New-ExchangeCertificate コマンドレットを実行することで生成される証明書。

ハブ トランスポート、エッジ トランスポート、ユニファイド メッセージング、またはクライアント アクセス サーバーの役割がインストールされている場合は、Exchange セットアップによって自己署名入りの証明書が生成されます。ホスト コンピュータ上の個人用証明書ストアに有効な証明書が存在する場合は、その既存の証明書が使用され、Exchange セットアップによって生成された自己署名入りの証明書は使用されません。有効な値は True または False です。

RootCAType

RootCAType プロパティは、この証明書を発行した CA の種類を識別します。IsSelfSigned パラメータが True に設定されている場合、RootCAType プロパティの値は None になります。それ以外の場合は、この証明書のために、証明書選択プロセスで予期しない結果が発生する可能性があります。可能性のあるその他の値は次のとおりです。

  • Registry   証明書ストアに手動でインストールされた内部のプライベート PKI ルート CA。
  • ThirdParty   パブリックのサード パーティ ルート CA。
  • GroupPolicy   グループ ポリシーを使用して展開された内部のプライベート PKI ルート CA。
  • Enterprise   Active Directory を使用して展開された内部のプライベート PKI ルート CA。
  • Unknown   Exchange が、インストールされている証明書の種類を特定できません。

ルート CA 証明書がコンピュータにどのようにインストールされているかを理解しておくと、整合性のない信頼ポリシーを診断する場合に役立つことがあります。このような不整合のために、証明書がサーバーによって有効になったり無効になったりする場合があります。

たとえば、Registry の値は、だれかがあるサーバーにこの証明書を手動でインストールしたことを示します。この証明書が組織内の他のサーバーにインストールされていないと、これにより不整合が発生する場合があります。グループ ポリシーまたは Active Directory を使用して証明書をすべてのコンピュータに配布することをお勧めします。

Services

Services プロパティは、この証明書を使用できるサービスを識別します。有効な値は SMTP、POP、IMAP、UM、および IIS です。

"サービス" フィールドの値は、Enable-ExchangeCertificate コマンドレットで Services パラメータを指定することによって設定します。詳細については、「Enable-ExchangeCertificate」を参照してください。

Status

Status プロパティは、この証明書が有効かどうかを識別します。"状態" フィールドは、証明書の問題をトラブルシューティングしている場合に非常に役立ちます。特定の証明書の Status 値が Valid でない場合、その証明書は Exchange サーバーによってどのサービスにも使用されません。Status プロパティの値には、次のものがあります。

  • Unknown   この状態は一般に、証明書失効リスト (CRL) が使用できないか、またはこのサーバーから接続できないため、この証明書の状態を確認できないことを示します。このコンピュータから証明書失効機関に接続できることを確認してください。詳細については、「WinHTTP のプロキシ設定を構成する方法」を参照してください。
  • Valid   この証明書は正しく機能しています。
  • Revoked   この証明書が取り消されたことを CRL が示しています。新しい証明書を生成する必要があります。
  • DateInvalid   この状態は、システム時刻が正しくないか、証明書の期限が切れたか、またはこのファイルに署名したシステムの時刻が正しくないことを示します。以下の条件を満たすことを確認します。
    • ローカル コンピュータの時計が正確である。
    • 証明書の有効期限が切れていない。
    • 送信側のシステム クロックが正確である。
      証明書の有効期限が切れている場合は、新しい証明書を作成する必要があります。
  • Untrusted   この状態は、この証明書が自己署名入りの証明書でないことを示します。ただし、この証明書は、ローカル コンピュータには信頼されていない CA によって署名されています。この CA 証明書を、コンピュータ上の信頼されたルート証明機関ストアに追加する必要があります。証明書をローカル証明書ストアに手動で追加する方法の詳細については、MMC の証明書マネージャのヘルプ ファイルを参照してください。
  • Invalid   証明書パスのどこかに信頼されていない証明書、無効な証明書、または取り消された証明書があるなど、何らかの問題によってこの証明書が無効になっています。

その他のトラブルシューティング情報については、以下のトピックを参照してください。

HasPrivateKey

HasPrivateKey プロパティは、インストールされている証明書に秘密キーが含まれているかどうかを示します。Microsoft Exchange Transport サービス、Microsoft Exchange POP3 サービス、および Microsoft Exchange IMAP4 サービスは秘密キーが含まれていない証明書を使用しないため、このプロパティは非常に重要です。

Thumbprint

Thumbprint プロパティは、証明書を識別するための一意の文字列です。複数の Exchange サーバーに同じ証明書がインストールされている場合は、証明書の拇印によって各証明書を識別できます。複数の Exchange サーバーに同じ証明書がインストールされているのは、通常、複数のエッジ トランスポート サーバーが mail.fourthcoffee.com などの同じ FQDN を持つメールを受け付けている場合です。複数のサーバーに同じ証明書をインストールする方が、サーバーごとに新しい証明書を要求するより費用対効果ははるかに高くなります。ただし、証明書にエクスポート可能な秘密キーが含まれている必要があります。

Thumbprint プロパティは、次のコマンドレットの証明書を指定するために使用されます。

Thumbprint プロパティに対応する X.509 証明書拡張名も Thumbprint です。

ページのトップへ

証明書の信頼と検証

証明書を使用して認証するには、その証明書が検証され、かつ信頼されている必要があります。

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

証明書は、別の証明書によって CA にチェーンされます。また、その証明書も CA によって発行されているために、そこにチェーンされる可能性があります。この証明書のチェーンは、証明のパスとも呼ばれます。証明書が有効になるには、証明のパス内のすべての証明書が有効である必要があります。また、チェーンの最上位に位置する証明書は、信頼されたルート CA である必要があります。

証明書の認証に依存するアプリケーションを実装するために使用できる信頼されたルート CA には、サード パーティ パブリック ルート CA とプライベート ルート CA の 2 種類があります。

サード パーティ パブリック ルート証明機関

Windows、Windows Mobile、および各種のサード パーティ製のオペレーティング システムには、一連の組み込みのサード パーティ パブリック ルート CA が含まれています。これらのサード パーティ パブリック ルート CA によって発行された証明書を信頼している場合は、これらの CA によって発行された証明書を検証できます。

次の条件に当てはまる場合、信頼は自動的に行われます。

  • 組織で既定の Windows インストールを使用している。
  • 組織で使用されているクライアント ソフトウェアやモバイル デバイスも、組み込みのサード パーティ パブリック ルート CA を信頼している。

この場合は、追加の信頼構成は必要ありません。

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

プライベートな信頼されたルート CA は、プライベートまたは内部 PKI により展開されたルート CA です。たとえば、組織で独自のルート証明書を使用して内部 PKI を展開している場合は、追加の信頼構成を行う必要があります。

一般に、組織への外部からの接続をサポートしているクライアント アプリケーションに、プライベート PKI によって発行された証明書を使用することはベスト プラクティスではありません。

プライベート ルート CA が使用されている場合は、証明書の認証が必要なすべてのデバイス、クライアント、および Windows オペレーティング システム上で、Windows の信頼されたルート証明書ストアを更新する必要があります。

信頼の構成方法は 2 つあります。それは、直接ルート信頼と相互証明です。

直接ルート信頼

プライベート ルート CA によって発行された証明書を信頼する場合は、そのルート証明書を、Windows を実行しているコンピュータ上の信頼されたルート証明書ストアに手動で追加できます。また、場合によっては、モバイル クライアントの信頼されたルート ストアにルート証明書を追加することもできます。証明書を、Windows を実行しているコンピュータ上のローカル証明書ストアに手動で追加する方法の詳細については、MMC の証明書マネージャのヘルプ ファイルを参照してください。Windows Mobile デバイスに証明書をインストールする方法の詳細については、Windows Mobile ベースのデバイスにルート証明書をインストール方法についてのページを参照してください (このサイトは英語の場合があります)。

important重要 :
ユーザーは Exchange にアクセスするために使用するすべてのコンピュータとデバイスに、証明書をインストールできるわけではありません。たとえば、ユーザーの中には、キオスクまたは友人のコンピュータから Outlook Web Access にアクセスする人がいます。この場合、そのユーザーは警告を受けますが、自分のメールへのアクセスが妨げられるわけではありません。この動作によって、事実上、ユーザーは証明書の警告を無視することになります。つまり、これはベスト プラクティスではありません。信頼されたサード パーティ CA から発行されている証明書を使用することがベスト プラクティスです。

相互証明

相互証明は、ある CA が、別の CA によって生成された証明書に署名する場合に発生します。相互証明は、ある PKI と別の PKI との信頼を構築するために使用されます。独自の PKI を保持している場合は、別のプライベート PKI のルート CA に対する直接の手動による信頼を使用する代わりに、ルート CA の下にある他の CA に対するクロス証明書を作成することができます。この場合は、このクロス証明書のチェーンが最終的に信頼されたルート CA に戻るため、信頼が確立されます。

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

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

証明書を使用して正常に認証するには、使用している CA の CRL が、クライアントを認証しているサービスで使用できる必要があります。失効状態の確認が失敗すると、認証しているサービスが失敗します。

認証しているサーバーが、外部 CA の CRL にアクセスできる必要があります。

すべてのパブリック CA が、組織のサーバーから接続できる公式に使用可能な CRL を持っています。場合によっては、プライベートな内部 PKI の CRL は、LDAP (ライトウェイト ディレクトリ アクセス プロトコル) でのみ使用可能です。ほとんどの場合、パブリック CA では、CRL は HTTP を使用して公開されています。サーバーとクライアントが CRL に接続できるように、適切な送信ポートとプロキシが構成されていることを確認してください。特定の CRL 配布ポイントが受け付けるプロトコルは、MMC で証明書を開き、"CRL 配布ポイント" フィールドを表示することによって特定できます。

場合によっては、証明書を発行する CA の CRL を公式に使用可能にしなければならないことがあります。たとえば、ドメイン セキュリティを展開している場合は、エッジ トランスポート サーバーがユーザー自身の組織から証明書を取得するときでも、証明書チェーンを検証して証明書を検証することを理解しておく必要があります。したがって、CA の CRL はユーザー自身のエッジ トランスポート サーバーで使用可能である必要があります。さらに、セキュリティで保護されたドメインの電子メールを交換するすべてのパートナーは証明書を発行する CA の CRL にアクセスできる必要があります。

WinHTTP のプロキシ設定の構成

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

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

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

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

ページのトップへ

証明書の作成、インポート、および有効化

Exchange 2007 にインストールされ、機能している証明書を取得するには、いくつかの方法があります。どの方法を選択するかは、ニーズによって異なります。Exchange 2007 は、既定の構成をセキュリティで保護できるようにするために、一連の自己署名入り証明書を生成します。システムのセキュリティを保証するには、一定の期間ごとに、これを更新していく必要があります。Exchange では、証明機関による署名要求が自動的に生成されることはありません。新しい自己署名入り証明書、または証明機関に対する証明書要求のどちらを作成するかにかかわらず、両方とも同じコマンドレットを使用します。

ここでは、Exchange 2007 によって使用される証明書に関して実行できる操作の概要について説明します。このセクションは、ExchangeCertificate コマンドレットに精通していない場合にお読みください。このドキュメントの後半で、アプリケーション固有の例と手順について、POP3 を例に挙げて説明しています。このセクションでは、また、アプリケーション固有のドキュメントへのリンクも示しています。

証明書コマンドレット

以前のバージョンの Exchange Server では、すべての証明書管理が IIS および MMC の証明書マネージャを介して実行されました。Exchange 2007 では、Exchange に関連するほとんどの証明書管理タスクを、Exchange 管理シェルで以下の ExchangeCertificate コマンドレットを使用して実行します。

  • New-ExchangeCertificate   このコマンドレットは、自己署名入りの証明書および証明機関に対する証明書要求を生成します。
  • Import-ExchangeCertificate   このコマンドレットは、以前にエクスポートされた証明書をインポートしたり、CA によって生成された証明書ファイルをインポートしたりします。
  • Export-ExchangeCertificate   このコマンドレットは、バックアップのため、または複数のサーバーで使用するために証明書をエクスポートします。
  • Enable-ExchangeCertificate   このコマンドレットは、証明書での特定のサービスを有効にします。
  • Get-ExchangeCertificate   このコマンドレットは、証明書の属性を表示します。
  • Remove-ExchangeCertificate   このコマンドレットは、Exchange Server およびローカル証明書ストアから証明書を削除します。

証明機関に対する証明書要求を作成する方法の詳細については、「TLS の証明書または証明書の要求の作成」を参照してください。

以下のセクションでは、一般的な証明書タスクを実行するために ExchangeCertificate コマンドレットをどのように使用するかを説明した簡単な例を紹介します。詳細情報および例については、「グローバル コマンドレット」にある ExchangeCertificate コマンドレットのヘルプを参照してください。

自己署名入りの証明書の生成

Server1 のホスト名と fourthcoffee.com のドメインを持つサーバー用に SMTP サービスで使用する自己署名入りの証明書を生成するには、次のコマンドを実行します。

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

自己署名入りの証明書の複製

既存の自己署名入り証明書を更新する必要がある場合は、次のコマンドを実行して証明書を複製することができます。

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

thumbprint プレースホルダは、更新される証明書の拇印です。また、次のように、このコマンドで新しい証明書のサービスを指定することもできます。

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

その後、次のコマンドを実行すると、この証明書を有効にできます。

Enable-ExchangeCertificate <thumbprint>

証明書要求の作成および信頼された証明書のインストール

パブリックのサード パーティ証明書のインストールは、より複雑なプロセスになります。証明書要求を生成し、発行された証明書と必要なすべての CA 証明書をインポートしてから、発行された証明書を、目的とする用途のために有効にする必要があります。

ここでは、1 つの例として、POP3 サービスを、証明書で使用するために有効にする方法について説明します。この例では、クライアントは popserver.fourthcoffee.com の FQDN に接続することによって、POP3 サービスに接続します。

証明書要求

生成された証明書はパブリックのサード パーティ CA から送られてくるため、最初に、次のコマンドを実行して証明書要求を生成する必要があります。

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

証明書要求が正しく生成された場合は、システム ドライブのルートに証明書要求ファイル (.cer または .der) が作成され、その要求の拇印が Exchange 管理シェルに表示されます。

note注 :
プロバイダから返される証明書は、証明書要求ファイルの拡張子 (.der や .cer など) とは異なる拡張子をサポートしています。これらの拡張子は、証明書ファイルで使用されるエンコーディング方法を表しています。既定では、New-ExchangeCertificate 要求は Base64 でエンコードされたファイル (.cer) を作成します。.der ファイルを作成するには、BinaryEncoded パラメータ スイッチを使用してください。

前のコマンドでは、PrivateKeyExportable パラメータが $True に設定されていました。これにより、同じ FQDN でのアクセスが必要になる可能性のある複数の Exchange サーバーで使用するために、この証明書を秘密キーと共にエクスポートできるようになります。たとえば、POP3 接続をサポートするために、複数のクライアント アクセス サーバーが負荷分散される可能性があります。

note注 :
PrivateKeyExportable パラメータは省略可能です。このパラメータは、信頼された CA に対する証明書要求を生成する場合にのみ指定する必要があります。PrivateKeyExportable パラメータを $True に設定すると、証明書とそれに関連付けられたキーを移動したりアーカイブしたりすることができます。自己署名入りの証明書では、これは必要はありません。

前のコマンドでは、また、X.500 名として Subjectname パラメータを指定しています。ほとんどのサード パーティ CA で、証明書のサブジェクト名として有効な X.500 名を指定する必要があります。また、少なくとも、ほとんどの CA で、organizationName (o=) フィールドに示されている組織が Web サーバーの commonName (cn=) に現れるドメイン名を所有している必要があります。

要求が完成したら、証明書を取得するために要求ファイルを証明書ベンダに送信できます。

note注 :
Get-ExchangeCertificate コマンドレットは証明書だけでなく、要求が保留中の証明書も返します。この 2 つを区別するために、証明書要求には、証明書要求ファイルに格納されている出力を表示する CertificateRequest 属性が含まれています。この出力は、証明書要求ファイルを誤って削除した場合や、パラメータを指定せずに要求を生成した場合に役立つことがあります。CertificateRequest のデータは base64 でエンコードされているため、ファイルにコピーし、証明書要求のために CA に送信することができます。

証明書のインポート

CA から証明書が返されたら、それを Exchange サーバーにインポートする必要があります。New-ExchangeCertificate コマンドレットで生成された要求を使用して取得した証明書を正しくインポートするには、次のコマンドを実行します。

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

証明書が正常にインポートされた場合は、このコマンドによって、特定のサービスを有効にするために使用できる証明書の拇印が返されます。

important重要 :
証明書は、その証明書要求を生成したのと同じコンピュータにインポートする必要があります。また、MMC の証明書マネージャを使用して Exchange 証明書をインポートしないでください。

証明書の有効化

証明書を有効にすると、特定の証明書をどのサービスで使用できるかを指定できます。次のコマンドは、発行された証明書を POP3 サービスに対して有効にしています。

Enable-ExchangeCertificate <thumprint> -Services:"POP"

次のコマンドを実行すると、証明書のインポートと有効化を同時に行うことができます。

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

証明書のインストールの検証

必要なすべての手順が完了し、証明書がインストールされて機能していることを確認するには、次のコマンドを実行します。

Get- ExchangeCertificate <thumbprint> | fl *
note注 :
Exchange 2007 SP1 以降のバージョンを実行している場合は、コマンド引数にアスタリスク (*) を含めないでください。

このコマンドの出力によって、次のようなデータが返されます。

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

このコマンドの出力を調べて、以下の情報が正しいことを検証します。

  • 存在すると想定しているドメイン名が CertificateDomains フィールドに一覧表示されている。
  • HasPrivateKey プロパティが True に設定されている。
  • RootCAType プロパティが正しく設定されている。RootCAType プロパティの詳細については、このドキュメントの前の方にある「証明書のプロパティ」を参照してください。
  • 証明書に必要なサービスが有効になっている。
  • Status が Valid に設定されている。

証明書サービス

証明書で POP、IMAP、IIS、SMTP などのサービスを有効にすることができます。サービスは、証明書自体にあるフィールドではありません。サービスは、証明書のメタデータ プロパティです。そのため、サービスは証明書を無効にしなくても変更できます。

サービスを有効にすると、構成の変更が、IIS メタベース内、ファイル システム内、IMAP4 や POP3 の設定上など、他のコンポーネントでも発生します。ここでは、Enable-ExchangeCertificate コマンドレットを実行して特定のサービスを有効にした場合に発生する構成の変更について説明します。

POP と IMAP

証明書にサービスとして POP または IMAP が追加されると、POPSettings オブジェクトまたは IMAPSettings オブジェクト上の x509CertificateName 属性が、その証明書のサブジェクト内のドメインを含むように更新されます。

たとえば、POPSettings オブジェクトが更新されたことを検証するには、次のコマンドを実行します。

Get-POPSettings | fl *
note注 :
Exchange 2007 SP1 以降のバージョンを実行している場合は、コマンド引数にアスタリスク (*) を含めないでください。

IIS

IIS を有効にすると、既定の IIS Web サイトがこの特定の証明書を使用するように更新されます。

Enable-ExchangeCertificate コマンドレットを使用して証明書で IIS を有効にできるのは、既定の IIS Web サイトの場合だけです。既定の IIS Web サイト以外の Web サイトで Outlook Web Access または自動検出をホストしている場合は、IIS マネージャを使用して、これらの Web サイトに特定の証明書を関連付ける必要があります。

SMTP

証明書で SMTP サービスを有効にすると、ネットワーク サービス アカウントに、Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys ディレクトリ内の適切な秘密キー ファイルへの読み取りアクセスが許可されます。この処理によって、Microsoft Exchange Transport サービスが TLS によってセキュリティ保護されたメッセージにアクセスしたり、秘密キーを使用してそれらのメッセージを解読したりするために必要なアクセス許可が提供されます。

Microsoft Exchange ユニファイド メッセージング サービス

証明書で Microsoft Exchange ユニファイド メッセージング サービスを有効にすると、その証明書のプロパティがユニファイド メッセージングを含むように更新されます。この証明書は、次の条件に当てはまる場合に使用されます。

  • コンピュータにユニファイド メッセージング サーバーの役割がインストールされている。
  • この証明書に、CertificateDomains 証明書フィールド内のローカル コンピュータの物理 FQDN が含まれている。

ページのトップへ

証明書の選択

証明書の選択は、Exchange コンポーネントが、受信接続にどの証明書を使用する必要があるかを決定するためのプロセスです。SMTP STARTTLS、POP3、および IMAP4 はすべて、特定のセッションに使用する証明書を決定するために同様の選択プロセスを実行します。このプロセスの手順は、ほぼ確定的と言えます。ただし、場合によっては、コンピュータに複数の証明書がインストールされている場合は特に、わかりにくいことがあります。

ここでは、SMTP STARTTLS、SMTP X-AnonymousTLS、POP3、および IMAP4 の証明書選択プロセスについて説明します。トランスポート固有の証明書選択の詳細については、「SMTP TLS 証明書の選択」を参照してください。

SMTP STARTTLS

STARTTLS は、セキュリティで保護された TLS セッションを開始するための SMTP コマンドです。STARTTLS は、Exchange を実行しているコンピュータに有効な証明書が存在する場合に、Exchange によってのみ通知されます。

STARTTLS を通知または使用するために、Exchange は FQDN と、証明書の CertificateDomains フィールド内の一致する値に基づいて証明書を選択します。この FQDN は、次の情報に基づいています。

  • 送信 STARTTLS   この証明書は、送信コネクタ上の FQDN の値に基づいて選択されます。
  • 受信 STARTTLS   この証明書は、受信コネクタ上の FQDN の値に基づいて選択されます。
    note注 :
    送信 STARTTLS と受信 STARTTLS で、コネクタの FQDN が指定されていない場合は、Exchange サーバーの物理 FQDN が照合に使用されます。

FQDN が決定されると、Exchange は、ホスト コンピュータ上の個人用証明書ストアからすべての有効な証明書を検索します。証明書が TLS の使用に対して有効なのは、以下のすべての要件を満たしている場合です。

  • Enhanced Key Usage フィールドにサーバー認証オブジェクト識別子 (OID ともいう) が含まれているか、またはこのフィールドが NULL である。
  • PKI 証明書拡張に、少なくとも 1024 ビットの RSA キーがリストされている。
  • この証明書で証明書チェーンが信頼されたルートまで検証されているか、またはこの証明書が自己署名入りの証明書である。
  • この証明書と証明書チェーンが有効であることが、失効状態の確認によって確認されている。
  • 秘密キーが存在し、使用可能である。
  • 秘密キーがリムーバブル デバイスに格納されていない。
  • 秘密キーがパスワードで保護されていない。

複数の有効な証明書が見つかった場合、Exchange は、次の条件に基づいて証明書を選択します。

  • NotBefore フィールドの値   Exchange は、最新の有効な証明書を選択します。
  • 信頼された CA によって発行された証明書と自己署名入りの証明書の比較   Exchange は、信頼された CA によって発行された証明書を自己署名入りの証明書より優先して選択します。

ほとんどの場合、Exchange は証明書の寿命には関係なく、信頼された CA によって発行された証明書を自己署名入りの証明書より優先して選択します。有効な証明書が見つからない場合、STARTTLS は通知されません。

SMTP X-AnonymousTLS

X-AnonymousTLS は、2 台のハブ トランスポート サーバーの間、およびハブ トランスポート サーバーとエッジ トランスポート サーバーの間の通信をセキュリティで保護するために使用されます。Exchange 2007 SP1 では、証明書が見つからない場合は、このセッションのために一時的な暗号化キーが生成されるように証明書選択プロセスが簡略化されています。

Exchange は、内部トランスポート証明書を検索します。有効な内部トランスポート証明書が見つからない場合、Exchange は有効な CA 証明書を検索します。

そのため、Kerberos プロトコルが認証のために使用されているハブ間通信では、有効な内部トランスポート証明書が存在しなくても SMTP セッションが失敗することはありません。SMTP セッションは、一時的な暗号化キーを使用して暗号化されます。この場合は、イベントがログに記録されるため、そのイベントを生成しているコンピュータで、引数を指定しないで New-ExchangeCertificate コマンドレットを実行することによって新しい内部トランスポート証明書を作成する必要があります。

エッジ トランスポート サーバーが組織に購読されているハブとエッジの間の通信では、有効な内部トランスポート証明書が見つからないとセッションが失敗し、エラーがログに記録されます。この場合は、そのイベントを生成しているコンピュータで、引数を指定しないで New-ExchangeCertificate コマンドレットを実行してから、再度 Microsoft Exchange EdgeSync サービスを実行する必要があります。

POP3 と IMAP4

SMTP STARTTLS の証明書選択プロセスと同様に、POP3 と IMAP4 のプロセスでは、Exchange は FQDN を選択し、CertificateDomains フィールド内の一致する値に基づいて証明書を見つける必要があります。この FQDN は、POP3 または IMAP4 サービスの設定にある X509CertificateName 属性に基づいて選択されます。X509CertificateName 属性は、Get-POPSettings コマンドレットまたは Get-IMAPSettings コマンドレットを実行することによって表示できます。詳細については、「Get-POPSettings」および「Get-IMAPSettings」を参照してください。

Exchange 2007 SP1 での POP3 と IMAP4 の選択プロセスは、SMTP STARTTLS のプロセスと同じです。

note注 :
Exchange 2007 RTM では、POP3 と IMAP4 の証明書選択プロセスに 2 つの主な例外があります。信頼された CA によって発行された証明書が、自己署名入りの証明書より優先されることはありません。代わりに、Exchange 2007 は最新の証明書を選択します。また、Exchange 2007 RTM では、POP3 と IMAP4 で証明書上のワイルドカード ドメインがサポートされていません。つまり、POP3 設定または IMAP4 設定のどちらかで X509CertificateName 属性が mail.fourthcoffee.com に設定されている場合、証明書ドメインとして *.fourthcoffee.com のみを含む証明書は Exchange 2007 ではサポートされません。

ユニファイド メッセージング

Microsoft Exchange ユニファイド メッセージング サービスがセキュリティで保護されたモードで開始された場合、このサービスは、暗号化を有効にするために TLS で使用する有効な証明書をローカルの個人用証明書ストアで検索します。Microsoft Exchange ユニファイド メッセージング サービスは最初に、プライベート PKI またはパブリック CA によって発行された有効な証明書を検索します。適切な証明書が見つからない場合は、自己署名入りの証明書を検索します。PKI、パブリック、または自己署名入りの証明書が見つからない場合、Microsoft Exchange ユニファイド メッセージング サービスは、セキュリティで保護されたモードで開始するために使用する自己署名入りの証明書を作成します。UM サーバーがセキュリティで保護されていないモードで開始している場合、証明書は必要ありません。

セキュリティで保護されたモードで開始するときに使用された証明書の詳細はすべて、証明書が使用されるたびに、または証明書が変更された場合にログに記録されます。ログに記録される詳細には、次のようなものがあります。

  • 発行者名
  • シリアル番号
  • 拇印

この拇印は、SHA1 (Secure Hash Algorithm) ハッシュです。拇印を使用すると、使用されている証明書を一意に識別できます。Microsoft Exchange ユニファイド メッセージング サービスがセキュリティで保護されたモードで開始するために使用した証明書をローカル証明書ストアからエクスポートし、この証明書を、ネットワーク上のユニファイド メッセージング IP ゲートウェイおよび IP PBX の信頼された証明書ストアにインポートすることができます。

適切な証明書が見つかって使用された後、Microsoft Exchange ユニファイド メッセージング サービスは、使用されている証明書の期限が切れる 1 か月前にイベントをログに記録します。この期間中に証明書に何も変更を加えない場合、Microsoft Exchange ユニファイド メッセージング サービスはこの証明書の期限が切れるまでの毎日と、この証明書の期限が切れた後の毎日、イベントをログに記録します。

ユニファイド メッセージング サーバーが、暗号化されたチャネルを確立するために相互 TLS で使用する証明書を検索するときは、信頼されたルート証明書ストアを調べます。発行者が異なっている有効な証明書が複数存在する場合、ユニファイド メッセージング サーバーは、有効期限までの期間が最も長い有効な証明書を選択します。複数の証明書が存在する場合、ユニファイド メッセージング サーバーは、発行者とその証明書の期限が切れる日付に基づいて証明書を選択します。ユニファイド メッセージング サーバーは、次の優先順序で有効な証明書を検索します。

  1. 有効期間が最も長い PKI またはパブリック証明書
  2. 有効期間が最も短い PKI または商用証明書
  3. 有効期間が最も長い自己署名入りの証明書
  4. 有効期間が最も短い自己署名入りの証明書

ページのトップへ

詳細情報

このトピックでは、以下のドキュメントが参照されています。

ページのトップへ

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