이 글의 목적은 Windows에서 TLS 1.2가 비활성화되어 발생하는 웹사이트 접속 실패를 빠르게 진단하고, Schannel 레지스트리 복구와 WinHTTP/.NET 설정까지 포함해 재발 없이 정상화하는 절차를 현장에서 그대로 따라 할 수 있도록 정리하는 것이다.
1. TLS 1.2 비활성화 시 나타나는 대표 증상
TLS 1.2는 현재 대부분의 웹사이트와 서비스가 기본으로 요구하는 보안 통신 프로토콜이다. Windows에서 TLS 1.2가 꺼져 있으면 브라우저뿐 아니라 업데이트, 로그인 모듈, 사내 그룹웨어, ERP, 백신/에이전트, 프린트 드라이버 관리 콘솔 등 다양한 프로그램이 동시에 실패하는 형태로 나타나기 쉽다.
| 증상 | 화면/에러 예시 | 가능성이 높은 원인 | 우선 조치 |
|---|---|---|---|
| 특정 사이트만 접속 실패 | ERR_SSL_VERSION_OR_CIPHER_MISMATCH, 보안 연결 실패 | TLS 1.2 비활성화 또는 구형 암호군만 허용 | Internet Options TLS 1.2 체크 및 Schannel 확인 |
| 브라우저는 되는데 프로그램이 실패 | .NET/WinHTTP 통신 오류, “서버가 보안 연결을 지원하지 않음” | WinHTTP 기본 프로토콜 미설정, .NET Strong Crypto 미적용 | DefaultSecureProtocols, SchUseStrongCrypto 적용 |
| 사내 보안정책 적용 후 전체 장애 | 업무 사이트·에이전트·업데이트 동시 실패 | GPO/보안 베이스라인이 TLS 1.2까지 비활성화 | 레지스트리 값 및 정책 배포 이력 확인 |
| Windows 7/2008 R2에서 특히 빈발 | 어제까지 되던 서비스가 갑자기 차단 | 기본값이 TLS 1.0/1.1 중심, 업데이트/키 누락 | KB 적용 + WinHTTP 키 추가 + Schannel 키 생성 |
2. 먼저 확인해야 하는 빠른 체크(레지스트리 수정 전에 3분 점검)
2.1 Internet Options에서 TLS 1.2 체크 확인
Windows의 많은 구성 요소는 “인터넷 옵션(Internet Options)”의 고급 보안 설정과 Schannel 설정의 영향을 받는다. 우선 다음을 확인해야 한다.
1) 제어판 → 인터넷 옵션(Internet Options) 2) [고급] 탭 → [보안] 섹션 3) "TLS 1.2 사용" 체크가 꺼져 있으면 켠다. 4) 브라우저/프로그램을 모두 종료 후 재실행한다.2.2 회사 정책(GPO) 또는 보안 솔루션에 의해 다시 꺼지는지 확인
체크를 켰는데 재부팅 후 다시 꺼진다면, 그룹 정책(GPO), 보안 기준 템플릿, EDR/보안 에이전트가 레지스트리를 강제로 덮어쓰는 경우가 흔하다. 이 경우는 “레지스트리 복구”를 해도 재발하므로, 정책 배포 구간(AD OU/로컬 보안 정책/보안 솔루션 규칙)을 함께 점검해야 한다.
3. 핵심 원리: TLS는 Schannel(Windows 보안 채널)에서 켜고 끄는 구조이다
Chrome/Edge/IE 등 대부분의 Windows 기반 브라우저와 다수 프로그램은 Windows의 Schannel을 통해 TLS를 협상한다. 따라서 TLS 1.2 복구의 핵심은 다음 경로에 TLS 1.2의 Client/Server 키를 정상 값으로 만드는 것이다.
4. 레지스트리 복구 1단계: Schannel에서 TLS 1.2(Client/Server) 활성화
4.1 적용 대상
Windows 10/11, Windows Server 2012 이상, Windows 8.1, Windows 7(업데이트 상태에 따라 추가 조치 필요)에 공통으로 적용하는 기본 복구 단계이다.
4.2 레지스트리 경로와 권장 값
아래 경로에 키가 없으면 생성해야 한다. 값이 있더라도 DisabledByDefault가 1로 되어 있거나 Enabled가 0이면 TLS 1.2가 사실상 꺼진 상태가 된다.
| 레지스트리 경로 | 값 이름 | 형식 | 권장 값 | 의미 |
|---|---|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client | Enabled | DWORD(32-bit) | 1 | 클라이언트 측 TLS 1.2 사용 |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client | DisabledByDefault | DWORD(32-bit) | 0 | 기본 비활성화 방지 |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server | Enabled | DWORD(32-bit) | 1 | 서버 측 TLS 1.2 사용(서버 역할 시) |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server | DisabledByDefault | DWORD(32-bit) | 0 | 기본 비활성화 방지 |
4.3 regedit로 수동 복구 절차
1) 시작 메뉴 → regedit 실행(관리자 권한 권장) 2) 다음 경로로 이동 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols 3) "TLS 1.2" 키가 없으면 생성한다. 4) TLS 1.2 아래에 "Client", "Server" 키를 각각 생성한다. 5) 각 키에 DWORD(32-bit) 값 2개를 만든다. - Enabled = 1 - DisabledByDefault = 0 6) 재부팅한다.4.4 .reg 파일로 일괄 복구(권장)
현장에서는 수동 작업보다 .reg 파일로 표준화하는 편이 실수가 적다. 아래 내용을 메모장에 붙여 넣고 파일명을 예를 들어 Enable_TLS12_Schannel.reg로 저장한 뒤, 관리자 권한으로 병합 실행하는 방식이 일반적이다.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [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:000000015. 레지스트리 복구 2단계: “프로그램만” 접속 실패하는 경우(WinHTTP 기본 프로토콜 설정)
브라우저는 접속되는데 특정 프로그램(업데이트 모듈, 에이전트, 구형 런처, 일부 백신 콘솔, 다운로드 도구 등)만 접속이 실패한다면, 해당 프로그램이 WinHTTP를 사용하면서 기본 보안 프로토콜이 TLS 1.2를 포함하지 않는 상태일 가능성이 크다. 특히 Windows 7/Server 2008 R2 계열에서 빈도가 높다.
5.1 WinHTTP DefaultSecureProtocols 키 적용
아래 키가 없으면 생성한다. 64비트 OS에서는 Wow6432Node 경로도 같이 적용해야 32비트 프로세스가 영향을 받는다.
| 대상 | 레지스트리 경로 | 값 이름 | 권장 값(HEX) | 설명 |
|---|---|---|---|---|
| 64비트/32비트 공통 | HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp | DefaultSecureProtocols | 0x00000A00 | TLS 1.1(0x200) + TLS 1.2(0x800) 포함이다. |
| 64비트 OS에서 32비트 앱용 | HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp | DefaultSecureProtocols | 0x00000A00 | 32비트 프로세스 WinHTTP 기본값 보정이다. |
일부 환경에서는 TLS 1.0까지 병행 허용이 필요할 수 있으나, 보안상 권장하지 않는다. 부득이하게 TLS 1.0을 포함해야 하면 값이 달라진다. 다만 일반적인 “사이트 접속 안됨” 복구 목적은 TLS 1.2를 살리는 것이므로 0x00000A00을 기본으로 사용한다.
5.2 .reg 파일 예시(WinHTTP 포함)
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:00000a006. 레지스트리 복구 3단계: .NET 기반 프로그램이 실패하는 경우(Strong Crypto 및 OS 기본 TLS 사용)
업무 프로그램이 .NET Framework 기반이라면, Schannel에서 TLS 1.2가 켜져 있어도 .NET 런타임이 “강한 암호화(Strong Crypto)”를 사용하지 않거나, OS 기본 TLS 구성을 따르지 않아 TLS 1.2 협상을 하지 못하는 경우가 있다. 이때는 아래 2개 설정이 핵심이다.
6.1 SchUseStrongCrypto 및 SystemDefaultTlsVersions 적용
아래는 대표 경로이다. 64비트 OS에서는 Wow6432Node 경로도 같이 적용하는 편이 안전하다. 값은 DWORD(32-bit)로 1을 사용한다.
| 레지스트리 경로 | 값 이름 | 권장 값 | 설명 |
|---|---|---|---|
| HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 | SchUseStrongCrypto | 1 | .NET이 강한 암호화(TLS 1.1/1.2)를 사용하도록 유도한다. |
| HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 | SystemDefaultTlsVersions | 1 | .NET이 OS의 TLS 설정을 따르도록 한다. |
| HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 | SchUseStrongCrypto | 1 | 32비트 .NET 앱에 적용하기 위한 경로이다. |
| HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 | SystemDefaultTlsVersions | 1 | 32비트 .NET 앱이 OS TLS를 따르도록 한다. |
6.2 .reg 파일 예시(.NET 포함)
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:000000017. 운영체제별 추가 체크 포인트(Windows 7 포함)
Windows 10/11은 기본적으로 TLS 1.2 사용이 일반적이지만, 정책이나 레지스트리 변경으로 꺼진 경우가 있다. Windows 7/Server 2008 R2는 업데이트/기본값 구조상 TLS 1.2 관련 키를 “직접 만들어야 하는 케이스”가 존재한다. 따라서 OS별로 다음 항목을 같이 점검해야 한다.
| 구분 | 중점 확인 | 권장 조치 | 재부팅 필요 |
|---|---|---|---|
| Windows 11/10 | GPO/보안 솔루션이 TLS 1.2를 비활성화했는지 | Schannel TLS 1.2 Client/Server 정상화 후 정책 원인 제거 | 권장 |
| Windows Server 2016/2019/2022 | 서버 역할(IIS/리버스프록시)에서 Server 키가 꺼져 있는지 | Client/Server 모두 활성화 및 서비스 재시작/재부팅 | 권장 |
| Windows 8.1/Server 2012 R2 | 프로그램(WinHTTP/.NET)만 실패하는지 | Schannel + WinHTTP + .NET 조합 적용 | 권장 |
| Windows 7/Server 2008 R2 | Schannel 키 존재 여부와 WinHTTP 기본값 미설정 | Schannel 키 생성 + WinHTTP DefaultSecureProtocols + .NET Strong Crypto | 필수 |
8. 복구 후 정상 여부 확인 방법(현장 검증 체크리스트)
8.1 레지스트리 값 확인(명령어)
GUI 대신 명령으로 확인하면 누락이 빠르게 드러난다.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols
reg query "HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319" /v SchUseStrongCrypto8.2 브라우저 및 프로그램 동작 검증
브라우저 검증은 “문제 사이트 재접속”이 가장 확실하다. 프로그램 검증은 업데이트/로그인/동기화 등 실제 TLS 통신이 발생하는 기능을 실행하여 확인해야 한다.
8.3 curl로 TLS 협상 확인(가능한 환경에서)
Windows에 기본 포함되는 curl 또는 설치된 curl이 Schannel을 사용할 때, 연결 로그에 TLS 버전이 표시되는 경우가 있다. 환경에 따라 출력이 다를 수 있으나, 최소한 “핸드셰이크 실패”가 사라지는지 확인하는 데 도움이 된다.
curl -Iv https://대상도메인9. 자주 발생하는 실수와 재발 방지 포인트
9.1 “TLS 1.2만 켰는데도 안됨”의 가장 흔한 원인
첫째, 재부팅을 하지 않아 Schannel이 재로딩되지 않은 경우이다. 둘째, WinHTTP 또는 .NET 설정이 빠진 경우이다. 셋째, 정책(GPO/보안 솔루션)이 재부팅 시 값을 다시 덮어쓰는 경우이다.
9.2 레지스트리 키가 다시 바뀌는 경우의 대응
변경 후 정상화되었다가 며칠 후 다시 장애가 재발하면, “수동 복구”는 근본 해결이 아니다. 다음을 확인해야 한다.
1) 그룹 정책 결과 확인(도메인 환경) 2) 보안 솔루션의 암호화 정책/레거시 프로토콜 차단 정책 확인 3) 표준 이미지(골든 이미지) 또는 배포 스크립트에 TLS 비활성화 항목이 포함되었는지 확인 4) 변경 관리(누가 언제 어떤 스크립트를 배포했는지) 점검9.3 보안 관점에서의 권장 운영
현 시점의 일반적인 권장 방향은 “TLS 1.2 이상 사용”이다. 다만 레거시 장비/프로그램이 TLS 1.0/1.1에 의존하는 경우가 아직 남아 있어, 무리하게 구버전 프로토콜을 동시에 끄면 업무 장애가 생길 수 있다. 따라서 접속 실패의 직접 원인이 “TLS 1.2 비활성화”인지 먼저 확정하고, 그 다음 단계로 레거시 프로토콜의 단계적 정리를 설계하는 편이 운영 안정성이 높다.
10. 현장용 통합 복구 REG 샘플(한 번에 적용)
아래는 “Schannel TLS 1.2 + WinHTTP + .NET(4.x)”를 한 번에 적용하는 예시이다. 조직 표준에 맞춰 파일명과 배포 방식만 정하면 현장 대응 시간이 크게 줄어든다.
Windows Registry Editor Version 5.00 ; ===== Schannel: TLS 1.2 enable ===== [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [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 ; ===== WinHTTP: default secure protocols ===== [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 ; ===== .NET Framework 4.x: strong crypto + system default TLS ===== [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:00000001FAQ
TLS 1.2를 켰는데도 특정 사이트가 계속 접속 안되는 이유는 무엇인가?
원인이 TLS 1.2 하나로 끝나지 않는 경우가 있다. 대표적으로 프록시/SSL 검사 장비의 정책, 클라이언트 시간 오류, 루트 인증서/중간 인증서 누락, 보안 제품의 HTTPS 가로채기, 오래된 브라우저 엔진 또는 암호군 제한이 원인이 될 수 있다. 다만 “TLS 1.2 비활성화”가 확인된 환경이라면 Schannel 복구와 재부팅을 먼저 완료해야 다음 원인 진단이 정확해진다.
브라우저는 되는데 사내 프로그램만 안된다. 무엇을 먼저 적용해야 하는가?
WinHTTP DefaultSecureProtocols와 .NET SchUseStrongCrypto/SystemDefaultTlsVersions 적용을 우선 순위로 두는 편이 실무적으로 빠르다. 특히 Windows 7/Server 2008 R2 계열에서는 Schannel만 켜서는 부족한 경우가 흔하다. 통합 reg를 적용하고 재부팅한 뒤 프로그램 기능(로그인/업데이트/동기화)을 재시험하는 방식이 효율적이다.
레지스트리 키가 없는데 만들어도 괜찮은가?
Schannel의 TLS 1.2 관련 하위 키는 환경에 따라 기본 생성이 되지 않을 수 있다. 키가 없으면 Windows가 해당 프로토콜을 기본 비활성화로 취급하는 경우가 있어, 현장에서는 키를 생성하고 Enabled/DisabledByDefault 값을 명시하는 방식으로 정상화를 진행하는 사례가 많다. 다만 변경 전 백업과 재부팅은 필수이다.
적용 후 반드시 재부팅해야 하는가?
대부분의 경우 재부팅이 필요하다. 특히 Schannel 설정은 프로세스 재시작만으로 완전 반영이 되지 않거나, 이미 로드된 보안 구성으로 통신이 시도되어 동일 증상이 반복될 수 있다. 운영 환경에서는 계획된 재부팅 또는 서비스 재시작 절차를 포함해 적용하는 편이 안정적이다.
회사 보안정책 때문에 TLS가 다시 꺼진다. 현장에서는 어떻게 처리해야 하는가?
현장 단에서는 임시 복구로 업무를 살리되, 재발 방지를 위해 정책 배포 경로를 확인해야 한다. 도메인 환경이면 GPO 결과를 추적하고, 보안 솔루션이면 암호화 정책 템플릿을 확인해야 한다. “어떤 정책이 어떤 키를 덮어쓰는지”를 특정하면 근본 해결이 가능하다.