【解決方法】システム イベント ID 36882 (Schannel)について

PKI

システム イベント (ソース:Schannel) ID 36882 は SSL/TLS 通信に関するエラー イベント ログです。
今回は、ID 36882 のイベント ログの意味や確認すべきポイントについて紹介します。

この問題を解決するには、SSL/TLS の基本知識が必要です。
また、SSL/TLS の一般的な仕組みについては、以下の記事で紹介していますのでご参照ください。

関連記事

インターネット上で通信を暗号化して送信し、他の人に見られないように安全に通信を行うためのプロトコルである SSL/TLS の概要について説明します。 SSL/TLS とは SSL/TLS とはインターネット等の通信ネットワークにおいて、[…]

関連記事

SSL/TLS では暗号化通信を開始する前に、SSL/TLS ハンドシェイクと呼ばれるやりとりを行い、暗号化通信を行うにあたって必要な情報を交換し、暗号化通信を確立します。 SSL/TLS ハンドシェイクにて、クライアントとサーバー間で暗[…]

 

イベント ID 36882 の概要

システム イベント ログに以下のようなエラー ログが記録されていることがあります。

ログの名前: System
ソース: Schannel
日付: YYYY/MM/DD HH:MM:SS
イベント ID: 36882
タスクのカテゴリ: なし
レベル: エラー
キーワード:
ユーザー: <ユーザー ID>
コンピューター: <コンピューター名>
説明:
リモート サーバーから受信した証明書は、信頼されていない証明機関によって発行されています。このため、この証明書に含まれているデータはどれも検証できません。TLS 接続の要求に失敗しました。添付されたデータにサーバー証明書が含まれています。
このエラー ログは SSL/TLS 通信の確立に失敗したことを示すエラー ログです。
SSL/TLS 通信の確立時に相手から送信されたサーバー証明書が、信頼されていない証明機関によって発行されているため、通信相手の正当性を確認できないために通信の確立に失敗しております。

このエラーは、SSL/TLS 通信に失敗しただけとなり、コンピューターに問題があるわけではありません。
これらのエラー ログの原因となった SSL/TLS 通信が、不要な通信である可能性もあります。
そのため、このエラー ログが記録されたタイミングにおいて、特に問題が発生していない場合は無視して問題ありません。

SSL/TLS 通信が関連している問題の場合、エラー ID 36882 が原因である可能性があります。
その場合、ID 36882 エラー ログから、エラーの原因となった証明書を確認した上で対処することで問題を解決することができます。

 

 

ID 36882 エラー ログの解析

ID 36882 エラーの要因となった証明書は、イベント ログの中身から確認することができます。

ID 36882 エラー ログには、信頼されていない証明機関によって発行されたと判断された証明書のバイナリ データが含まれています。この証明書のバイナリ データより、証明書の詳細情報を確認することができます。確認方法は以下の通りです。

1) [ファイル名を指定して実行] を開き、eventvwr と入力して [OK] をクリックします。

2) 画面の左ペインより、[イベント ビューアー] – [Windows ログ] – [システム] を選択します。

3) 対象のイベント ID 36882 エラー ログを選択します。

4) [詳細] タブを選択し、[XML で表示] を選択します。

5) XML 表示の <EventData> タグの下の <Binary> のデーターをコピーします。

6) 新しくテキスト エディタを開き、<Binary> 内のデータをコピーして、ファイル名 (例:cert.txt) を指定して保存します。

 

7) コマンド プロンプトを開き、cd コマンドで証明書のバイナリ データのファイルをあるフォルダに移動します。

8) 以下のコマンドを実行して、バイナリ データをデコードして証明書ファイルに変換します。

    certutil -f -decodehex <バイナリデータのファイル> <証明書のファイル> 12

実行例:
    certutil -f -decodehex cert.txt cert.crt 12

9) 作成されたファイル(cert.crt)をダブルクリックして開きます。

10) この証明書が ID 36882 エラーが要因となった証明書です。

 

 

証明書チェーンについて

SSL/TLS 通信を確立する際に、TLS ハンドシェイクにおいて、サーバーの信頼性を確認するためにサーバー証明書が提示されます。

クライアントは、サーバー証明書が信頼される証明機関から発行されているかどうかを確認します。
証明書チェーンをたどっていき、最上位にあるルート証明書がクライアントが信頼している必要があります。
これは、ルート証明書がクライアントの [信頼されたルート証明機関] ストアに登録されているかどうかです。

ルート証明書が [信頼されたルート証明機関] ストアに登録されていないと、サーバー証明書は信頼されません。
ルート証明書を [信頼されたルート証明機関] ストアに登録することで、問題は解決します。

Certificate:

これはサーバーが送信した Certificate です。
Certificate パケットでは、サーバー証明書と中間証明書の順でチェーンで送信されてくることが一般的です。
(中間証明書は省略されることもあります。サーバー側の設定次第です。)

証明書チェーンは降順で送信され、ルート証明書は送信されません。
上のパケットの画面キャプチャの場合、①サーバー証明書、②中間証明書の順となります。

下位の図でいうと、①サーバー証明書⇒②中間証明書⇒③中間証明書の順で送信されます。

ルート証明書の特定は、③の中間証明書の発行元機関キー識別子の情報をもとに特定します

③中間証明書はルート証明機関から発行された証明書となります。
そのため、③の中間証明書の発行元はルート証明機関の名前となります。

また、機関キー識別子とは、発行元の証明機関の公開鍵の識別子を指定するものです。
そのため、①のサーバー証明書の機関キー識別子=②の中間証明書のサブジェクト キー識別子となります。
また、③の中間証明書の機関キー識別子=ルート証明書のサブジェクト キー識別子となります。



issuer が発行元の証明機関の名前(CA 名)です。

  AuthorityKeyIdentifier が機関キー識別子です。これがルート証明書のサブジェクト キー識別子と一致します。

 

 

対処策

先程の「ID 36882 エラー ログの解析」にて、紹介した手順で、イベント ID 36882 の原因となった証明書を確認します。この証明書に対して、証明書チェーンの検証を行った結果、信頼された証明機関から発行されていないとみなされております。

そのため、ID 36882 エラーを解消するには、ルート証明書を [信頼されたルート証明機関] の証明書ストア、中間証明書を [中間証明機関] ストアに登録します。

 

サーバー証明書が自己署名証明書の場合
サーバー証明書が自己署名証明書(証明機関で発行されていない証明書)の場合は、その自己署名証明書を [信頼されたルート証明機関] に登録します。

自己署名証明書の見分け方として、①「発行先」と「発行元」の名前が同じ、②証明書の拡張機能の項目に “機関キー識別子” がない、などのポイントで見分けることができます。

[信頼されたルート証明機関] への自己署名証明書の登録方法は以下の通りです。

1) 対象の端末の任意のフォルダに、自己署名証明書のエクスポート ファイル(cer ファイル)を保存します。

2) 管理者権限でコマンド プロンプトを開きます。

3) 以下のコマンドを実行して、自己署名証明書を [信頼されたルート証明機関] に登録します。

    certutil -addstore Root <自己署名証明書のエクスポート ファイルのパス>

実行例:
    certutil -addstore Root selfsignedcert.cer

 

サーバー証明書が自己署名証明書の場合
サーバー証明書が証明機関から発行された証明書である場合は、証明書チェーン上にあるルート証明書を [信頼されたルート証明機関] に登録します。

証明機関に発行された証明書の見分け方として、①「発行先」と「発行元」の名前が異なる、②証明書の拡張機能の項目に “機関キー識別子” がある、などのポイントで見分けることができます。

発行元の証明機関の情報は、証明書の「発行元」や「機関キー識別子」の情報より特定することができます。
これらの情報より、証明書チェーン上の CA 証明書をたどっていき、最上位にあるルート証明書を [信頼されたルート証明機関] に登録します。

[信頼されたルート証明機関] への自己署名証明書の登録方法は以下の通りです。

1) 対象の端末の任意のフォルダに、ルート証明書のエクスポート ファイル(cer ファイル)を保存します。

2) 管理者権限でコマンド プロンプトを開きます。

3) 以下のコマンドを実行して、ルート証明書を [信頼されたルート証明機関] に登録します。

    certutil -addstore Root <ルート証明書のエクスポート ファイルのパス>

実行例:
    certutil -addstore Root rootcert.cer

 

環境によっては、中間証明書のインストールも必須である場合があります
 
上述の「証明書チェーンについて」にて説明した通り、一般的に TLS サーバーはサーバー証明書と中間証明書の順でチェーンで送信されきます。その場合、ルート証明書のみをインストールしておけば、証明書チェーンを構成できて信頼された証明機関から発行されていることを確認することができます。
しかしながら、接続先のサーバーの構成によっては、サーバー証明書のみを送信している場合もあります。その場合、サーバー証明書の証明書チェーンを構成するために、中間証明書のデータも入手する必要があります。
証明書の “機関情報アクセス(AIA)” の項目には、発行元の証明機関の CA 証明書が公開先の URL が記載されておりますので、中間証明書の入手が必要になった場合はその URL から中間証明書をダウンロードして、証明書チェーンを構成します。
ただし、ネットワークがクローズドの環境の場合に、”機関情報アクセス(AIA)” の URL へアクセスできない場合があります。その場合は、ローカルに中間証明書にインストールしていないと、証明書チェーンの検証は成功しません。ローカルに中間証明書をインストールする手順は以下の通りです。

1) 対象の端末の任意のフォルダに、中間証明書のエクスポート ファイル(cer ファイル)を保存します。

2) 管理者権限でコマンド プロンプトを開きます。

3) 以下のコマンドを実行して、中間証明書を [中間証明機関] に登録します。

    certutil -addstore CA  <中間証明書のエクスポート ファイルのパス>