Windows ServerでSchannelのイベントID 36871・36874が記録されたら、最初に本文、内部エラー状態、発生時刻、実際に失敗した通信を照合します。36871は資格情報の作成、36874は接続要求の暗号スイート等の条件を確認する入口です。IDだけで原因を決め、全サーバーへ同じレジストリ値を追加する対処は避けます。
36871・36874・36887・36888：先に見る項目
| イベントや本文 | 確認の入口 | 先に判断しないこと |
|---|---|---|
| 36871：TLSクライアント/サーバー資格情報の作成エラー | どちらの役割か、本文にあるプロセス、内部エラー状態、同時刻のアプリの失敗 | 10013などの内部状態だけで証明書切れや特定KBを原因と決めない |
| 36874：相手からの接続要求で共通の暗号スイートがない等 | 相手が提示するTLS条件と、サーバー・アプリが許可する条件 | TLS 1.2のキーを追加すれば必ず直るとは判断しない |
| 36887：致命的な警告を受け取った | 相手から送られた警告コードと通信先 | 記録した側が警告を生成したと扱わない |
| 36888：致命的な警告を生成した | この端末が送った警告と、直前の通信 | ログの件数だけで全サービスの障害やCPU負荷を断定しない |
MicrosoftのSchannelイベント資料は旧Windows向けの説明を含みます。36871のSMTPに関する「無視できる」例は、その条件の例です。現在のTLS client credentialエラーすべてを無視する根拠にはせず、現場のイベント本文と利用サービスを優先します。
イベントログと実際の通信を対応させる
- イベントビューアーの「Windowsログ」→「システム」でソースSchannelを確認し、対象の時刻とIDを絞ります。イベント本文と詳細/XMLを保存します。
- 記録した端末が接続を受けるサーバーか、別サーバーへ接続するクライアントかを確認します。Windows Server上でもアプリが外部へ接続する場面はクライアントです。
- 業務アプリ、IIS、メール、SQL接続などで同時刻に失敗している処理を調べます。本文にプロセス情報があれば、その時点の情報と照合します。後から見たPIDだけで同じプロセスと決めないでください。
- 失敗した通信先、ポート、成功する端末との違いを記録し、許可されたテストで一度に一項目ずつ比較します。
| 記録すること | 比較例 |
|---|---|
| 時刻・タイムゾーン・イベント本文・内部状態 | 相手側とアプリ側のログを同じ時間帯で見る |
| OS版/ビルド・アプリ版・更新日 | 同じ処理が成功する端末との差を見る |
| 接続方向・相手・ポート | 受信TLSとアプリの送信TLSを分ける |
| 適用ポリシーと直前の変更 | OS更新、証明書更新、GPO、アプリ設定を別々に確認 |
ログだけがある場合も、通信失敗がある場合も、影響範囲を先に確認します。外部のサポートへ共有するログやパケットには、接続先や証明書・組織情報が含まれる場合があるため、必要範囲と共有先を確認してください。
36874は両端のTLS条件を比較する
OSがサポートする版、OSの有効設定、アプリの指定、相手の条件を分けます。サーバー側でTLS 1.2が使えても、相手のアプリが旧方式だけを指定していれば同じ条件にはなりません。ロードバランサー等がTLSを終端している場合は、その区間とアプリサーバーへの区間を別に調べます。
暗号スイートはまず読み取る
WindowsのTLS PowerShellモジュールが利用できる環境では、Get-TlsCipherSuiteで、そのコンピューターの暗号スイート一覧を取得できます。次は一覧を読む例で、設定を変更しません。
Get-TlsCipherSuite | Select-Object Name, Protocolsこの結果だけで、特定アプリの通信先に対して実際に使われた方式は確定できません。相手のログや、許可された通信キャプチャのClientHello/ServerHelloと比較します。アプリが許可する方式や証明書との組み合わせも確認します。
公式のTLS管理資料は、暗号スイートをGPO・MDM・TLS PowerShellで管理する方法を示しています。既定の優先順序をレジストリで直接書き換える方法はサポートされません。変更が必要な場合も、採用する共通の安全な方式と適用ポリシーを管理者が検討し、検証環境で接続への影響を確認します。優先順序の変更は次の起動で有効になります。
TLS 1.3はOSの対応も確認する
Schannelのプロトコル対応表では、TLS 1.3はWindows Server 2022以降で対応しています。Windows Server 2019へTLS 1.3のレジストリキーを作ることは、対応機能を追加する方法にはなりません。OS、アプリ、接続先が共通して利用できる安全な版を確認します。
警告コード70・40と内部エラー状態を混同しない
TLSの公式仕様（RFC 8446）で、警告コード70はprotocol_version、40はhandshake_failureです。70なら版の条件、40ならハンドシェイクの失敗として、送信側と受信側の記録を確認します。イベント本文の「internal error state 1205」「10013」等はこのTLS警告番号とは別なので、同じ対応表で原因を解釈しないでください。
証明書は対象サービスと関連ログを確認する
有効期限、接続先名、信頼チェーン、失効確認、秘密キーの利用権限は、証明書を使う対象サービスと関連エラーが示す範囲で確認します。36871/36874というIDだけで、すべての証明書を入れ直す必要があると判断しません。
- ローカルコンピューターの証明書を調べるなら
certlm.msc等で対象を確認します。ユーザー用証明書やアプリ独自のストアを使う場合は、実際の参照先を分けます。 - 期限・用途・名前・秘密キーの有無と、サービスが使っている証明書の関連付けを確認します。正しい証明書がストアにあることだけで、サービスが利用しているとは決めません。
- チェーンや失効確認のエラーがある場合は、CAの正式な資料と管理者の手順で確認します。無関係なCAを信頼ストアへ追加したり、証明書検証を無効にしたりして回避しないでください。
Schannelのレジストリと.NET設定は対象を分ける
現行のSchannelレジストリ資料で、対象のプロトコル、Client/Server、既定値と上書きを確認します。キーが存在しないことを「TLS無効」と同一視しません。Schannelの設定は他社のTLS実装には適用されず、アプリ自身のプロトコル指定も別に調べる必要があります。
TLSの許可条件を狭めると、資格情報の取得や相手との接続が失敗する場合があります。設定が必要と判断した場合は、既存値・キーがなかった状態・GPO等の設定元を記録し、戻す手順と影響範囲を用意します。資格情報を再取得するため、アプリやサービスの再起動が必要になる場合があります。
.NET Frameworkで確認する項目
.NET Frameworkの公式TLS資料を基に、実行環境だけでなくアプリの対象Framework、32/64ビット、設定ファイルやコードによるTLS固定を確認します。対応するアプリでは、OSに安全な版の選択を任せる方法が推奨されます。
| 確認項目 | 意味・対象 |
|---|---|
| SystemDefaultTlsVersions | OSによる版の選択に関する設定。実行環境・対象Framework・明示指定の有無を確認 |
| SchUseStrongCrypto | 強い暗号の選択に関する設定で、アプリのクライアント側（送信）接続へ影響 |
| SOFTWAREとWow6432Node、Frameworkの版 | アプリのビット数と利用Frameworkに合う対象を確認。一つのパスだけを全アプリへ適用しない |
| アプリ内のSecurityProtocol等 | コードで版を指定していると、レジストリやOS既定へ任せる方針を上書きし得る |
サーバー全体へ一括適用する.REGを初手にはしません。アプリを管理する担当者と、更新・対象Framework・設定変更の適用範囲を決めます。IISを使う場合も、すべてのアプリプールへ同時に変更を入れる前に、対象の接続を検証してください。
Windows Update後に発生した場合の検証
更新の後に記録が増えたことは、更新が原因と確定したことを意味しません。適用KBとOSビルド、アプリ版、同時期のGPOや証明書の変更を記録し、対象KBの公式な既知の問題と対象条件を確認します。「2024年以降の更新はTLSを変更する」と一律には扱いません。
- 更新前後に同じ通信先・同じ操作で比較できる記録を集める。
- 検証環境で、OS更新・アプリ・GPO・証明書の変更を一つずつ比較する。
- 本番での更新削除や暗号設定の変更は、公式の対象条件・代替策・サービス影響・復旧手順を確認した上で管理者が判断する。
詳細ログとパケット解析を使う場面
通常のイベント本文とアプリログで特定できなければ、許可された範囲でログを追加します。現行Schannel資料にはEventLoggingのレベルが定義され、変更後は端末の再起動が必要です。イベントを増やすだけで、すべての相手や交渉内容が得られるとは限りません。調査期間と保存量、元へ戻す値を記録します。
通信キャプチャでは、どの相手が接続を開始し、どの段階で警告を返したかを確認します。TLS 1.3では暗号化されるハンドシェイク情報もあるため、パケットだけですべてを読み取れると考えず、アプリ側のログやサービス提供元の診断情報も組み合わせます。性能の最適化は、接続障害の原因を特定した後に別の検証として行います。
対処後の確認と、問い合わせに必要な情報
- 対象の業務操作・接続が成功するかを、同じ相手と条件で確認する。
- 新しいSchannelログとアプリの失敗ログを対応させ、別のサービスにも影響が出ていないか確認する。
- 解決しなければ、OS/アプリ版、イベント本文・内部状態、時刻、接続方向、相手、適用ポリシー、直前の変更と試した結果を整理し、管理者や製品サポートへ渡す。
36871・36874は調査の入口です。イベント本文、アプリ、相手との共通条件を対応させ、必要性が分かった対象だけを変更することで、原因の切り分けと復旧後の確認を進められます。
コメント