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

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

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

関連記事

【PKI 応用】SSL/TLS (暗号化通信プロトコル) とは

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

関連記事

【PKI 応用】SSL/TLS ハンドシェイクをわかりやすく図解

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

イベント ID 36887/36888 の概要

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

ID 36888
TLS 通信の途中で、自身がエラーを検知して TLS 通信の確立を中断した状況だったことを示しています。

警告コード一覧

イベント ID 36887/36888 エラー ログの説明に警告コードが記載されています。
この警告コードは TLS Alert メッセージで通知されるエラー コード(数字)です。

TLS Alert とは、TLS ハンドシェイクや TLS 通信中に、問題が発生したことを通信相手に通知するものです。
TLS 通信において、途中で失敗する要因は様々なものが想定されます。
そのため、TLS の警告プロトコルで、想定される一般的な要因を示すエラー コードを定義しています。

定義されているエラーの一覧は以下の通りです。

※ エラー コードにはレベルが指定されており、warning と fatal があります。
fatal(=致命的)のエラー コードの TLS Alert メッセージを受領すると、双方はコネクションを閉じます。

TLS 通信に失敗する理由を調査する時、警告コードの内容がヒントになります。
警告コードの内容をもとに、適切な対処策を実施していただければと思います。

パケット解析ツール：Wireshark

TLS 通信に失敗する理由を調査する場合、その通信のパケット キャプチャーの解析が必要です。
TLS 通信のパケットの解析は、Wireshark がおすすめです。

オープンソースのパケット解析ツール：Wireshark
https://www.wireshark.org/

その他、パケット解析ツールとして、マイクロソフト製の Network Monitor があります。
ただし、SSL/TLS 通信のパケット解析という観点ではおすすめしません。

Network Monitor では、TLS ハンドシェイクに使われる拡張項目など正しく解釈されない項目があり、バイナリ表示となることがあります。

例えば、、、
Client Hello Extension の signature_algorithms の表示を見比べてみましょう。

Network Monitor

signature_algorithms の値が “Binary Large Object” と表示されています。
Network Monitor がパケットのバイナリデータを変換しないため、バイナリからアルゴリズム一覧を解釈する必要があります。
署名アルゴリズムは、ハッシュアルゴリズム(１バイト)、公開鍵暗号方式(１バイト) の計2バイトで表現されます。
バイナリデータの 0x4(SHA256) 0x3(ECDSA)、0x08(RSASSA-PSS) 0x04(SHA256)、0x4(SHA256) 0x1(RSA)、0x5(SHA384) 0x3(ECDSA)　… と解釈していきます。

Wireshark

一方、Wireshark では、signature_algorithms の値は解析ツールの方で自動解釈して署名アルゴリズムを表記してくれます。
そのため、バイナリデータからサポートしている署名アルゴリズムの一覧を解釈する必要はありません。

拡張項目に含まれるべきデータを把握しており、バイナリ表記でも意味を理解できる上級者であれば Network Monitor でも問題ないと思います。
ただ、慣れるまで時間がかかるので、普通に Wireshark を利用する方がおすすめです。

トラブルシューティング事例

Handshake failure (40)

Handshake failure (40) は、TLS ハンドシェイクに失敗したことを示します。
指定されたセキュリティ アルゴリズムのセットに、利用できるものがないことを通知したものです。

これは、通信相手が提示してきた暗号スイートの中に、利用できるものがないことを意味しています。
クライアントとサーバーの双方が利用可能な暗号スイートを利用できるようにすることで、問題は解決します。

Client Hello：

これはクライアントが送信した Client Hello です。
クライアント自身が利用可能な暗号スイートの一覧を列挙してサーバーに通知します。

Server Hello：

これはサーバーが送信した Server Hello です。
Client Hello に含まれる暗号スイート一覧の中から、サーバー自身も利用可能な暗号スイートを 1 つ選択してクライアントに通知します。
ここで選択された暗号スイートのアルゴリズムを利用して、暗号化通信を行います。

クライアントが提示した暗号スイート一覧の中に、サーバーが利用できる暗号スイートがない状態となります。
そのため、正常にアクセスできる端末で採取したパケット、アクセスできない端末で採取したパケットを比較します。
正常系のログから、どの暗号スイートがサーバーが利用可能なのかを特定します。
特定した暗号スイートを利用できるように、クライアント端末の暗号スイートの設定を変更してください。

暗号スイートとは何か？暗号スイートの設定変更方法については、以下の記事で紹介しております。

関連記事

【PKI 応用】暗号スイート (cipher suite) とは

SSL/TLS にてデータを暗号化して通信を行うには、自分自身と通信相手の両方が利用可能なアルゴリズムを使う必要があります。 不特定の相手と両者が利用可能なアルゴリズムを確認しあうために使われるのが 暗号スイート(cipher suite[…]

Unknown CA (48)

Unknown CA (48) は、サーバー証明書が不明な証明機関(CA)から発行されたことを示します。

TLS ハンドシェイク中に、サーバーの信頼性を確認するためにサーバー証明書が提示されます。

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

ルート証明書が [信頼されたルート証明機関] ストアに登録されていないと、サーバー証明書は信頼されません。
サーバー証明書が不明な証明機関から発行されたとみなされ、Unknown CA (48) エラーを通知します。

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

Certificate：

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

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

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

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

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

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

※ issuer が発行元の証明機関の名前(CA 名)です。
　 AuthorityKeyIdentifier が機関キー識別子です。これがルート証明書のサブジェクト キー識別子と一致します。

該当するルート証明書を入手し、[信頼されたルート証明機関] にインストールしてください。

Protocol version (70)

Protocol version (70) は、指定されたプロトコル バージョンが利用できないことを示します。

TLS ハンドシェイクの過程で、自身が利用したいプロトコル バージョンを指定します。
クライアントは Client Hello、サーバーは Server Hello でプロトコル バージョンを指定しています。

通信相手が指定したプロトコル バージョンをサポートしていない場合、Protocol version (70) エラーを通知します。
相手がサポート指定しているプロトコル バージョンを有効にすることで、問題は解決します。

Client Hello：

Server Hello：

Handshake Protocol の項目の Version を確認してください。(Record Layer の Version は確認対象ではありません)

補足