ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결법: 구형 TLS 강제 해제와 SSL 검사 중간장비 우회 가이드

이 글의 목적은 크롬 등 브라우저에서 발생하는 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류를 신속히 진단하고, 구형 TLS 강제 설정 및 SSL 검사 중간장비로 인한 문제를 안전하게 해제하거나 우회하여 서비스 가용성을 회복하도록 돕는 것이다.

오류 의미와 동작 원리

ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류는 클라이언트와 서버가 TLS 프로토콜 버전 또는 암호군(cipher suite)에 합의하지 못해 핸드셰이크가 실패할 때 발생한다. 브라우저는 ClientHello에서 지원 가능한 TLS 버전과 암호군을 제시하고, 서버는 ServerHello로 선택 결과를 응답한다. 두 측의 교집합이 없거나, 인증서 체인 요구 조건과 확장(SNI, ALPN 등)이 충족되지 않으면 세션 수립에 실패한다.

현장에서 자주 보이는 원인은 다음과 같다.

서버가 TLS 1.0·1.1만 허용하거나 RC4·3DES 같은 구형 암호군만 허용하는 경우이다.
기업망 SSL 검사(HTTPS Proxy, TLS Break-and-Inspect) 장비가 중간자 역할을 하며 구형 정책을 강제 적용하는 경우이다.
서버 인증서의 키 타입과 암호군 정책이 불일치하는 경우이다.
SNI 미사용 가상호스팅에서 인증서가 일치하지 않는 경우이다.
ALPN 미지원으로 HTTP/2 협상 과정에서 호환 문제가 발생하는 경우이다.
HSTS 정책으로 HTTP 강제 리다이렉트가 불가한 상태에서 구성이 상충되는 경우이다.

10분 복구 퀵가이드

다른 네트워크로 재시도한다. 휴대폰 테더링 등 외부망으로 접속하여 기업 SSL 검사 영향 여부를 분리한다.
브라우저 프로필을 교차 검증한다. 시크릿 모드와 타 브라우저에서 재현되는지 확인한다.
운영자가 서버 측이라면 온라인 TLS 검사 도구 대신 로컬에서 openssl s_client -connect 도메인:443 -tls1_2 -servername 도메인으로 지원 버전과 인증서 체인을 점검한다.
중간장비가 의심되면 보안팀에 해당 도메인을 SSL 검사 예외 목록에 등록하도록 요청한다.
서버는 TLS 1.2 이상을 반드시 허용하고, TLS 1.0·1.1은 비활성화한다.
암호군은 현대적 스위트(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 등) 위주로 구성한다.
서버 인증서 체인을 최신 중간인증서로 완성하고 키 길이 2048비트 이상을 확인한다.
가상호스팅이면 SNI를 활성화하고, 서버 블록별로 올바른 인증서를 매핑한다.
ALPN을 활성화하되 HTTP/2가 문제를 유발하면 일시적으로 HTTP/1.1로 강등하여 확인한다.
캐시와 HSTS를 초기화한다. 클라이언트에서 사이트별 HSTS 삭제 후 재시도한다.

원인별 확인 체크리스트

영역	점검 항목	권장 조치
클라이언트	브라우저·OS TLS 1.2/1.3 지원 여부	최신 브라우저 사용, OS 업데이트 실시
클라이언트	로컬 프록시·보안 확장프로그램	프록시·필터 확장 해제 후 재시도
네트워크	SSL 검사 프록시 사용 여부	대상 도메인 예외 처리 또는 SSL 검사 일시 해제
서버	TLS 버전 정책	TLS 1.2 이상만 허용, 1.0·1.1 비활성화
서버	암호군 목록	ECDHE+AESGCM 우선, RC4·3DES 제외
서버	SNI·ALPN 설정	SNI 필수, ALPN h2·http/1.1 동시 제공
서버	인증서 체인 완성도	서버+중간+루트 체인 정확히 제공
DNS	레코드 지연 전파·CDN 엣지 구성	전파 완료 확인, CDN TLS 정책 점검
정책	HSTS 강제, 구형 리다이렉트	HSTS 유지하되 서버 구성 일치화

중간장비(SSL 검사)로 인한 장애 분리 방법

기업·학교망의 SSL 검사 장비는 TLS 세션을 복호화하여 검사한 뒤 재암호화한다. 이 과정에서 장비가 구형 암호정책을 강제하거나, 내부 발급 루트로 재서명된 인증서를 사용한다. 다음 절차로 영향 여부를 판단한다.

문제 도메인 접속 시 인증서 발급자를 확인한다. 내부 CA 이름이 표시되면 SSL 검사 중이다.
사설망과 외부망에서 동일 도메인의 TLS 버전·암호군 협상 결과를 비교한다.
SSL 검사 우회 정책 존재 여부를 보안팀에 확인한다. 금융·개인건강정보 페이지 등은 통상 예외로 설정한다.
임시 복구가 필요하면 해당 도메인을 검사 예외로 등록한다. 장비에 따라 FQDN·SAN·와일드카드가 구분되므로 정확히 입력한다.

보안 유지와 가용성 균형을 위해 장기적으로는 TLS 1.2 이상 정책으로 장비를 업데이트하고 현대적 암호군을 수용하도록 구성하는 것이 바람직하다.

서버 측 표준 구성 가이드

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers   'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
               ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
               TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
server {
  listen 443 ssl http2;
  server_name example.com;
  ssl_certificate     /etc/ssl/fullchain.pem;   # 서버+중간 체인
  ssl_certificate_key /etc/ssl/privkey.pem;
}

Apache httpd

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:
                        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
                        ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     on
SSLUseStapling          on
Protocols               h2 http/1.1

IIS

Windows 서버에서는 레지스트리 또는 그룹정책으로 TLS 1.0·1.1을 사용 안 함으로 설정하고 TLS 1.2를 사용으로 설정한다. 또한 Schannel의 암호군 우선순위를 현대적으로 구성한다. 인증서는 최신 중간체인을 포함하도록 갱신한다.

인증서·체인·서명 알고리즘 점검

서버 인증서는 키 길이 2048비트 이상 RSA 또는 ECDSA를 사용한다.
서명 알고리즘은 SHA-256 이상을 사용한다.
중간인증서가 누락되면 일부 클라이언트에서 체인 구축에 실패한다. 웹서버가 fullchain을 제공하도록 설정한다.
와일드카드·SAN 구성은 실제 호스트명과 일치해야 한다.

SNI, ALPN, HTTP/2 관련 유의사항

여러 도메인을 하나의 IP로 서비스하면 SNI가 필수이다. 클라이언트가 SNI를 전송하지 않거나 서버가 SNI를 처리하지 못하면 올바른 인증서를 제공하지 못해 오류가 발생한다. ALPN은 애플리케이션 계층 프로토콜 협상으로 HTTP/2 또는 HTTP/1.1 전송 방식을 결정한다. 특정 장비가 ALPN을 처리하지 못하는 경우 HTTP/2를 일시 해제하고 문제를 분리한다.

HSTS와 혼선 해소

대상 도메인이 HSTS를 적용하면 브라우저는 항상 HTTPS로만 접속한다. 서버가 최신 TLS를 제공하지 못하면 우회가 어렵다. 임시로 테스트하려면 개발 환경 하위 서브도메인을 분리하여 HSTS를 적용하지 않고 검증한다. 운영 도메인의 HSTS를 임의 해제하는 것은 권장하지 않는다.

클라이언트 측 확인 명령어

# 서버가 TLS 1.2로 협상되는지 확인
openssl s_client -connect example.com:443 -tls1_2 -servername example.com

# 지원 암호군 스캔(간단)

nmap --script ssl-enum-ciphers -p 443 example.com

레거시 시스템과의 공존 전략

사내 폐쇄망에서만 접근 가능한 별도 레거시 엔드포인트를 운영한다.
외부 공개 서비스는 TLS 1.2 이상만 허용하고, 내부 마이크로세그먼트에서만 예외를 허용한다.
애플리케이션 업그레이드 로드맵을 수립하고 종료기한을 명확히 한다.

사례별 트러블슈팅 시나리오

사례 1: 특정 회사망에서만 오류 발생

외부망에서는 정상이나 회사망에서만 실패한다면 SSL 검사 장비가 구형 암호군을 사용 중일 가능성이 크다. 예외 목록 등록 후 즉시 복구가 되는지 확인한다. 이후 장비 정책을 업데이트한다.

사례 2: 신규 인증서 교체 후 일부 단말에서만 오류

체인에 필요한 중간인증서가 누락되었을 수 있다. fullchain 제공 여부를 확인하고 OCSP Stapling을 활성화한다. 오래된 단말 루트스토어 업데이트도 병행한다.

사례 3: CDN 적용 후 간헐적 오류

CDN 엣지 노드별 TLS 정책 또는 SNI 라우팅이 일관되지 않을 수 있다. TLS 정책 템플릿을 최신으로 통일하고, 엣지 인증서 상태를 점검한다.

브라우저별 진단 팁

Chrome: 주소창 chrome://net-internals/#events에서 실패 이벤트를 확인한다. 프로필을 새로 만들어 재현 여부를 교차 확인한다.
Edge/IE 레거시: OS의 Schannel 설정에 영향을 받으므로 Windows 업데이트와 레지스트리 정책을 점검한다.
Firefox: 자체 루트스토어를 사용하므로 기업망의 내부 CA 배포 여부를 확인한다.

조치 우선순위 정리

서비스 가용성 복구를 위해 중간장비 예외 설정 또는 최신 정책 업데이트를 즉시 적용한다.
서버는 TLS 1.2 이상, 현대적 암호군, SNI·ALPN 활성화를 표준으로 채택한다.
인증서 체인을 완성하고 자동 갱신 절차에 체인 검증을 포함한다.
레거시 호환은 폐쇄망에서만 제한적으로 허용한다.

현장 점검용 체크리스트 다운로드용 포맷

번호	점검 항목	확인 결과
1	문제 재현 환경 분리(외부망/사내망)	정상/비정상
2	SSL 검사 장비 영향 확인 및 예외 등록	예/아니오
3	TLS 1.2·1.3 서버 허용	예/아니오
4	암호군 현대화(ECDHE+AESGCM)	예/아니오
5	SNI·ALPN 활성화	예/아니오
6	인증서 체인 완성 및 유효기간 확인	예/아니오
7	CDN 엣지·DNS 전파 상태 확인	예/아니오
8	클라이언트 캐시·HSTS 초기화	예/아니오

FAQ

브라우저에서 사용자가 TLS 1.0을 강제로 허용하면 해결되는가?

권장하지 않는다. 일시적 테스트 목적이라도 보안 위험이 크다. 서버와 중간장비를 최신 정책으로 수정하는 것이 정답이다.

SSL 검사 예외 등록이 어렵다면 어떻게 하나?

테스트 전용 외부망을 사용하거나, 대상 서비스의 별도 도메인을 분리해 보안 정책의 충돌을 줄이는 방법을 고려한다.

HTTP/2를 끄면 해결되는 경우가 있다. 계속 꺼둘까?

근본 원인은 ALPN 처리 문제 또는 중간장비 호환성이다. 장비와 서버를 업데이트한 뒤 HTTP/2를 다시 활성화하는 것이 바람직하다.

인증서가 유효한데도 오류가 난다. 왜 그런가?

인증서 유효성 외에도 TLS 버전·암호군·SNI 등 여러 요소가 협상에 관여한다. 체인이 완성되어 있어도 구형 정책 강제나 협상 불일치가 있으면 오류가 발생한다.

레거시 클라이언트 지원을 위해 TLS 1.0을 유지해야 한다면?

공개망에서는 유지하지 않는다. 폐쇄망 또는 별도 엔드포인트로 분리하여 리스크를 한정한다.

ZeroError_holic

이 블로그 검색

파워포인트 자막(라이브 캡션) 안될 때 1분 진단과 완전 해결 가이드