【Windows】Schannel Event ID 36888/36887エラーの原因と対処方法

今回は、Windows Serverの運用中に遭遇することの多いSchannel Event ID 36888および36887のイベントログエラーについて詳しく解説します。

これらのエラーは、TLS/SSL通信に関連する重要なセキュリティイベントであり、特にIISやSQL Serverを運用している環境では頻繁に発生する可能性があります。

本記事では、これらのイベントが何を意味するのか、なぜ発生するのか、そしてPowerShellを活用した確認方法を含む具体的な対処法までを説明していきます。

Schannel Event ID 36888/36887とは何か

Schannelの役割

Schannel(Secure Channel)は、Windows OSに組み込まれているセキュリティサポートプロバイダー(SSP)の一つで、TLS/SSL通信を処理する重要なコンポーネントです。WebサーバーやデータベースサーバーがHTTPSやTLS暗号化通信を行う際、必ずこのSchannelを経由します。

Event ID 36888とは

Event ID 36888は、「サーバーへの接続試行時に、クライアントから致命的なアラートが受信されました」というエラーメッセージを示します。これは、クライアント側がTLS/SSLハンドシェイクの途中で接続を拒否したことを意味します。

具体的なログメッセージの例:

次の致命的なアラートが生成されました: 40. 内部エラー状態は 1205 です。
(The following fatal alert was generated: 40. The internal error state is 1205.)

Event ID 36887とは

Event ID 36887は、「次の致命的なアラートが受信されました」というメッセージで、TLS/SSLハンドシェイク中にクライアントまたはサーバー側で重大なエラーが発生したことを示します。

これらのイベントは、セキュリティログまたはシステムログに記録され、ソースは「Schannel」となります。

主な影響範囲

Event ID 36888/36887が発生する主な原因

1. TLSプロトコルバージョンの不一致

最も一般的な原因は、クライアントとサーバー間でサポートするTLSバージョンが一致しないことです。特に、セキュリティ強化のためにサーバー側でTLS 1.0/1.1を無効化した場合、古いクライアントからの接続が失敗します。

⚠ 注意: Windows Server 2019以降では、デフォルトでTLS 1.0/1.1が無効化される傾向にあります。レガシーアプリケーションとの互換性に注意が必要です。

2. 暗号スイート(Cipher Suite)の不一致

TLSハンドシェイクでは、クライアントとサーバーが共通して使用できる暗号化アルゴリズム(暗号スイート)を合意する必要があります。サーバー側で強固なセキュリティポリシーを適用した結果、クライアントがサポートする暗号スイートがすべて拒否されると、このエラーが発生します。

3. 証明書に関する問題

• SSL/TLS証明書の有効期限切れ
• 証明書チェーンの不完全性(中間証明書の欠落)
• 証明書のホスト名とアクセス先URLの不一致
• 自己署名証明書に対するクライアント側の信頼関係の欠如

4. レジストリ設定の不適切な変更

TLS/SSLの動作を制御するレジストリキー(HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL)が不適切に設定されている場合、予期しない動作を引き起こします。

5. IIS固有の問題

• IISのSSL設定でクライアント証明書が必須になっているが、クライアントが証明書を提示できない
• IISのバインディング設定で誤ったポートやIPアドレスが指定されている
• HTTPSリダイレクトの設定ミス

6. SQL Server固有の問題

• SQL Server接続文字列で暗号化を強制しているが、証明書が正しく設定されていない
• SQL Server Configuration Managerでの証明書設定ミス
• TLS 1.2を要求するクライアントと、古いSQL Serverバージョンとの互換性問題

PowerShellを使った確認方法と対処法

トラブルシューティングの視点と確認の流れ

Schannel Event ID 36888/36887のトラブルシューティングでは、以下の視点で段階的に確認を進めることが重要です。

1. 事象の把握: いつ、どのくらいの頻度でエラーが発生しているか
2. 原因の切り分け: クライアント側の問題か、サーバー側の設定問題か
3. 設定の確認: 現在のTLS/SSL設定が適切か、証明書に問題はないか
4. サービス別の確認: IISやSQL Serverなど、特定のサービスに起因するか
5. 対処と検証: 設定変更後、問題が解決したか確認

重要な判断基準:

• エラーが特定時間帯や特定クライアントからのみ発生 → クライアント側またはネットワークの問題の可能性
• 設定変更後に突然発生 → 変更内容の見直しが必要
• 複数のサービスで同時発生 → OSレベルのTLS設定の問題
• 特定のサービス(IISまたはSQL Serverのみ)で発生 → サービス固有の設定問題

Step 1: イベントログの確認

PowerShellでSchannelエラーを検索する

まずは、実際にどのようなエラーが発生しているかを確認します。

# 最近のSchannel Event ID 36888を検索
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Schannel'
    ID=36888
    StartTime=(Get-Date).AddDays(-7)
} -MaxEvents 50 | Format-Table TimeCreated, Message -AutoSize

# Event ID 36887も同様に検索
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Schannel'
    ID=36887
    StartTime=(Get-Date).AddDays(-7)
} -MaxEvents 50 | Format-Table TimeCreated, Message -AutoSize

🔍 確認の視点:

• 発生頻度: 継続的に発生しているか、それとも一時的なものか
• 発生時間帯: 特定の時間帯に集中していないか(業務開始時、バッチ処理時など)
• エラーメッセージの内容: “致命的なアラート: 40″や”内部エラー状態”の番号に注目
• 関連性: 複数のイベントIDが同時刻に発生していないか

💡 判断基準:

# より詳細な情報を取得(メッセージの内容でフィルタリング)
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Schannel'
    ID=36888,36887
    StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message | 
    Group-Object -Property Id | 
    Select-Object Count, Name

# 特定の時間範囲で検索(例: 昨日の業務時間内)
$startTime = (Get-Date).AddDays(-1).Date.AddHours(9)  # 昨日の9:00
$endTime = (Get-Date).AddDays(-1).Date.AddHours(18)   # 昨日の18:00
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Schannel'
    ID=36888,36887
    StartTime=$startTime
    EndTime=$endTime
} | Measure-Object

Step 2: 現在のTLS設定の確認

有効なTLSプロトコルバージョンを確認する

# TLS 1.0の設定確認
$tls10Server = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server"
if (Test-Path $tls10Server) {
    Get-ItemProperty -Path $tls10Server | Select-Object Enabled, DisabledByDefault
}

# TLS 1.2の設定確認
$tls12Server = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
if (Test-Path $tls12Server) {
    Get-ItemProperty -Path $tls12Server | Select-Object Enabled, DisabledByDefault
}

🔍 確認の視点:

• 有効なプロトコル: Enabled=1 かつ DisabledByDefault=0 の場合、そのプロトコルは有効
• セキュリティバランス: 最低でもTLS 1.2は有効にすべき(TLS 1.0/1.1は非推奨)
• クライアント互換性: レガシークライアントがTLS 1.2をサポートしているか

💡 判断基準:

Step 3: IISでの証明書とバインディング確認

IISのHTTPSバインディングと証明書を確認する

# WebAdministrationモジュールのインポート
Import-Module WebAdministration

# すべてのIISサイトのバインディング情報を取得
Get-ChildItem -Path IIS:\Sites | ForEach-Object {
    $siteName = $_.Name
    $_.Bindings.Collection | Where-Object {$_.protocol -eq "https"} | ForEach-Object {
        [PSCustomObject]@{
            SiteName = $siteName
            Protocol = $_.protocol
            BindingInformation = $_.bindingInformation
            CertificateHash = $_.certificateHash
        }
    }
}

# 証明書の詳細確認
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
    $_.HasPrivateKey -eq $true
} | Select-Object Subject, Thumbprint, NotBefore, NotAfter | Format-Table -AutoSize

🔍 確認の視点:

• 証明書の有効期限: NotAfterが現在日時より前になっていないか(期限切れチェック)
• 秘密キーの存在: HasPrivateKey=Trueであること(秘密キーがないと通信不可)
• ホスト名の一致: 証明書のSubjectまたはSANとアクセスURLが一致しているか

Step 4: SQL Serverでの暗号化設定確認

SQL Serverの証明書と暗号化設定を確認する

# レジストリからSQL Serverの証明書設定を取得
$sqlRegPath = "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib"
if (Test-Path $sqlRegPath) {
    Get-ItemProperty -Path $sqlRegPath | Select-Object Certificate, ForceEncryption
}

# SQL Serverサービスアカウントの確認
$sqlService = Get-WmiObject Win32_Service | Where-Object {$_.Name -eq "MSSQLSERVER"}
Write-Host "SQL Server Service Account: $($sqlService.StartName)"

🔍 確認の視点:

• ForceEncryption設定: 1の場合はすべての接続でTLS必須、0の場合はクライアント次第
• 証明書の指定: Certificateレジストリキーに証明書のThumbprintが設定されているか
• サービスアカウントの権限: SQL Serverサービスアカウントが証明書の秘密キーにアクセスできるか

Step 5: TLSプロトコルの有効化(必要に応じて)

TLS 1.2を有効化する

⚠ 重要: レジストリ変更前に必ずバックアップを取得してください。また、変更後はサーバーの再起動が必要です。

# レジストリバックアップの作成
$backupPath = "C:\Backup\Registry"
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
if (-not (Test-Path $backupPath)) {
    New-Item -Path $backupPath -ItemType Directory -Force
}

# Schannelレジストリキーのバックアップ
reg export "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" "$backupPath\Schannel_Backup_$timestamp.reg" /y

# TLS 1.2 Serverを有効化
$tls12ServerPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
if (-not (Test-Path $tls12ServerPath)) {
    New-Item -Path $tls12ServerPath -Force
}
New-ItemProperty -Path $tls12ServerPath -Name "Enabled" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path $tls12ServerPath -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force

# TLS 1.2 Clientを有効化
$tls12ClientPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"
if (-not (Test-Path $tls12ClientPath)) {
    New-Item -Path $tls12ClientPath -Force
}
New-ItemProperty -Path $tls12ClientPath -Name "Enabled" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path $tls12ClientPath -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force

その他の対処法

• Windowsアップデートの適用: 最新のセキュリティパッチを適用することで、既知のTLS/SSL関連の問題が解決される場合があります
• ネットワーク機器の確認: ロードバランサーやファイアウォールがTLS通信を中断していないか確認
• クライアント側の確認: 古いブラウザやアプリケーションが原因の場合、クライアント側のアップデートが必要
• ログの継続監視: 定期的にイベントログを監視し、パターンを分析する

まとめ

Schannel Event ID 36888/36887は、Windows ServerにおけるTLS/SSL通信のハンドシェイク失敗を示す重要なイベントです。これらのエラーは、セキュリティ強化とレガシーシステムの互換性という、相反する要件のバランスを取る際に頻繁に発生します。

重要なポイント:

• Event ID 36888: クライアントからの致命的アラート受信を意味し、主にTLSバージョンや暗号スイートの不一致が原因
• Event ID 36887: TLS/SSLハンドシェイクの失敗を示し、証明書の問題やプロトコル設定の不備が関連
• PowerShellの活用: イベントログの検索、TLS設定の確認、証明書の管理など、PowerShellを使った効率的なトラブルシューティングが可能
• IISとSQL Server: これらのサービスでは特に暗号化通信が重要であり、適切な証明書設定とTLS設定が不可欠
• セキュリティと互換性: TLS 1.2以上の使用を推奨しつつ、既存システムとの互換性を考慮した段階的な移行が重要

今回紹介した確認方法と対処法を活用することで、Schannelエラーの原因を特定し、適切に対処できるようになります。ただし、レジストリの変更や証明書の設定は、システムのセキュリティと安定性に直接影響するため、必ず検証環境でテストしてから本番環境に適用してください。

定期的なイベントログの監視と、セキュリティベストプラクティスに従った設定管理が、安全で信頼性の高いWindows Server環境を維持する鍵となります。