直接信頼証明書のエラー 1037 と 2019 のトラブルシューティングを行う方法

  • [アーティクル]

 

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

トピックの最終更新日: 2007-09-13

ここでは、イベント 1037 とイベント 2019 のトラブルシューティングについて説明します。これらのイベントは、直接信頼証明書に関連しています。

イベント 1037 とイベント 2019 は、Microsoft Exchange がこれらのイベントが発生したコンピュータで内部トランスポート証明書 (直接信頼証明書とも呼ばれます) を検証しようとしたときに問題が発生したことを示す警告イベントです。Microsoft Exchange Server 2007 では、直接信頼とは、Active Directory ディレクトリ サービスまたは Active Directory アプリケーション モード (ADAM) ディレクトリ サービスに証明書が存在するかどうかによって証明書を検証することです。Active Directory は、信頼されたストレージ メカニズムと見なされます。直接信頼を使用する場合は、証明書が自己署名されているか、または証明機関によって署名されているかはどちらでもかまいません。

既定では、Microsoft Exchange は、サード パーティのカスタム証明書を使用する代わりに、Microsoft Exchange によりインストールされる自己署名入りの証明書を使用します。ただし、直接信頼のためにカスタム証明書を使用できます。

イベント 1037 とイベント 2019 によって示される問題は、次のうち該当する 1 つ以上の条件が原因になっています。

  • SMTP (簡易メール転送プロトコル) サービスが証明書で有効になっていない。既定では、自己署名入りの内部トランスポート証明書の SMTP サービスは有効になっています。このため、直接信頼のために使用するカスタム証明書がインストールされている場合に、SMTP サービスが有効になっていない可能性があります。
  • ネットワーク サービス アカウントに C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys ディレクトリのキーに対する適切なアクセス許可がない。"C:\" は Exchange 2007 がインストールされているディレクトリです。
  • DNS またはマシン名の構成が正しくないため、証明書の選択プロセスにあるホスト名の照会に失敗した。
  • ハブ トランスポート サーバーの役割が、ネットワーク負荷分散 (NLB) を使用するように構成されている。ハブ トランスポート サーバー間の通信などのシナリオで Exchange Server 認証を行う場合、ハブ トランスポート サーバーの役割はクラスタまたは NLB 構成でサポートされません。NLB を使用すると、証明書の検証中にホスト名の照会に失敗することがあります。

開始する前に

この手順を実行するには、使用するアカウントに以下が委任されている必要があります。

  • Get-ExchangeCertificate コマンドレットを実行するための Exchange 表示専用管理者の役割
  • New-ExchangeCertificate コマンドレットまたは Enable-ExchangeCertificate コマンドレットを実行するための、Exchange サーバー管理者の役割と対象サーバーのローカルの Administrators グループ
  • Filemon (Filemon.exe) を実行するための、対象サーバーのローカルの Administrators グループ

エッジ トランスポート サーバーの役割がインストールされているコンピュータでこれらのコマンドレットまたは Filemon を実行するには、そのコンピュータのローカルの Administrators グループのメンバであるアカウントを使用してログオンする必要があります。

Exchange 2007 を管理するために必要なアクセス許可、役割の委任、および権限の詳細については、「アクセス許可に関する考慮事項」を参照してください。

手順

警告イベントを解決するには、以下の処理を 1 つ以上実行します。

  • SMTP サービスが証明書で有効になっていることを確認します。

    Exchange 管理シェルで次のコマンドレットを実行します。

    Get-ExchangeCertificate | fl *

    note注 :
    Exchange Server 2007 Service Pack 1 以降を実行している場合は、コマンド引数にアスタリスク (*) を含めないでください。

    コンピュータにインストールされているすべての証明書の詳細が出力されます。

    • IsSelfSign 属性の値が True である場合、その証明書は Microsoft Exchange によってインストールされた自己署名入りの証明書です。自己署名入りの証明書はサーバーに複数インストールできます。ただし、最新のタイムスタンプを持つ有効な証明書だけが使用されます。
    • IsSelfSign 属性の値が False である場合、その証明書はサード パーティの証明書またはカスタマイズされた証明書です。

    Services 属性に値 SMTP が含まれていない場合は、Exchange 管理シェルで次のコマンドレットを実行します。

    Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP
    note注 :
    このコマンドにより、証明書で既に有効になっているすべてのサービスに SMTP が追加されます。既存のサービスが削除されることはありません。

  • ネットワーク サービス アカウントは適切なアクセス許可を持っているかどうかを確認します。ネットワーク サービス アカウントに C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys ディレクトリのすべてのキーに対する読み取りアクセス許可が付与されていることを確認します。"C:\" は Exchange 2007 がインストールされているディレクトリです。

    note注 :
    Filemon を使用して、これがアクセス許可の問題であるかどうかを判断することもできます。

  • Filemon を起動し、発生するエラーを取得します。結果のログ ファイルに access denied イベントがないかどうかを確認します。ローカル DNS 構成で構成したパラメータが直接信頼証明書の検証プロセスで使用する基準と一致することを確認します。直接信頼のために証明書が必要になるため、ローカル DNS 構成を Microsoft Exchange によってインストールされた自己署名入りの証明書と比較する必要があります。内部トランスポート証明書の検証プロセスでは、次の DNS 構成設定を確認します。

    • DnsFullyQualifiedDomainName
    • DnsHostName
    • DnsPhysicalFullyQualifiedDomainName
    • DnsPhysicalHostName

    証明書の基準は Exchange トラブルシューティング アシスタントのトレースを使用して確認できます。それには、次のコンポーネントとタグを使用します。

    • Common\Certificate
    • NetworkingLayer\Certificate
    • Transport\Certificate

    Exchange トラブルシューティング アシスタントのトレースにより生成される出力は、完全修飾ドメイン名 (FQDN) が自己署名入りの証明書で構成されているドメインと一致するかどうかを識別する際に利用できます。FQDN が一致しない場合は、正しく構成されていない可能性があります。この場合は、証明書がデータを抽出している場所を確認する必要があります。

  • Exchange サーバーが NLB 環境で実行されている場合は、直接信頼証明書の検証プロセスを実行中に予期しない FQDN が追加されることがあります。予期しないドメインを見つけた場合は、NLB 構成を確認し、予期しないドメインがそこで構成されているかどうか確認します。NLB 構成に予期しない FQDN がある場合は、証明書の検証に失敗しないように NLB 構成を変更します。

詳細情報

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

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