- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows 시스템 로그에 반복적으로 기록되는 Schannel 이벤트 ID 36887 “알림 레벨 치명적 오류”의 원인을 정확히 분류하고, 현장에서 바로 적용 가능한 점검 절차와 설정 조치로 재발을 줄이거나 근본 해결하는 방법을 제공하는 것이다.
1. Schannel 36887을 “오류”로만 보면 해결이 안 되는 이유
Schannel 이벤트 ID 36887은 Windows의 TLS/SSL 구성요소(Schannel)가 원격 통신 상대와 보안 연결을 협상하는 과정에서 “치명적(Fatal) 경고(Alert)”를 받았거나 교환했다고 기록하는 이벤트이다. 핵심은 “원인 범주가 매우 넓다”는 점이다. 같은 36887이라도 실제 원인은 프로토콜 버전 불일치, 암호군(Cipher Suite) 불일치, 인증서 체인/신뢰 문제, SNI/호스트명 불일치, 프록시/보안장비의 HTTPS 검사, 레거시 앱의 구형 TLS 사용, 시스템 시간 오류 등으로 갈린다.
따라서 36887을 단순히 “레지스트리 몇 개 수정”으로 접근하면 한쪽 환경에서는 해결되지만 다른 환경에서는 부작용이 생기거나 원인이 숨겨져 재발한다. 이 글은 “증상 → 원인 범주 → 확인 포인트 → 조치” 순으로 정리한다.
주의 : Schannel 관련 레지스트리 변경(TLS 버전 비활성화, 암호군 정책 변경, 인증서 저장소 수정)은 서비스 중단을 유발할 수 있다. 운영 서버는 반드시 변경관리(점검 시간, 롤백 계획, 영향 범위)를 선행하고 적용해야 한다.
2. 먼저 확인해야 할 이벤트 내용(알림 코드, 프로세스, 대상)
2.1 이벤트 본문에서 반드시 확인할 항목
이벤트 뷰어에서 System 로그의 Schannel 36887을 열고 아래 항목을 확인한다.
| 확인 항목 | 의미 | 다음 단계 |
|---|---|---|
| “TLS protocol defined fatal alert code is XX” | 협상 실패의 큰 방향(버전/인증서/핸드셰이크)을 좁히는 단서이다. | 아래 3장 ‘알림 코드별 원인’로 분기한다. |
| 로그 발생 빈도/시각 | 특정 스케줄 작업, 백신 업데이트, 배치 통신, 사용자 로그인 시점과 연관될 수 있다. | 작업 스케줄러, 서비스 재시작, 업데이트 시간과 대조한다. |
| 클라이언트/서버 역할 | 이 PC가 연결을 “시도”했는지, “수신”했는지에 따라 조치가 달라진다. | 서버라면 인바운드 TLS 설정/IIS/LDAPS 등을 점검한다. |
| 관련 애플리케이션 추정 | 이벤트 자체만으로 프로세스가 항상 나오지 않는다. | Schannel 로깅/네트워크 로그로 프로세스를 특정한다. |
2.2 Schannel 이벤트 로깅을 강화해 “누가” 발생시키는지 찾기
36887은 결과 로그에 가깝고, 원인 추적을 위해 추가 로깅이 필요할 때가 많다. Schannel 이벤트 로깅을 강화하면(환경에 따라) 더 많은 단서(추가 이벤트, 내부 상태)가 남는다.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" ^ /v EventLogging /t REG_DWORD /d 7 /f설정 값 7은 가능한 항목을 넓게 기록하도록 하는 용도로 사용된다. 적용 후에는 재부팅이 필요할 수 있다. 로그가 과다해질 수 있으므로 원인 파악 후에는 값 원복 또는 기록 범위 축소를 검토한다.
주의 : 로깅 강화는 “원인 규명”을 위한 임시 조치로 운용하는 것이 안전하다. 장기간 유지하면 이벤트 로그가 빠르게 증가해 분석이 어려워질 수 있다.
3. 알림 코드(XX)별로 원인 범주를 빠르게 좁히기
이벤트 메시지에 “TLS protocol defined fatal alert code is XX”가 포함되는 경우가 많다. 코드는 환경마다 다양하지만, 실무에서 자주 만나는 패턴을 아래 표로 정리한다. 코드는 ‘힌트’이며 단독으로 확정 진단이 되지 않으므로, 4장 점검 절차로 반드시 교차 확인해야 한다.
| 자주 보이는 코드 | 현장 의미(실무 해석) | 대표 원인 | 우선 조치 |
|---|---|---|---|
| 70 | 상대가 요구/허용하는 TLS 버전이 맞지 않다. | 서버가 TLS 1.2+만 허용, 클라이언트가 TLS 1.0/1.1로 시도(레거시 앱, 구형 .NET, 구형 장비) | 클라이언트/서버 TLS 버전 정합, 레거시 앱 업데이트 또는 정책 예외 범위 최소화 |
| 40 | 핸드셰이크 자체가 성립하지 못했다. | 암호군 불일치, 중간장비(프록시/검사) 개입, 인증서 처리 실패, SNI/호스트명 문제 | 암호군/인증서/프록시 여부를 순서대로 점검 |
| 46, 48 | 인증서 관련 문제 가능성이 높다. | 신뢰 체인 미구성(루트/중간CA 누락), 인증서 만료, EKU/용도 부적합, 이름 불일치 | 인증서 체인/신뢰 저장소/서버 인증서 교체 점검 |
| 42 | 상대가 인증서 또는 협상 조건을 수용하지 않았다. | 검사장비의 정책 차단, 서버 측 인증서 체인 오류, 취약 암호군 차단 | 보안장비 정책/서버 인증서 체인/암호군 확인 |
| 20 | 인증서 유효성/검증 단계에서 중단되는 패턴이 있다. | CRL/OCSP 접근 실패, 체인 검증 오류, 특정 업데이트 이후 호환성 문제 | 검증 경로(인터넷/프록시) 및 업데이트/정책 영향 확인 |
4. 현장에서 통하는 표준 점검 절차(클라이언트 기준 → 서버 기준 순)
4.1 1단계: “어떤 프로그램/서비스가 연결을 시도했는지”부터 특정
36887이 반복되면 원인 프로세스가 거의 항상 존재한다. 아래 순서로 범위를 줄인다.
1) 발생 시각을 기준으로, 같은 시간대에 아래 이벤트가 함께 있는지 확인한다.
- Schannel 36874, 36888, 36871 등 인접 이벤트
- 애플리케이션 로그(.NET, 특정 에이전트, 업데이트 클라이언트) 오류
- 작업 스케줄러 실행 기록
2) 서버 환경이라면, 해당 시각에 인바운드 접속 로그(IIS 로그, LDAPS, SMTP TLS 로그 등)와 매칭한다.
3) 보안 제품(백신/EDR), 프록시, SSL 가시화 장비가 있다면 해당 장비의 이벤트와 대조한다.
4.2 2단계: 시스템 시간/시간대 오류부터 배제
TLS 인증서 검증은 시간에 민감하다. 시스템 시간이 틀리면 정상 인증서도 만료/미유효로 판단될 수 있다.
w32tm /query /status w32tm /resync도메인 환경에서는 도메인 시간 동기 정책(GPO, NTP 소스)도 함께 확인한다.
4.3 3단계: 프록시/보안장비의 HTTPS 검사(SSL Inspection) 여부 확인
프록시 또는 보안장비가 TLS를 “중간에서 종료 후 재암호화”하는 구조라면, 클라이언트 입장에서는 서버 인증서가 장비가 발급한 사설 인증서로 바뀐다. 이때 루트 인증서를 신뢰하지 않거나 정책이 바뀌면 36887이 급증한다.
확인 포인트는 아래와 같다.
- 사내 네트워크에서는 발생하지만 외부망/테더링에서는 발생하지 않는가
- 브라우저에서 해당 사이트 인증서 발급자가 공인 CA가 아니라 사내 CA/장비명으로 보이는가
- 특정 보안 업데이트 이후 갑자기 빈도가 증가했는가
조치는 “루트 인증서 배포” 또는 “검사 예외(대상 도메인/프로세스)” 중에서 보안 정책에 맞게 선택한다. 운영 관점에서는 예외를 최소화하고, 사내 루트 인증서의 배포/갱신 체계를 갖추는 쪽이 재발이 적다.
4.4 4단계: TLS 버전 불일치(특히 코드 70) 점검
서버가 TLS 1.2 이상만 허용하는데, 클라이언트(레거시 앱)가 TLS 1.0/1.1로 시도하면 협상 실패가 반복된다. 반대로, 클라이언트가 보안강화를 위해 TLS 1.0/1.1을 꺼버렸는데 내부 시스템이 아직 TLS 1.0만 지원하는 경우에도 동일하게 실패한다.
4.4.1 Windows Schannel 프로토콜 활성화 상태 확인(레지스트리)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" /s실무에서 많이 쓰는 구성 예시는 아래와 같다. (운영 적용 전 반드시 대상 시스템/업무 영향 검토가 필요하다.)
rem TLS 1.0 비활성화(서버/클라이언트) reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 0 /f
rem TLS 1.1 비활성화(서버/클라이언트)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 0 /f
rem TLS 1.2 활성화(서버/클라이언트)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f주의 : TLS 1.0/1.1 비활성화는 보안적으로 권장되는 방향이지만, 내부 레거시 시스템(구형 NAS, 프린터, 구형 WAS, 오래된 API 게이트웨이 등)이 TLS 1.0/1.1에 의존하면 즉시 장애가 발생한다. 장애가 우려되면 먼저 “누가 TLS 1.0/1.1로 접속 시도하는지”를 식별한 뒤 단계적으로 적용해야 한다.
4.5 5단계: 암호군(Cipher Suite) 불일치 점검(핸드셰이크 실패/코드 40 빈발)
보안강화 정책으로 특정 암호군을 비활성화했는데, 상대가 지원 가능한 암호군이 남아 있지 않으면 36887이 반복된다. 특히 오래된 클라이언트/서버 조합, 또는 정책 템플릿을 강하게 적용한 서버에서 빈발한다.
Windows에서는 그룹 정책 또는 로컬 보안 정책으로 TLS 암호군 우선순위/허용 목록이 바뀔 수 있다. 점검은 아래 항목을 중심으로 한다.
- 최근 적용된 보안 기준(템플릿, CIS, 사내 하드닝) 변경 이력
- 특정 서비스만 실패하는지(예: LDAPS만, HTTPS만, SMTP STARTTLS만)
- 상대 시스템이 매우 구형인지(구형 Java, 구형 OpenSSL, 구형 장비 펌웨어)
운영 환경에서는 “전체 완화”가 아니라 “필요한 최소 암호군만 추가”하는 방식이 안전하다. 적용 전에는 동일 환경의 테스트 장비에서 통신 성공 여부를 검증해야 한다.
4.6 6단계: 인증서 체인/신뢰 문제 점검(코드 46/48/42 계열 의심)
TLS에서 가장 흔한 실무 이슈는 “서버 인증서는 있어 보이지만 체인이 완전하지 않은” 경우이다. 예를 들어 서버가 중간 인증서를 누락한 채로 서비스를 올리면, 어떤 클라이언트는 AIA로 중간 인증서를 찾아와 통과하지만, 다른 클라이언트는 정책/네트워크/검증 제한 때문에 실패한다. 그 결과가 36887로 남을 수 있다.
4.6.1 클라이언트(또는 서버)의 신뢰 저장소 점검 포인트
- 루트 CA가 “신뢰할 수 있는 루트 인증 기관”에 있는가
- 중간 CA가 “중간 인증 기관”에 있는가
- 같은 이름의 루트/중간이 여러 개 있고 일부가 만료/폐지 상태인가
- 사내 프록시/검사장비 루트 인증서가 갱신되었는데 단말 배포가 누락되었는가
4.6.2 서버 인증서 자체 점검 포인트
- CN/SAN에 실제 접속 호스트명이 포함되는가(SNI 환경에서 특히 중요하다)
- 만료일이 지났거나 임박하지 않았는가
- 용도(EKU)가 서버 인증에 적합한가(서버 인증/클라이언트 인증 혼동 여부)
- 서버가 중간 인증서를 포함한 “전체 체인”을 제공하는가
5. “무시해도 되는 로그”와 “반드시 잡아야 하는 로그” 구분 기준
일부 환경에서는 특정 외부 사이트, 광고/텔레메트리, 구형 엔드포인트에 대한 백그라운드 연결 시도 때문에 36887이 간헐적으로 발생할 수 있다. 그러나 다음 조건이면 단순 무시가 아니라 원인 규명이 필요하다.
| 구분 | 판단 기준 | 권장 대응 |
|---|---|---|
| 무시 가능 범주(제한적) | 업무 영향 없음, 매우 낮은 빈도, 특정 외부 도메인/레거시 대상에 한정, 내부 보안정책상 해당 통신이 불필요함이 명확 | 발생 주체 식별 후 차단(정책/방화벽) 또는 로그 모니터링만 유지 |
| 반드시 조치 필요 | 업무 시스템 접속 실패 동반, 동일 시각 반복(스팸 수준), 서버 서비스(ADFS/LDAPS/IIS/API)에서 발생, 업데이트/정책 변경 직후 급증 | 4장 절차대로 원인 분류 후 TLS/암호군/인증서/프록시 정책을 근본 조정 |
주의 : “로그가 많아 거슬린다”는 이유로 TLS 보안을 낮추는 방향(TLS 1.0 재활성화, 취약 암호군 재허용)을 먼저 선택하면, 보안 감사/침해 리스크가 급격히 증가한다. 우선은 원인 프로세스와 대상 엔드포인트를 특정하고, 업그레이드/교체/예외 최소화로 정리하는 것이 정석이다.
6. 실무에서 자주 쓰는 원인-조치 매핑(체크리스트)
| 현장 증상 | 가능성이 높은 원인 | 확인 방법 | 조치 |
|---|---|---|---|
| 코드 70이 반복되며 특정 레거시 프로그램 사용 시만 발생 | 레거시 앱이 TLS 1.0/1.1만 지원 | 해당 앱 버전/.NET 버전/서버 허용 TLS 확인 | 앱 업데이트 또는 TLS 1.2 지원 설정 전환, 불가하면 예외 범위 최소화 |
| 사내망에서만 발생, 외부망에서는 정상 | 프록시/보안장비 HTTPS 검사 | 인증서 발급자 확인, 장비 로그 대조 | 사내 루트 인증서 배포/갱신, 정책 예외 최소 적용 |
| 서버 교체/인증서 갱신 직후 일부 클라이언트만 실패 | 중간 인증서 누락 또는 체인 불완전 | 서버가 전체 체인 제공 여부 확인 | 서버 인증서 체인 구성 수정(중간CA 포함), 클라이언트 신뢰 저장소 정리 |
| 보안 하드닝 후 36887 증가 + 특정 서비스만 장애 | 암호군 불일치/정책 과도 | 하드닝 정책 변경 이력, 상대 시스템 지원 범위 확인 | 필요 최소 암호군만 추가/우선순위 조정 |
| 도메인/서버에서 간헐적 인증서 오류, 다른 시스템도 시간 오차 | 시간 동기 문제 | w32tm 상태/오차 확인 | NTP/도메인 시간 동기 정상화 |
7. FAQ
Schannel 36887이 뜨는데 인터넷/업무는 정상이다. 그래도 조치해야 하나?
업무 영향이 전혀 없고 빈도가 낮다면 즉시 보안 설정을 바꿀 필요는 없다. 다만 같은 시간대에 반복적으로 폭증하거나, 특정 서버/업무 시스템에서 발생하거나, 업데이트/정책 변경 직후 증가했다면 원인 프로세스를 특정해 정리해야 한다. “정상처럼 보이는 상태”에서도 특정 통신이 지속 실패하는 경우가 있어, 보안 감사나 장애 전조로 이어질 수 있다.
코드 70이면 무조건 TLS 1.0/1.1을 켜야 하나?
그렇게 처리하면 빠르게 “연결”은 될 수 있지만 보안 위험이 크다. 우선 누가 TLS 1.0/1.1로 시도하는지(레거시 앱/장비/라이브러리)를 찾고, 업데이트나 TLS 1.2 지원 설정으로 해결하는 것이 우선이다. 불가피한 경우에도 예외 범위를 최소화하고 대체 계획을 동시에 추진해야 한다.
프록시/보안장비 HTTPS 검사 때문에 생기는 36887은 어떻게 줄이나?
사내 루트 인증서 배포가 누락되거나 만료/교체되었을 때 급증하는 경우가 많다. 단말/서버에 최신 루트 인증서가 배포되었는지 확인하고, 장비 정책 변경 이력(검사 대상 확대, 차단 규칙 변경)을 함께 점검해야 한다. 특정 업무 시스템은 정책 예외가 필요할 수 있으나, 예외는 최소화하는 것이 운영 안정성과 보안성 모두에 유리하다.
암호군 문제인지 인증서 문제인지 구분이 어렵다. 가장 빠른 순서는 무엇인가?
현장에서는 “발생 주체 프로세스 특정 → 사내망/외부망 비교로 중간장비 여부 판단 → TLS 버전 정합 확인 → 인증서 체인 점검 → 암호군 정책 점검” 순이 성공률이 높다. 특히 사내망에서만 발생한다면 중간장비 가능성이 높고, 특정 서버 교체/인증서 갱신 직후라면 체인 이슈 가능성이 높다.