- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 크롬 등 크로미움 기반 브라우저에서 자주 발생하는 ERR_SSL_PROTOCOL_ERROR의 기술적 원인을 체계적으로 설명하고, 개인 사용자와 관리자 모두가 현장에서 바로 적용할 수 있는 복구 절차와 서버·네트워크 측 예방 대책을 제공하는 것이다.
1. 오류 개요와 진단 프레임
ERR_SSL_PROTOCOL_ERROR는 클라이언트와 서버가 TLS 핸드셰이크를 완료하지 못해 HTTPS 연결을 수립하지 못했음을 의미한다.
브라우저는 TLS 버전 협상, 암호군 선택, 서버 인증서 검증, 확장값 교환(SNI, ALPN, OCSP Stapling 등)을 순차 수행한다.
어느 단계에서든 불일치나 차단이 발생하면 연결이 중단되고 본 오류가 출력된다.
실무에서는 사용자 측 환경 문제와 서버·네트워크 구성 문제를 분리 진단하는 것이 시간을 절약하는 최적 전략이다.
아래 표는 원인 범주와 대표 증상을 요약한 것이다.
| 범주 | 대표 원인 | 주요 증상 | 우선 조치 |
|---|---|---|---|
| 클라이언트 | 시스템 시간 불일치, 손상된 SSL 캐시·쿠키, 구버전 브라우저, 확장프로그램 간섭, 보안SW의 SSL 검사 | 특정 사이트만 또는 전역으로 간헐 오류 | 시간 동기화, SSL 상태 초기화, 시크릿 모드 재시도, 보안SW HTTPS 검사 해제 |
| 네트워크 | 기업망 SSL 검사 프록시, 미승인 프록시, 공용 와이파이 포털, DNS 변조, MTU/패킷 차단, QUIC 차단 | 사내만 재현, 공용망에서 정상 | 프록시 바이패스, DNS 교정, QUIC 비활성화 시험, 다른 네트워크 비교 |
| 서버·CDN | TLS 버전·암호군 미호환, SNI 미구성, 인증서 체인 누락, 만료, 개인키 불일치, HTTP→HTTPS 리다이렉트 루프, CDN 모드 설정 문제 | 모든 사용자가 장애, 특정 클라이언트군만 장애 | 체인 재구성, TLS1.2/1.3 허용, ALPN·SNI 점검, 리다이렉트 규칙 정합성 검토 |
2. TLS 핸드셰이크 핵심 이해
핸드셰이크는 ClientHello와 ServerHello로 시작하며, 버전(TLS1.2/1.3), 암호군, 압축, 확장(SNI로 호스트 지정, ALPN으로 HTTP/2·HTTP/3 선택)을 협상한다.
이후 서버 인증서 체인과 키 교환이 진행되고, 완료 메시지로 대칭키 통신이 개시된다.
다음 조건이 실패하면 본 오류가 발생한다.
- 클라이언트가 제시한 버전·암호군과 서버 지원값의 교집합이 없을 때이다.
- 서버 인증서 체인에 중간CA가 누락되었거나 만료되었을 때이다.
- 요청 호스트명과 인증서 CN/SAN이 불일치하거나 SNI 가상호스팅이 누락되었을 때이다.
- 보안 장비가 TLS 세션을 가로채거나 QUIC/HTTP3를 비선호 환경에서 부분 차단할 때이다.
3. 사용자 측 빠른 복구 체크리스트
- 시스템 시간 동기화: 운영체제 시간을 인터넷 시간 서버와 동기화한다.
- 시크릿 모드 재시도: 확장프로그램 간섭을 배제한다.
- 브라우저·OS 최신화: 크로미움 기반 브라우저와 OS 보안 업데이트를 적용한다.
- SSL 상태 초기화: Windows에서 Internet Options > Content > Clear SSL State를 실행한다.
- 캐시·쿠키 정리: 해당 도메인 또는 전체를 삭제 후 재시도한다.
- 보안SW의 HTTPS 검사 일시 해제: 백신·방화벽의 SSL 검사 기능을 잠시 꺼서 원인 분리한다.
- QUIC 비활성화 시험: chrome://flags 또는 edge://flags에서 Experimental QUIC Protocol을 Disabled로 설정하고 재기동한다.
- 네트워크 전환: 다른 와이파이·테더링으로 비교하여 네트워크 이슈를 분리한다.
- DNS 새로고침: ipconfig /flushdns 또는 네트워크 재시작을 수행한다.
4. 브라우저별 상세 절차
4.1 Chrome·Edge(Windows)
- 시크릿 창에서 접속을 시험한다.
- 설정 > 개인정보 및 보안 > 인터넷 사용 기록 삭제에서 캐시·쿠키를 삭제한다.
- Windows 검색에서 Internet Options 실행 후 Content 탭에서 Clear SSL State를 클릭한다.
- chrome://flags에서 Experimental QUIC protocol을 Disabled로 설정하고 재시작한다.
- 확장프로그램을 모두 꺼 본 뒤 한 개씩 켠다.
4.2 macOS Chrome·Safari
- 시스템 설정 > 일반 > 날짜와 시간에서 자동 설정을 활성화한다.
- 키체인 접근에서 문제 인증서가 있는지 확인하고 제거한다.
- 새 사용자 프로필로 테스트하여 프로필 손상을 배제한다.
4.3 모바일(Android·iOS)
- 기기 시간 자동 설정을 켠다.
- 앱 캐시 삭제 후 재시작한다.
- 모바일 데이터로 전환하거나 다른 와이파이로 재시도한다.
- 기업 MDM 기기라면 정책상 SSL 검사 여부를 관리자에게 확인한다.
5. 기업망·보안장비 환경 점검
SSL Inspection이 활성화된 프록시·방화벽은 사내 루트CA를 배포하고 TLS를 중간 복호화한다.
사내 루트CA 미배포, TLS1.3 미지원, HTTP/3 일부 차단, SNI 필터링 등과 결합되면 본 오류가 빈발한다.
- 프록시 자동 설정(PAC)에서 대상 도메인의 BYPASS 예외를 추가한다.
- 사내 루트CA 체인을 모든 단말 신뢰 저장소에 배포한다.
- QUIC 차단 정책이 있는 경우 HTTP/2 우선 사용을 보장하도록 ALPN 정책을 정합화한다.
- DNS 보안 게이트웨이 사용 시 내·외부 레졸버 간 불일치를 해소한다.
6. 서버·CDN 운영자용 근본 원인 분석
6.1 인증서 체인
- 서버에 풀체인 파일을 배포하여 루트 직전 중간CA까지 포함한다.
- 개인키와 인증서의 일치 여부를 지문 또는 모듈러스 비교로 확인한다.
- 만료 30일 이전 자동 갱신과 무중단 재기동 절차를 구현한다.
6.2 TLS 버전·암호군·ALPN
- TLS1.2와 TLS1.3을 모두 허용한다.
- ALPN에서 h2, http/1.1을 제공하고 HTTP/3는 환경에 맞춰 점진 활성화한다.
- 구형 암호군 의존 제거와 모던 암호군 우선순위를 설정한다.
6.3 SNI·가상호스팅
- 멀티 도메인 환경에서 서버 이름 표시를 처리하도록 SNI 구성을 확인한다.
- wildcard·SAN 구성을 도메인별 리스너와 일치시킨다.
6.4 리다이렉트·HSTS
- HTTP→HTTPS 301 리다이렉트 규칙을 단일 지점으로 통합한다.
- 서브도메인 포함 preload 사용 시 모든 하위 도메인의 인증서 준비 상태를 보장한다.
6.5 CDN·프록시
- 원본↔CDN 구간도 TLS 종단을 강제하고 인증서를 배치한다.
- CDN 모드 설정 불일치로 인한 루프 또는 버전 불일치를 제거한다.
7. 서버 구성 예시
7.1 Nginx 예시
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/ssl/fullchain.pem; # 중간CA 포함 체인이다.
ssl_certificate_key /etc/ssl/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / { proxy_pass [http://app](http://app); }
}
7.2 Apache httpd 예시
<VirtualHost *:443> ServerName example.com SSLEngine on SSLCertificateFile /etc/ssl/fullchain.pem SSLCertificateKeyFile /etc/ssl/privkey.pem SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite TLSv1.3+TLSv1.2 Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" </VirtualHost>
8. 현장 진단 커맨드 모음
| 목적 | 도구 | 명령 | 해석 포인트 |
|---|---|---|---|
| TLS 협상·체인 확인 | OpenSSL | openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1 -tls1_2 | 중간CA 유무, ALPN, 버전 호환을 확인한다. |
| HTTP/2 확인 | curl | curl -I --http2 https://example.com | HTTP/2 협상 정상 여부를 확인한다. |
| 포트 개방 | PowerShell | Test-NetConnection example.com -Port 443 | 방화벽·경로 차단 여부를 확인한다. |
| DNS 확인 | nslookup | nslookup example.com | 의도한 IP로 해석되는지 확인한다. |
| QUIC 차단 영향 | curl | curl -I --http3 https://example.com | HTTP/3 지원과 오류 재현 여부를 확인한다. |
9. 케이스별 빠른 처방
9.1 특정 사이트만 오류
- 해당 도메인 쿠키·캐시 삭제 후 재시도한다.
- 브라우저 프로필을 새로 만들어 시험한다.
- 다른 네트워크에서 동일 재현이면 서버측 체인·리다이렉트·SNI 검토를 요청한다.
9.2 사내에서만 오류
- 프록시 자동 구성 파일에서 목적지 바이패스를 설정한다.
- SSL 검사 프록시의 루트CA가 모든 단말에 신뢰 배포되어 있는지 확인한다.
- 방화벽이 QUIC/UDP 443을 부분 차단할 경우 HTTP/2 우선 사용으로 강제한다.
9.3 전역적으로 모든 사이트 오류
- 시스템 시간 동기화와 보안SW HTTPS 검사 해제를 우선 확인한다.
- 네트워크 게이트웨이 재기동과 DNS 설정 복구를 수행한다.
- 브라우저와 OS를 최신으로 업데이트한다.
10. 예방 모범 구성
- 인증서 자동 갱신과 체인 검증 파이프라인을 CI로 구축한다.
- 서버·CDN에서 TLS1.2·1.3을 동시 제공하고 모던 암호군을 우선한다.
- ALPN에 h2를 항상 포함하고 HTTP/3는 점진 활성화한다.
- HSTS를 적용하되 preload 사용 시 모든 서브도메인의 인증서 준비도를 확보한다.
- 프록시·방화벽 정책 변경 시 캔어리 테스트와 단계적 롤아웃을 시행한다.
11. 자주 하는 실수와 방지 포인트
- 중간CA를 빠뜨리고 서버 인증서만 배치하는 실수를 반복한다.
- HTTP에서 HTTPS로 다중 단계 리다이렉트를 구성하여 루프를 유발한다.
- 하이브리드 환경에서 내부 DNS와 공인 DNS가 서로 다른 레코드를 반환한다.
- 보안장비가 TLS1.3을 다운그레이드하면서 특정 브라우저 조합에서 실패한다.
12. 현장 점검 체크리스트 다운로드용 텍스트
[사용자] - 시간 동기화 완료 여부 확인 - 시크릿 모드·다른 네트워크 재시도 - 캐시·쿠키·SSL 상태 초기화 - 보안SW HTTPS 검사 비활성화 시험 - QUIC 비활성화 시험 [관리자] * 인증서 풀체인·만료·키 일치 확인 * TLS1.2/1.3·ALPN(h2/http/1.1) 제공 * SNI·가상호스팅 매핑 검증 * 리다이렉트 규칙 단일화·루프 제거 * CDN 원본↔엣지 TLS 일관성 보장 * 프록시·방화벽 SSL 검사 정책 점검
FAQ
브라우저에서만 오류가 나고 앱은 정상인 이유는 무엇인가
브라우저는 QUIC/HTTP3를 우선 시도하거나 확장프로그램·프록시 영향을 받기 쉽기 때문이다.
SSL 상태 초기화는 무엇을 지우는가
Windows의 WinINet 캐시에 저장된 세션·인증서 관련 캐시를 지워 재협상을 유도한다.
QUIC을 꺼도 안전한가
기능 검증을 위한 일시적 비활성화는 문제 원인 분리에 유효하며, 상시 비활성화는 네트워크 정책과 성능 영향 평가 후 결정해야 한다.
인증서가 정상인데도 오류가 지속되는 경우는 무엇인가
중간CA 체인 누락, SNI 미설정, ALPN 미일치, 프록시의 TLS 간섭 같은 비인증서 요인이 원인일 수 있다.
공용 와이파이에서만 오류가 나는 이유는 무엇인가
캡티브 포털이 HTTPS를 가로채거나 프록시·DNS가 재작성되기 때문이다.