- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows 이벤트 로그에 반복 기록되는 Schannel 36887 알림 레벨 치명적 오류를 원인 유형별로 분류하고, 현장에서 바로 적용 가능한 점검 절차와 설정 복구 방법을 체계적으로 제공하는 데 있다.
1. Schannel 36887 오류의 의미와 발생 구조
Schannel 36887은 Windows의 보안 채널(SChannel)이 TLS 핸드셰이크 과정에서 원격 끝점이 전송한 치명적(fatal) 경고를 수신했음을 알리는 시스템 이벤트이다.
이 이벤트는 “원격이 보낸 경고 코드”를 기록하는 성격이 강하므로, 내 PC가 잘못한 경우도 있고 원격 서버가 차단한 경우도 있는 구조이다.
따라서 해결의 핵심은 “누가 누구에게 연결을 시도했는지”와 “어떤 TLS 경고 코드가 반복되는지”를 먼저 분리하는 접근이다.
주의 : Schannel 36887은 보안 통신 협상 실패의 결과 로그이므로, 로그만 지우는 방식은 근본 해결이 아니며 장애를 숨기는 조치에 해당하다.
2. 먼저 확인해야 하는 필수 정보 5가지
원인 파악을 빠르게 하기 위해 아래 5가지를 먼저 정리하는 방식이 표준적인 실무 절차이다.
| 확인 항목 | 확인 방법 | 왜 중요한지 |
|---|---|---|
| 오류가 기록되는 장비 역할 | 클라이언트 PC인지 서버(IIS, AD, SQL, 프록시)인지 분류하다. | 서버라면 외부 클라이언트가 실패한 로그일 가능성이 크기 때문이다. |
| 이벤트 메시지의 경고 코드 | 이벤트 상세에 “fatal alert code” 숫자를 확인하다. | 프로토콜 불일치인지 인증서 문제인지 방향을 좁히는 단서이다. |
| 발생 주기와 시간대 | 분당/시간당 발생 횟수와 특정 시간대 집중 여부를 확인하다. | 예약 작업, 에이전트, 스캐너, 모니터링이 원인인 경우가 흔하기 때문이다. |
| 연결 대상의 유형 | 사내 서버, 외부 API, 보안장비, 클라우드 서비스인지 분류하다. | 중간 장비 SSL 검사나 정책 차단 여부를 판단하기 때문이다. |
| 동반 증상 존재 여부 | 실제 서비스 장애, 로그인 실패, 업데이트 실패, API 호출 실패를 확인하다. | 무해 로그인지 장애 전조인지 우선순위를 결정하기 때문이다. |
3. 자주 함께 보이는 TLS 경고 코드와 원인 범주
Schannel 36887의 경고 코드는 TLS 표준에서 정의된 Alert 번호이며, 현장에서는 아래 범주로 정리하는 방식이 실용적이다.
| 경고 코드 예 | 현장에서 연결되는 원인 범주 | 우선 점검 포인트 |
|---|---|---|
| 40 | 핸드셰이크 실패 범주로 분류하다. | TLS 버전, 암호 스위트, 중간 장비 개입을 우선 점검하다. |
| 42 | 인증서/인증 관련 실패 범주로 분류하다. | 루트/중간 인증서, 신뢰 저장소, SSL 검사(가짜 인증서) 여부를 점검하다. |
| 46 | 인증서 처리 실패 범주로 분류하다. | 서버 인증서 체인, 만료, EKU, SAN, 호스트명 불일치를 점검하다. |
| 70 | 지원하지 않는 프로토콜/버전 협상 실패 범주로 분류하다. | 한쪽이 TLS 1.0/1.1만 시도하거나 반대로 TLS 1.2 이상만 강제하는지 점검하다. |
주의 : 경고 코드가 동일하더라도 원격 서버 정책 차단, 클라이언트 설정 차단, 중간 장비 SSL 검사 등 원인이 겹칠 수 있으므로 “원인 범주”로 먼저 묶어 점검 순서를 세우는 방식이 효율적이다.
4. “누가” 통신을 시도했는지 찾는 실무 절차
4.1 서버에서 36887이 폭증하는 경우의 해석
서버에서 Schannel 36887이 폭증하는 상황은 다수의 외부 또는 내부 클라이언트가 서버로 TLS 연결을 시도하다가 서버 또는 중간 장비 정책에 의해 실패하는 그림이 흔한 패턴이다.
이 경우 서버 자체를 무작정 바꾸기보다 “실패시키는 클라이언트 유형”을 먼저 찾는 접근이 정답에 가깝다.
4.2 클라이언트 PC에서 36887이 반복되는 경우의 해석
클라이언트 PC에서 Schannel 36887이 반복되는 상황은 특정 프로그램, 에이전트, 스크립트, 업데이트 구성 요소가 외부 HTTPS 엔드포인트에 연결을 시도하다가 실패하는 패턴이 흔하다.
이 경우 PC의 TLS 구성과 해당 프로그램의 런타임(.NET, WinHTTP, Java, OpenSSL 계열)을 분리하여 보는 방식이 핵심이다.
4.3 즉시 적용 가능한 네트워크/프로세스 추적 명령
다음 명령은 연결 시도 주체를 좁히는 데 유용한 기본 도구 모음이다.
:: 현재 수립된 연결에서 PID 확인하다 netstat -ano | findstr ":443" :: PID로 프로세스 이름 확인하다 tasklist /fi "PID eq 1234" :: 시스템 전체 네트워크 추적을 ETL로 수집하다 netsh trace start scenario=internetclient capture=yes tracefile=C:\Temp\schannel_trace.etl :: 재현 후 중지하다 netsh trace stop주의 : netsh trace는 로그 크기가 급격히 증가할 수 있으므로 재현 시간만 짧게 잡고 즉시 중지하는 운영이 안전하다.
5. 원인 1) TLS 버전 불일치로 인한 36887 해결
TLS 버전 불일치는 “서버가 TLS 1.2 이상만 허용하는데 클라이언트가 TLS 1.0/1.1로만 시도하는 상황” 또는 “클라이언트가 TLS 1.2 이상만 시도하는데 서버가 구버전만 허용하는 상황”으로 정리하다.
현장에서는 보안 정책 강화 이후 구형 OS, 구형 .NET, 구형 WinHTTP 기반 프로그램에서 36887이 폭증하는 케이스가 대표적이다.
5.1 Schannel 프로토콜 레지스트리 기본 점검
아래 경로에서 TLS 1.2의 Client와 Server가 의도대로 활성화되어 있는지 확인하는 절차가 기본이다.
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" /s실무에서는 “Enabled”와 “DisabledByDefault” 조합으로 상태를 통제하는 방식이 일반적이다.
| 목표 상태 | Enabled | DisabledByDefault | 해석 |
|---|---|---|---|
| 활성화 | 1 | 0 | 프로토콜을 사용 가능 + 기본 협상에도 참여하도록 설정하다. |
| 비활성화 | 0 | 1 | 프로토콜을 사용 불가 + 기본 협상에서도 제외하도록 설정하다. |
5.2 TLS 1.2 활성화 예시 REG 파일
다음 예시는 TLS 1.2를 Client/Server 모두 활성화하는 대표 구성 예시이다.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001주의 : 레지스트리 변경은 즉시 적용이 보장되지 않으므로, 서비스 재시작 또는 서버 재부팅을 작업 계획에 포함해야 하다.
6. 원인 2) .NET 애플리케이션이 구버전 TLS로 나가는 문제 해결
.NET 애플리케이션은 OS의 Schannel 설정과 별개로 런타임 기본값이 보수적으로 동작하는 경우가 있으며, 이 상황에서 외부 서비스가 TLS 1.2 이상을 강제하면 Schannel 36887이 반복되는 구조이다.
실무에서는 SchUseStrongCrypto와 SystemDefaultTlsVersions 설정을 통해 .NET의 기본 협상을 OS 기본값에 맞추는 방식이 표준 대응이다.
6.1 .NET 4.x 강력한 암호화 및 시스템 기본 TLS 사용 설정
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:000000016.2 .NET 2.0/3.5 계열 호환 필요 시 보완 설정
구형 구성 요소가 남아 있는 서버나 레거시 프로그램 환경에서는 v2.0.50727에도 동일 개념을 적용하는 운영이 필요할 수 있는 구조이다.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SchUseStrongCrypto"=dword:00000001 "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727] "SchUseStrongCrypto"=dword:00000001 "SystemDefaultTlsVersions"=dword:00000001주의 : 구형 애플리케이션이 TLS 1.0 의존 구조인 경우 강제 전환은 연결 실패를 증가시키는 결과가 될 수 있으므로, 대상 프로그램 식별을 먼저 수행하는 절차가 필수이다.
7. 원인 3) WinHTTP 기반 프로그램이 TLS 1.2를 기본으로 못 쓰는 문제 해결
WinHTTP 기반 프로그램은 “기본 보안 프로토콜” 설정이 구형 OS에서 보수적으로 잡히는 경우가 있으며, 이때 외부 서비스가 TLS 1.2 이상만 허용하면 36887이 반복되는 구조이다.
이 경우 DefaultSecureProtocols 값을 통해 WinHTTP 기본 협상 프로토콜을 재지정하는 방식이 표준 대응이다.
7.1 DefaultSecureProtocols 설정 예시
아래 예시는 TLS 1.1(0x200)과 TLS 1.2(0x800)를 합산한 0xA00을 설정하는 대표 예시이다.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00주의 : 일부 구형 OS는 관련 업데이트가 누락된 상태에서 DefaultSecureProtocols가 기대대로 동작하지 않는 구조이므로, OS 업데이트 수준 점검을 병행해야 하다.
8. 원인 4) 인증서 체인/신뢰 저장소 문제로 인한 36887 해결
인증서 원인은 서버 인증서 자체 문제, 클라이언트의 신뢰 저장소 문제, 중간 장비 SSL 검사로 인한 가짜 체인 문제로 나누어 보는 방식이 정확하다.
8.1 서버 인증서 자체 점검 항목
서버가 제공하는 인증서 체인이 완전하고 유효해야 하며, 다음 항목은 실무에서 고장 지점으로 자주 등장하는 항목이다.
| 점검 항목 | 의미 | 조치 방향 |
|---|---|---|
| 만료 여부 | 유효기간 만료는 즉시 실패 원인이 되는 구조이다. | 정상 체인으로 재발급하고 교체하다. |
| 호스트명 일치 | CN 또는 SAN이 접속 도메인과 일치해야 하다. | 도메인 포함 SAN으로 재발급하다. |
| 중간 인증서 누락 | 서버가 체인을 끝까지 제공하지 않으면 일부 클라이언트가 실패하다. | 서버에 올바른 체인 번들로 설치하다. |
| 키 사용(EKU) 부적합 | 서버 인증서 용도와 실제 용도가 어긋나면 실패하다. | Server Authentication 용도 포함으로 재발급하다. |
8.2 클라이언트 신뢰 저장소 점검 항목
클라이언트에 루트 또는 중간 인증서가 없으면 서버 인증서를 신뢰하지 못하는 구조이다.
또한 시스템 시간 오차가 크면 정상 인증서도 유효하지 않게 판단하는 구조이다.
주의 : 기업 보안 장비의 HTTPS 검사 기능이 활성화된 환경에서는 장비가 자체 발급한 루트 인증서를 클라이언트가 신뢰하도록 강제하는 구조이므로, 해당 루트가 배포되지 않으면 36887이 연쇄적으로 발생하다.
9. 원인 5) 프록시·방화벽·보안장비의 SSL 검사로 인한 36887 해결
SSL 검사 장비는 TLS 종단을 중간에서 끊고 재암호화하는 구조이므로, 인증서 체인 변경과 암호 스위트 정책 변경이 함께 발생하는 환경이다.
이 환경에서는 특정 사이트만 실패하거나 특정 프로세스만 실패하는 패턴이 쉽게 나타나는 구조이다.
9.1 SSL 검사 원인 판별 체크리스트
| 현상 | 판별 힌트 | 조치 방향 |
|---|---|---|
| 사내망에서만 실패 | 모바일 핫스팟에서는 정상 동작하다. | SSL 검사 예외 정책을 적용하다. |
| 특정 도메인만 실패 | 동일 PC에서 다른 HTTPS는 정상 동작하다. | 해당 도메인 바이패스 또는 정책 완화하다. |
| 인증서 발급자가 내부 CA로 표시 | 브라우저 인증서 정보에 내부 조직 발급자가 보이다. | 루트 배포 또는 검사 정책 재검토하다. |
10. 운영 관점에서의 “무시 가능”과 “즉시 조치” 기준
Schannel 36887은 서비스 장애가 동반되지 않는 경우가 존재하며, 보안 정책 강화 이후 구형 스캐너나 취약한 클라이언트가 접속을 시도하다 차단되는 로그로 남는 구조도 흔하다.
반대로 도메인 로그인, 업데이트, 업무 앱, API 호출 같은 핵심 기능이 함께 실패하면 즉시 조치 대상이 되는 구조이다.
| 구분 | 상태 | 권장 대응 |
|---|---|---|
| 관찰 우선 | 서비스 장애가 없고, 특정 시간대에만 소량 발생하다. | 연결 주체 식별을 진행하고 추세를 모니터링하다. |
| 즉시 조치 | 분당 수십~수백 건으로 폭증하거나 핵심 기능 실패가 동반하다. | TLS 버전/인증서/중간 장비 정책을 우선순위로 점검하다. |
11. 현장 적용용 빠른 해결 순서 요약
아래 순서는 Schannel 36887을 가장 빠르게 줄이는 실무형 우선순위이다.
| 순서 | 조치 | 기대 효과 |
|---|---|---|
| 1 | 경고 코드와 발생 위치(클라이언트/서버)를 분리하다. | 원인 범주를 즉시 좁히는 효과이다. |
| 2 | netstat, tasklist, netsh trace로 연결 주체를 식별하다. | 불필요한 레지스트리 난사를 막는 효과이다. |
| 3 | TLS 1.2 활성화와 구버전 프로토콜 정책을 정리하다. | 70, 40 계열 폭증을 줄이는 효과이다. |
| 4 | .NET SchUseStrongCrypto와 SystemDefaultTlsVersions를 적용하다. | 업무 프로그램의 외부 HTTPS 실패를 줄이는 효과이다. |
| 5 | WinHTTP DefaultSecureProtocols를 점검하다. | 레거시 에이전트/서비스의 TLS 1.2 미사용 문제를 줄이는 효과이다. |
| 6 | 인증서 체인과 신뢰 저장소, SSL 검사 정책을 점검하다. | 42, 46 계열 반복을 줄이는 효과이다. |
FAQ
Schannel 36887이 많이 떠도 인터넷은 정상이라면 그냥 두어도 되나?
서비스 장애가 전혀 없고 특정 외부 스캐너나 구형 장비 접속이 차단되는 로그로 판단되면 관찰 우선 전략을 택하는 방식이 합리적이다.
다만 분당 발생량이 급증하거나 특정 업무 기능 실패가 동반하면 즉시 조치가 필요하다.
경고 코드가 70으로 나오면 무엇부터 바꾸어야 하나?
70은 프로토콜 협상 실패 범주로 분류하는 접근이 우선이다.
Schannel에서 TLS 1.2 활성화 상태를 확인하고, .NET 및 WinHTTP 기본 TLS 설정을 함께 점검하는 순서가 실무 표준이다.
경고 코드가 42 또는 46으로 반복되면 어떤 축이 핵심인가?
인증서 체인과 신뢰 저장소 축이 핵심이다.
서버 인증서 만료, 체인 누락, 호스트명 불일치, 그리고 SSL 검사 장비의 가짜 체인 개입 여부를 우선 확인하는 방식이 효과적이다.
레지스트리를 바꾸었는데도 로그가 계속 발생하면 다음 단계는 무엇인가?
연결 주체 식별이 충분하지 않은 상태일 가능성이 크다고 판단하다.
netsh trace로 재현 구간을 짧게 잡아 수집하고, PID와 프로세스를 역추적하여 문제 프로그램 또는 대상 엔드포인트를 확정하는 단계가 다음 단계이다.