ERR_SSL_VERSION_OR_CIPHER_MISMATCH: 해결 방법 완벽 가이드 (모든 브라우저)

ERR_SSL_VERSION_OR_CIPHER_MISMATCH란 무엇입니까?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH는 브라우저와 웹 서버가 SSL/TLS 핸드셰이크 과정에서 공통 TLS 프로토콜 버전 또는 암호화 cipher suite에 합의할 수 없을 때 나타나는 브라우저 오류입니다. 안전한 채널을 설정할 수 없기 때문에 브라우저가 연결 자체를 완전히 차단합니다.

모든 HTTPS 연결은 TLS 핸드셰이크로 시작됩니다. 이 핸드셰이크 과정에서 브라우저는 지원하는 TLS 버전과 cipher suite 목록(ClientHello)을 전송합니다. 서버는 자신도 지원하는 항목 중 하나를 선택하여 응답(ServerHello)합니다. 겹치는 항목이 전혀 없는 경우 — 서버가 브라우저에서 더 이상 지원하지 않거나 인식하지 못하는 프로토콜 또는 cipher만 제공하는 경우 — 핸드셰이크가 즉시 이 오류와 함께 실패합니다.

기본 Chromium 오류 코드는 net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH입니다. Firefox에서는 동일한 실패가 SSL_ERROR_NO_CYPHER_OVERLAP으로 표시됩니다. 두 오류 모두 같은 의미입니다: 클라이언트와 서버가 보안 연결을 위한 공통 기반이 없다는 것입니다.

각 브라우저에서 오류가 어떻게 표시되는지

브라우저마다 동일한 TLS 협상 실패에 대해 서로 다른 오류 메시지를 표시합니다. Chrome의 전체 오류 메시지는 다음과 같습니다: "이 사이트는 보안 연결을 제공할 수 없습니다. [도메인]이(가) 지원되지 않는 프로토콜을 사용합니다."

ERR_SSL_VERSION_OR_CIPHER_MISMATCH의 원인

이 오류에는 서버 측 원인과 클라이언트 측 원인이 모두 있습니다. 특정 웹사이트 하나에서만 오류가 나타나면 거의 확실히 서버 문제입니다. 여러 웹사이트에서 나타나면 사용자의 기기나 네트워크에서 무언가가 간섭하고 있는 것입니다.

• 서버가 더 이상 사용되지 않는 TLS 1.0 또는 TLS 1.1을 사용 — Chrome, Edge, Firefox, Safari 모두 2020년에 TLS 1.0 및 1.1 지원을 중단했습니다. 서버가 이러한 이전 프로토콜만 제공하면 최신 브라우저는 연결을 거부합니다. 이것이 서버 측 원인 1위입니다.

• 취약하거나 더 이상 사용되지 않는 cipher suite — RC4(2016년 Chrome 48에서 제거), 3DES, 수출 등급 cipher와 같은 cipher suite는 모든 최신 브라우저에서 차단됩니다. 서버가 이러한 cipher만 제공하면 핸드셰이크가 실패합니다.

• SHA-1 서명 인증서 — 브라우저는 2017년에 SHA-1 인증서 신뢰를 중단했습니다. 인증서가 SHA-256 대신 SHA-1을 사용하면 거부됩니다.

• 만료된 SSL 인증서 — 만료된 인증서는 일부 브라우저에서 더 일반적인 ERR_CERT_DATE_INVALID 대신 이 오류를 발생시킬 수 있으며, 특히 다른 잘못된 구성과 결합된 경우에 그렇습니다.

• 인증서 이름 불일치 — SSL 인증서가 example.com용으로 발급되었지만 www.example.com(또는 인증서가 적용되지 않는 하위 도메인)으로 사이트에 접속하는 경우입니다.

• 불완전한 인증서 체인 — 중간 인증서가 누락되면 브라우저가 신뢰 체인을 확인할 수 없습니다. 자세한 내용은 SSL 인증서 체인 가이드를 참조하세요.

• Cloudflare/CDN 잘못된 구성 — 사이트가 Cloudflare를 사용하는 경우 SSL 인증서가 아직 활성화되지 않았거나(최대 24시간 소요), DNS 레코드가 Proxied 대신 DNS-only로 설정되어 있거나, 다중 수준 하위 도메인이 Universal 인증서에 포함되지 않을 수 있습니다.

• 오래된 운영 체제 — Windows XP, Android 4.x 및 기타 레거시 OS 버전은 TLS 1.2 또는 최신 cipher suite를 지원하지 않으므로 이를 요구하는 서버에 연결할 수 없습니다.

• 백신 프로그램의 HTTPS 스캔 — Avast, Kaspersky, Bitdefender 등의 보안 소프트웨어가 자체 인증서로 HTTPS 연결을 가로채면서 cipher 불일치가 발생할 수 있습니다.

• 브라우저 또는 기기 업데이트 필요 — 매우 오래된 브라우저 버전은 서버가 요구하는 cipher suite를 지원하지 않을 수 있습니다.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결 방법 (사용자용)

웹을 탐색하는 중에 이 오류가 나타나면 해당 웹사이트의 서버 측 SSL 문제일 가능성이 높습니다. 하지만 먼저 사용자 측에서 시도할 수 있는 몇 가지 방법이 있습니다. 오류가 한 사이트에서만 나타나면 웹사이트 소유자 수정 항목으로 건너뛰세요 — 서버 문제입니다. 여러 사이트에서 나타나면 다음 사용자 수정 방법을 시도해 보세요.

해결법 1: SSL 상태 초기화 (Windows)

Windows는 브라우저와 별도로 SSL 인증서와 세션 데이터를 캐시합니다. 이 시스템 수준 캐시의 오래되거나 손상된 항목은 브라우저 캐시를 지운 후에도 지속적인 cipher 불일치 오류를 일으킬 수 있습니다.

시작 메뉴를 열고 인터넷 옵션을 검색합니다(또는 Win+R을 누르고 inetcpl.cpl을 입력합니다). 콘텐츠 탭으로 이동하여 SSL 상태 지우기를 클릭합니다. 확인을 클릭하고 브라우저를 다시 시작합니다.

해결법 2: 브라우저 캐시 및 쿠키 삭제

캐시된 HSTS(HTTP Strict Transport Security) 정책이나 오래된 SSL 세션 티켓이 브라우저가 오래된 매개변수로 연결을 시도하도록 강제할 수 있습니다.

• Chrome/Edge: Ctrl+Shift+Delete를 누르고 → 전체 기간으로 설정 → 캐시된 이미지 및 파일과 쿠키 선택 → 데이터 삭제 클릭

• Firefox: Ctrl+Shift+Delete를 누르고 → 전체로 설정 → 캐시와 쿠키 선택 → 지금 지우기 클릭

• Safari: Safari 메뉴 → 설정 → 개인 정보 보호 → 웹사이트 데이터 관리 → 모두 제거

특정 도메인의 경우 Chrome에서 HSTS 항목을 개별적으로 삭제할 수도 있습니다: chrome://net-internals/#hsts로 이동 → "도메인 보안 정책 삭제"에서 → 도메인을 입력 → 삭제를 클릭합니다.

해결법 3: QUIC 프로토콜 비활성화

Chrome의 QUIC 프로토콜(UDP를 통한 HTTP/3)은 이를 제대로 지원하지 않는 서버나 443번 포트에서 UDP를 차단하는 네트워크 장비에서 TLS 협상을 방해할 수 있습니다.

• 1단계: 주소 표시줄에 chrome://flags/#enable-quic을 입력합니다

• 2단계: Experimental QUIC protocol을 Disabled로 설정합니다

• 3단계: 다시 시작을 클릭하여 Chrome을 재시작합니다

오류가 사라지면 QUIC/HTTP/3 충돌이 원인이었습니다. QUIC를 비활성화된 상태로 유지해도 됩니다 — 페이지는 표준 HTTPS(TCP를 통한 HTTP/2)로 로드되며 눈에 보이는 차이는 없습니다.

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

오래된 브라우저와 운영 체제는 최신 웹사이트가 요구하는 TLS 버전이나 cipher suite를 지원하지 않을 수 있습니다. 레거시 시스템에서 흔한 원인입니다.

Chrome은 chrome://settings/help에서, Edge는 edge://settings/help에서 업데이트할 수 있습니다. 운영 체제의 경우 최소 Windows 10, macOS 10.15 또는 최신 Linux 배포판을 사용하고 있는지 확인하세요. Windows XP와 Windows Vista는 기본적으로 TLS 1.2를 지원하지 않으며 거의 모든 최신 웹사이트에서 이 오류가 발생합니다.

해결법 5: 백신 프로그램의 HTTPS 스캔 비활성화

HTTPS 트래픽을 검사하는 백신 프로그램(Avast, Kaspersky, Bitdefender, ESET, Norton)은 중간자 프록시로 작동합니다 — TLS 핸드셰이크를 가로채고 자체 인증서를 브라우저에 제시합니다. 백신이 원래 서버와 동일한 cipher를 지원하지 않을 때 cipher 불일치가 발생할 수 있습니다.

백신 프로그램에서 HTTPS 스캔, SSL 스캔, 웹 보호, 또는 암호화된 연결 스캔이라는 설정을 찾아 일시적으로 비활성화하세요. 오류가 해결되면 해당 기능을 완전히 비활성화하는 대신 영향을 받는 도메인을 백신 프로그램의 예외 목록에 추가하세요.

해결법 6: 시크릿 모드 / 개인 정보 보호 모드 사용

시크릿 모드는 캐시 데이터, 쿠키, 확장 프로그램이 없는 깨끗한 브라우저 상태를 사용합니다. 시크릿 모드에서는 웹사이트가 로드되지만 일반 모드에서는 안 되면 브라우저 확장 프로그램, 캐시 데이터 또는 손상된 프로필이 오류의 원인입니다.

Ctrl+Shift+N(Chrome/Edge) 또는 Ctrl+Shift+P(Firefox)로 시크릿 모드를 엽니다. 사이트가 작동하면 일반 모드로 돌아가서 캐시를 삭제(해결법 2)하거나 확장 프로그램을 하나씩 비활성화하여 원인을 찾으세요.

해결법 7: VPN 또는 프록시 비활성화

VPN과 HTTP 프록시는 브라우저와 웹 서버 사이에 위치합니다. 일부 VPN은 SSL 검사를 수행하거나 제한된 cipher 지원을 가진 서버를 통해 연결을 라우팅합니다. 기업 프록시는 종종 cipher 불일치를 유발할 수 있는 SSL 인터셉션을 사용합니다.

일시적으로 VPN 연결을 끊고 웹사이트를 직접 로드해 보세요. VPN 없이 작동하면 다른 VPN 서버 위치로 전환하거나 VPN 제공업체에 TLS 호환성에 대해 문의하세요.

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

사용자들이 웹사이트에서 이 오류를 보고하면 서버의 SSL/TLS 구성에 문제가 있는 것입니다. 아래의 해결 방법은 인증서 문제부터 프로토콜 및 cipher 설정에 이르기까지 근본 원인을 다룹니다.

해결법 1: SSL 인증서 확인

먼저 SSL 인증서가 유효하고 만료되지 않았으며 올바른 도메인을 포함하는지 확인합니다. DNS Robot의 SSL Checker를 사용하여 인증서 상태, 만료일, 발급자, 체인 완전성을 즉시 검사할 수 있습니다.

이 오류를 일으키는 일반적인 인증서 문제:

• 만료된 인증서 — Let's Encrypt 인증서는 90일마다 만료됩니다. 자동 갱신이 실패하면 인증서가 조용히 만료되어 브라우저가 연결을 거부합니다.

• 잘못된 도메인 — 인증서가 example.com을 포함하지만 사이트는 www.example.com 또는 하위 도메인에서 제공됩니다. 인증서는 정확한 도메인과 일치하거나 와일드카드(*.example.com)를 포함해야 합니다.

• SHA-1 인증서 — 모든 주요 브라우저가 2017년에 SHA-1 인증서를 거부했습니다. 인증서가 여전히 SHA-1을 사용하고 있다면 SHA-256으로 재발급하세요.

• 자체 서명 인증서 — 개발 환경에서만 신뢰할 수 있습니다. 프로덕션 사이트에는 인정된 인증 기관의 인증서가 필요합니다.

# Check certificate details from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer -fingerprint -sha256

# Check which TLS versions the server supports
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

# Renew Let's Encrypt certificate
sudo certbot renew --force-renewal

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

모든 최신 브라우저는 최소 TLS 1.2를 요구합니다. 서버가 TLS 1.0 또는 1.1만 제공하면 브라우저에 ERR_SSL_VERSION_OR_CIPHER_MISMATCH가 표시됩니다. TLS 1.2와 TLS 1.3을 모두 활성화하고 이전 버전은 모두 비활성화하세요.

# Nginx — in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder on

# After changing, restart your web server:
sudo systemctl restart nginx    # or apache2

업데이트 후 DNS Robot의 SSL Checker 또는 Qualys SSL Labs로 TLS 1.2와 1.3만 활성화되어 있는지 확인하세요.

해결법 3: Cipher Suite 업데이트

TLS 1.2가 활성화되어 있더라도 더 이상 사용되지 않는 cipher suite를 사용하면 동일한 오류가 발생합니다. 브라우저는 RC4(2016년 이후), 3DES, 수출 등급 cipher, NULL cipher를 차단합니다. 서버는 AES-GCM 또는 ChaCha20-Poly1305와 같은 최신 AEAD cipher를 제공해야 합니다.

# Nginx — modern cipher configuration
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;  # Let client choose (TLS 1.3 best practice)

# Apache — modern cipher configuration
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

해결법 4: 완전한 인증서 체인 설치

불완전한 인증서 체인 — 서버가 자체 인증서만 보내고 중간 인증서를 보내지 않는 경우 — 은 일부 브라우저와 기기에서 ERR_SSL_VERSION_OR_CIPHER_MISMATCH를 발생시킬 수 있습니다. 서버는 리프 인증서에서 중간 CA까지의 전체 체인을 전송해야 합니다.

Let's Encrypt의 경우 항상 fullchain.pem(cert.pem이 아님)을 사용하세요. 다른 CA의 경우 CA 문서에서 중간 인증서를 다운로드하여 인증서와 연결하세요.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

# Verify chain is complete
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "(depth|verify|Certificate chain)"

해결법 5: 인증서 이름 불일치 수정

SSL 인증서가 접속하는 정확한 도메인이나 하위 도메인을 포함하지 않으면 TLS 핸드셰이크가 cipher 불일치 오류로 실패할 수 있습니다. 이 문제가 흔히 발생하는 경우:

• www vs non-www — 인증서가 example.com을 포함하지만 www.example.com은 포함하지 않습니다. 해결 방법: 두 도메인 모두를 포함하는 인증서를 사용하거나 와일드카드 인증서(*.example.com)를 발급받으세요.

• 하위 도메인 미포함 — 인증서가 example.com을 포함하지만 사용자가 app.example.com을 방문합니다. 와일드카드 인증서는 1단계 하위 도메인만 적용되며 staging.app.example.com과 같은 다중 수준 하위 도메인은 포함하지 않습니다.

• 완전히 다른 도메인 — 서버가 다른 도메인의 인증서를 제시합니다(공유 호스팅이나 잘못 구성된 가상 호스트에서 흔히 발생).

DNS Robot의 SSL Checker를 사용하여 인증서가 어떤 도메인을 포함하는지 확인하세요 — 인증서가 적용되는 모든 도메인과 하위 도메인을 보여주는 Subject Alternative Names(SANs) 목록을 표시합니다.

해결법 6: Cloudflare 관련 수정

사이트가 Cloudflare를 사용하고 방문자에게 ERR_SSL_VERSION_OR_CIPHER_MISMATCH가 표시되면 일반적으로 Cloudflare의 SSL 프록시 구성 방식에 문제가 있습니다.

• 인증서가 아직 활성화되지 않음 — Cloudflare의 Universal SSL은 도메인 추가 후 15분에서 24시간이 걸려 활성화됩니다. Cloudflare Dashboard → SSL/TLS → Edge Certificates에서 인증서 상태를 확인하세요. "Active"로 표시되어야 합니다.

• DNS 레코드가 DNS-only로 설정됨 — DNS 레코드가 Proxied(주황색 구름)로 설정되어야 Cloudflare가 SSL 인증서를 제공합니다. DNS-only(회색 구름)로 설정되면 Cloudflare는 연결을 프록시하지 않으며 원본 서버의 인증서가 대신 사용됩니다.

• 다중 수준 하위 도메인 — Cloudflare의 Universal 인증서는 example.com과 *.example.com(1단계)만 포함합니다. sub.sub.example.com의 경우 Advanced Certificate, Total TLS 또는 사용자 지정 인증서가 필요합니다.

• SSL/TLS 모드 불일치 — Cloudflare Dashboard → SSL/TLS에서 원본에 유효한 인증서가 있으면 암호화 모드를 Full (Strict)로, Cloudflare Origin Certificate를 사용하면 Full로 설정하세요.

해결법 7: CDN SSL 구성 확인

사이트가 CDN(CloudFront, Fastly, Akamai 또는 리버스 프록시)을 사용하면 CDN이 방문자와의 TLS 연결을 종료합니다. CDN 수준의 SSL 잘못된 구성은 원본 서버의 SSL이 완벽하더라도 이 오류를 발생시킵니다.

• CDN 인증서 만료 또는 누락 — CDN에 도메인에 대한 유효한 SSL 인증서가 있는지 확인하세요. AWS CloudFront에서는 ACM 인증서를 의미합니다. 다른 CDN에서는 사용자 지정 인증서가 업로드되어 활성 상태인지 확인하세요.

• CDN TLS 버전이 너무 오래됨 — 일부 CDN 구성은 기본적으로 TLS 1.0을 허용합니다. CDN의 최소 TLS 버전을 1.2로 업데이트하세요.

• SNI 미지원 — CDN이 하나의 IP에서 여러 도메인을 제공하는 경우 각 도메인에 올바른 인증서를 제시하기 위해 Server Name Indication(SNI)을 지원해야 합니다.

SSL 구성을 테스트하는 방법

변경을 완료한 후 SSL 설정이 올바른지 확인하세요. 다음 도구들은 방문자보다 먼저 문제를 발견하는 데 도움이 됩니다.

• [DNS Robot SSL Checker](/ssl-checker) — 인증서 상태, 만료일, 체인 완전성, 발급자를 빠르게 확인합니다. 결과가 몇 초 안에 나옵니다.

• Qualys SSL Labs — TLS 버전, cipher suite, 프로토콜 지원, 알려진 취약점을 심층 검사합니다. 문자 등급을 부여합니다(A 또는 A+를 목표로 하세요).

• OpenSSL CLI — openssl s_client -connect domain.com:443 명령으로 명령줄에서 테스트하여 원시 핸드셰이크, 인증서 체인, 협상된 cipher를 확인할 수 있습니다.

• Chrome DevTools — DevTools(F12)를 열고 → 보안 탭에서 → 현재 연결의 TLS 버전, cipher suite, 인증서 세부 정보를 확인할 수 있습니다.

# Quick OpenSSL check — shows protocol, cipher, and certificate
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "(Protocol|Cipher|subject|issuer|Not After)"

# Test specific TLS version support
openssl s_client -connect yourdomain.com:443 -tls1_2 2>/dev/null | head -5  # Test TLS 1.2
openssl s_client -connect yourdomain.com:443 -tls1_3 2>/dev/null | head -5  # Test TLS 1.3

관련 SSL/TLS 오류

Chrome에는 여러 SSL 관련 오류 코드가 있습니다. 각 코드는 TLS 실패의 서로 다른 단계를 나타냅니다.

이러한 SSL 오류가 발생하면 먼저 DNS Robot의 SSL Checker로 인증서를 확인하세요. 인증서 상태, 체인, 만료일, 지원되는 프로토콜을 한 번의 검사로 확인할 수 있습니다. ERR_SSL_PROTOCOL_ERROR 및 연결이 비공개가 아닙니다 가이드도 참조하세요.