ERR_SSL_VERSION_OR_CIPHER_MISMATCH: 지원되지 않는 프로토콜 해결

ERR_SSL_VERSION_OR_CIPHER_MISMATCH란 무엇입니까?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH는 브라우저와 웹사이트가 연결을 어떤 방식으로 암호화할지 합의하지 못했다는 오류입니다. Chrome에는 "사이트에 보안 연결할 수 없음"과 "example.com에서 지원되지 않는 프로토콜을 사용합니다."가 표시되고, 세부 정보에는 "클라이언트와 서버가 일반적인 SSL 프로토콜 버전 또는 암호화 제품군을 지원하지 않습니다."라고 나옵니다. Chromium은 이 오류를 -113으로 정의합니다(net_error_list.h).

이 오류는 TLS 핸드셰이크의 가장 첫 단계에서 발생합니다. 브라우저가 자신이 지원하는 TLS 버전과 cipher suite 목록을 보내면, 서버는 각각 하나씩 골라야 합니다. 서버에 목록과 겹치는 항목이 없거나, 브라우저가 더 이상 받아들이지 않는 버전으로 응답하거나, 요청한 도메인 이름의 인증서가 없어 더 진행하지 못하면 핸드셰이크는 그 자리에서 멈춥니다.

인증서를 검사하기 전에 실패하므로, 만료되었거나 이름이 맞지 않거나 체인이 잘못된 인증서는 다른 오류로 표시됩니다(끝부분의 표 참조). Firefox는 cipher나 인증서 문제로 거부되면 SSL_ERROR_NO_CYPHER_OVERLAP을, TLS 1.0/1.1만 지원하는 서버에는 SSL_ERROR_UNSUPPORTED_VERSION을 표시합니다.

각 브라우저에서 오류가 표시되는 모습

Chromium 기반 브라우저(Chrome, Edge, Brave, Opera)는 모두 같은 코드를 표시합니다. 아래 표시를 찾아보십시오.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH의 원인

오류가 한 웹사이트에서만 나타난다면 원인은 그 사이트의 서버나 CDN입니다. 여러 웹사이트에서 나타난다면 사용하는 기기나 네트워크의 중간에 무언가가 끼어 있는 것입니다. 원인은 다음과 같습니다.

• 서버가 TLS 1.0 또는 1.1만 지원합니다. Chrome, Edge, Firefox는 2020년에 두 버전을 차단하기 시작했고(Firefox 78, Chrome과 Edge 84), Chrome 98(2022년)부터는 우회할 방법이 없습니다. Chromium은 이런 서버를 이 오류로 보고합니다(net_error_list.h).
• 서버가 오래된 cipher만 제공합니다. RC4, 3DES, 수출 등급 제품군 등입니다. Chrome의 TLS 코드는 3DES를 완전히 꺼 두었기 때문에, 그것밖에 제공하지 않는 서버에는 접속할 수 없습니다.
• 입력한 도메인 이름의 인증서가 없습니다(일부 CDN). Cloudflare와 CloudFront에서는 인증서가 없는 호스트 이름의 핸드셰이크를 첫 단계에서 거부합니다. Cloudflare에서는 이것이 가장 흔한 원인으로, 인증서가 아직 활성화 중이거나, 레코드가 프록시를 거치지 않거나, 사용자 지정 인증서가 만료되었는데 대신할 것이 없거나, 도메인이 다단계 서브도메인인 경우입니다(Cloudflare). 일반 nginx나 Apache 서버는 대신 기본 인증서를 보내므로 이름 불일치 경고가 표시됩니다.
• 중간에 있는 것. 백신의 HTTPS 검사, 회사 프록시, 오래된 TLS 설정으로 트래픽을 다시 암호화하는 VPN 등입니다.
• 매우 오래된 기기나 브라우저. Windows XP, Android 4.x, 몇 년째 업데이트하지 않은 브라우저에는 서버가 지금 요구하는 TLS 1.2나 cipher가 없습니다.

직접 해 보았습니다: 오래된 TLS 서버와 최신 클라이언트

이 오류를 일으키는 조건을 보여 드리기 위해, 2026년 10월 27일에 최신 TLS 클라이언트(OpenSSL 3.6)로 badssl.com의 공개 테스트 서버에 접속했습니다. TLS 1.0과 1.1 서버는 클라이언트가 더 이상 받아들이지 않는 버전으로 응답했고, RC4와 3DES 서버는 handshake_failure 경고로 거부했습니다. Chrome은 네 가지 모두 ERR_SSL_VERSION_OR_CIPHER_MISMATCH로 표시합니다.

Chrome에서 https://tls-v1-0.badssl.com:1010/ 을 열면 바로 이 오류 페이지가 나타납니다. 본인 사이트가 처음 네 줄과 같은 상태라면 아래 웹사이트 소유자용 해결 방법이 해당됩니다.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결 방법 (사용자용)

웹사이트의 서버는 사용자가 바꿀 수 없으므로, 먼저 누구의 문제인지 확인해야 합니다. 한 사이트만 실패한다면 소유자만 해결할 수 있으니 웹사이트 소유자용 해결 방법으로 넘어가십시오. 여러 사이트가 실패한다면 아래 방법을 시도하십시오. (예전부터 알려진 "QUIC 끄기"는 여기서는 도움이 되지 않습니다. QUIC 실패는 ERR_QUIC_PROTOCOL_ERROR로 표시됩니다.)

해결법 1: 사이트 쪽 문제인지 확인

같은 사이트를 다른 기기나 모바일 데이터로 열어 보십시오. 거기서도 실패한다면 서버가 문제입니다.

확실하게 알아보려면 DNS Robot의 SSL Checker에 사이트를 입력하십시오. 대부분의 서버에 대해 지원하는 TLS 버전이 나열되고, Cloudflare의 사이트라면 해당 도메인 이름의 인증서가 발급되었는지도 보여 줍니다. TLS 1.0 또는 1.1만 지원하는 사이트는 Chrome, Edge, Firefox에서 열 수 없으며 클릭해서 넘어갈 방법도 없습니다. Chrome은 이 오류에 "계속 진행" 링크를 제공하지 않습니다.

해결법 2: 브라우저와 운영 체제 업데이트

매우 오래된 브라우저와 시스템에는 TLS 1.2, TLS 1.3 또는 서버가 지금 사용하는 cipher가 없습니다. Chrome은 chrome://settings/help, Edge는 edge://settings/help에서 업데이트한 다음 운영 체제도 업데이트하십시오.

Windows XP와 Vista의 Internet Explorer, 그리고 Android 4.0~4.3의 기본 브라우저는 오늘날의 cipher로 TLS 1.2를 사용할 수 없어 대부분의 HTTPS 사이트에서 실패합니다.

해결법 3: 백신의 HTTPS 검사 확인

HTTPS를 검사하는 백신 프로그램(Avast, Kaspersky, Bitdefender, ESET, Norton)은 모든 연결의 중간에 들어가 웹사이트와 자체 TLS 연결을 맺습니다. 이 TLS 설정이 오래되었다면 최신 TLS를 요구하는 사이트에서 실패합니다.

HTTPS 검사 기능만 끄십시오. 이름은 제품마다 다릅니다(Avast의 Web Shield HTTPS 검사, ESET의 SSL/TLS 프로토콜 필터링, Bitdefender의 암호화된 웹 검사, Kaspersky의 암호화된 연결 검사). 끈 다음 새로 고침하십시오. 오류가 사라지면 검사를 계속 끄지 말고 백신을 업데이트하거나 해당 사이트를 예외로 추가하십시오.

해결법 4: VPN 또는 프록시 연결 해제

회사 프록시와, 웹 보호나 HTTPS 검사 기능이 있는 VPN은 사이트와 자체 TLS 연결을 맺습니다(일반적인 VPN 터널은 그렇지 않습니다). 연결을 해제하고 새로 고침하십시오. 사이트가 열린다면 해당 기능을 끄거나, 제공업체(또는 회사 IT 팀)에 TLS 설정 업데이트를 요청하십시오.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결 방법 (웹사이트 소유자용)

방문자가 사이트에서 이 오류를 신고한다면, 포트 443에서 응답하는 서버나 CDN이 최신 브라우저와 TLS에 합의하지 못하는 것입니다. SSL Checker로 확인한 뒤 다음을 진행하십시오.

해결법 1: 모든 도메인 이름에 인증서가 있는지 확인

Cloudflare, CloudFront 및 일부 다른 CDN에서는 인증서가 없는 호스트 이름의 핸드셰이크가 거부되며, 브라우저에는 인증서 경고 대신 이 오류가 표시됩니다. 일반 nginx나 Apache 서버는 보통 기본 인증서를 대신 보내거나(ERR_CERT_COMMON_NAME_INVALID), nginx의 ssl_reject_handshake를 쓰면 unrecognized_name 경고(ERR_SSL_UNRECOGNIZED_NAME_ALERT)가 나옵니다. 방문자가 쓰는 모든 이름, 즉 example.com, www.example.com, 각 서브도메인을 확인하십시오.

각 이름을 SSL Checker로 검사하거나 터미널에서 테스트하십시오(OpenSSL 1.1.1 이상. "Could not find certificate"가 나오면 서버가 그 이름의 핸드셰이크를 거부한 것입니다).

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

해결법 2: TLS 1.2 및 TLS 1.3 활성화

현재의 모든 브라우저는 최소 TLS 1.2를 필요로 합니다. TLS 1.2와 TLS 1.3을 활성화하고 그보다 오래된 버전은 켜지 마십시오.

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

다시 로드한 뒤 SSL Checker나 Qualys SSL Labs로 다시 테스트하여 TLS 1.2와 1.3만 제공되는지 확인하십시오.

해결법 3: 최신 cipher suite 제공

TLS 1.2를 켰다면, 서버가 브라우저가 여전히 받아들이는 cipher를 제공해야 합니다. AES-GCM 또는 ChaCha20-Poly1305와 함께 ECDHE를 제공하십시오(Mozilla의 권장 세트). RC4, 3DES, 수출 등급, NULL cipher는 거부됩니다.

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# Apache
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

해결법 4: Cloudflare 관련 수정

Cloudflare의 자체 가이드는 호스트 이름이 인증서에 포함되지 않을 때 이 오류가 발생한다고 설명합니다(Cloudflare). 다음 순서로 확인하십시오.

• 인증서가 활성(Active) 상태입니까? 새 도메인의 Universal SSL 인증서는 15분에서 24시간 안에 발급됩니다. SSL/TLS → Edge Certificates에서 상태가 Active여야 합니다.
• DNS 레코드가 프록시를 거칩니까? 인증서는 프록시(주황색 구름) 레코드에만 제시됩니다. 프록시 이름을 DNS Lookup으로 조회하면 서버 주소가 아니라 Cloudflare의 주소가 반환됩니다.
• 사용자 지정 인증서가 만료되었습니까? Cloudflare는 만료된 인증서를 제거합니다. 그 이름을 포함하는 다른 활성 인증서(Universal SSL 등)가 없다면 방문자에게 인증서 경고 대신 이 오류가 표시됩니다.
• 다단계 서브도메인입니까? 전체 설정(full setup)에서 Universal SSL이 포함하는 것은 example.com과 *.example.com뿐이며 test.dev.example.com은 포함하지 않습니다. Advanced 또는 사용자 지정 인증서, 혹은 Total TLS(Advanced Certificate Manager 필요)를 사용하십시오.

해결법 5: 다른 CDN과 로드 밸런서 확인

CDN이나 로드 밸런서(CloudFront, Fastly, Akamai, 클라우드 로드 밸런서)가 TLS 연결을 종료한다면, 결정하는 것은 서버가 아니라 그쪽 설정입니다.

• 올바른 배포나 리스너에 연결된, 모든 호스트 이름의 인증서
• 보안 정책의 최소 TLS 1.2와 최신 cipher
• 여러 도메인이 하나의 IP 주소를 공유한다면 SNI 지원

SSL 구성을 테스트하는 방법

변경한 뒤에는 SSL 설정이 올바른지 확인하십시오. 다음 도구로 방문자보다 먼저 문제를 찾을 수 있습니다.

• DNS Robot SSL Checker — 인증서 상태, 만료일, 체인 완전성, 발급자를 빠르게 확인합니다. 몇 초 만에 결과가 나옵니다.
• Qualys SSL Labs — TLS 버전, cipher suite, 프로토콜 지원, 알려진 취약점을 정밀하게 검사하고 알파벳 등급을 매깁니다(A 또는 A+를 목표로 하십시오).
• OpenSSL CLI — 명령줄에서 openssl s_client -connect domain.com:443을 실행하면 원시 핸드셰이크, 인증서 체인, 협상된 cipher를 볼 수 있습니다.
• Chrome DevTools — 열리는 페이지라면 Security(또는 Privacy and security) 패널에서 사용된 TLS 버전과 cipher를 확인할 수 있습니다.

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

관련 SSL/TLS 오류

Chrome에는 TLS와 인증서 관련 오류가 여러 가지 있으며, 각각 다른 단계에서 발생합니다.

인접한 오류 가이드: ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID, 연결이 비공개로 설정되어 있지 않습니다.