SSL_ERROR_RX_RECORD_TOO_LONG는 인증서 문제인가요?

거의 아닙니다. 인증서를 검사할 기회조차 없습니다. 이 오류는 TLS 핸드셰이크의 맨 첫 바이트에서 발생합니다. Firefox가 TLS 레코드일 거라 기대하고 읽었는데, 길이 필드가 말이 안 되는 값이라 인증서를 주고받기도 전에 포기하는 겁니다. 대개 원인은 443 포트의 서버가 TLS가 아니라 평문 HTTP를 말하고 있다는 것 — 즉 핸드셰이크 자체가 없고 검사할 인증서도 없습니다.

같은 사이트인데 Chrome은 왜 다른 오류를 보여주나요?

모든 브라우저가 같은 근본 결함(HTTPS 포트에서 TLS가 아닌 응답)을 감지하지만 이름만 다르게 붙입니다. Firefox는 NSS 라이브러리의 SSL_ERROR_RX_RECORD_TOO_LONG을, Chrome은 보통 ERR_SSL_PROTOCOL_ERROR을 씁니다. 서버 쪽 원인은 동일하며, 아래 체크리스트가 둘 다 고칩니다.

80 포트는 되는데 443만 안 됩니다. 뭘 뜻하나요?

애플리케이션 자체는 멀쩡하고 문제는 순전히 TLS 리스너에 있다는 뜻입니다. 80 포트는 평문 HTTP를 제대로 응답하는데, 443에서 TLS를 종단하는 게 아무것도 없는 겁니다 — HTTPS 리스너가 없거나, 리스너가 평문 HTTP를 내보내도록 잘못 설정됐거나. 고칠 곳은 앱이 아니라 웹 서버의 SSL 설정입니다.

조회수: 111

SSL_ERROR_RX_RECORD_TOO_LONG 해결

SSL_ERROR_RX_RECORD_TOO_LONG는 대개 443 포트에서 평문 HTTP가 나오는 경우입니다. ssl 지시어·포트·프록시 3단계로 진단. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

Firefox가 SSL_ERROR_RX_RECORD_TOO_LONG 오류로 페이지 로드를 거부합니다. 전체 메시지는 보통 “보안 연결 실패… 연결하는 동안 오류가 발생했습니다… SSL이 허용된 최대 길이를 초과하는 레코드를 받았습니다.” 입니다.

Symptoms

Firefox가 SSL_ERROR_RX_RECORD_TOO_LONG을 표시하고 페이지가 끝내 안 뜹니다.
http:// 버전은 잘 되고 https://만 실패합니다.
같은 URL에 Chrome은 ERR_SSL_PROTOCOL_ERROR, Safari는 “보안 연결을 설정할 수 없습니다”를 보여줍니다.
어떤 네트워크에서는 HTTPS가 잘 되고 다른 데선 안 됩니다(프록시 개입).

What This Error Actually Means

오류를 문자 그대로 읽으세요. SSL이 너무 긴 레코드를 받았다. TLS 레코드는 콘텐츠 타입 1바이트와 길이 2바이트로 시작하는 헤더를 가집니다. Firefox는 연결을 열고 서버의 첫 바이트가 ServerHello TLS 레코드일 거라 기대하는데, 대신 읽은 바이트를 TLS 레코드 길이로 해석하니 터무니없이 큰 값이 나옵니다. 그래서 레코드가 손상됐거나 너무 크다고 판단하고 중단합니다.

그 바이트가 쓰레기처럼 보이는 이유는 대개 단순합니다. 애초에 TLS가 아니기 때문입니다. 443 포트의 서버가 평문 비암호화 HTTP로 응답한 겁니다. HTTP 응답의 첫 바이트는 HTTP/1.1 200 OK... 입니다. Firefox는 ASCII H, T, T, P를 TLS 레코드 헤더와 길이 필드로 파싱하려 하고, 계산된 “길이”는 거대한 값이 됩니다. 그래서 record too long.

따라서 이건 인증서 오류도, cipher 협상 오류도, 프로토콜 버전 불일치도 아닙니다. 핸드셰이크가 시작조차 안 됐으니 인증서에 대해 평가된 게 아무것도 없습니다. Chrome보다 Firefox가 이걸 더 잘 드러내는 건 NSS가 처음 읽는 레코드에 대해 엄격하기 때문입니다.

Top 3 Causes

443 포트에서 평문 HTTP를 서빙 - 가장 흔한 원인. nginx에서 ssl 키워드 없는 listen 443;은 서버가 443을 비암호화 HTTP로 응답하게 만듭니다. 올바른 지시어는 listen 443 ssl; 입니다. Apache에서는 SSLEngine on 없는 <VirtualHost *:443>가 똑같은 문제를 냅니다.
443에 TLS 리스너가 아예 없음 - HTTPS 리스너를 설정한 적이 없거나, 방화벽/포트포워딩이 443 트래픽을 HTTP만 말하는 백엔드로 보냅니다. 앱은 응답하지만 평문으로.
중간 장비가 TLS를 벗기거나 깨뜨림 - 회사 프록시, 잘못 설정된 로드밸런서, TLS를 잘못 종단하고 평문 HTTP를 전달하는 포트포워딩 규칙. 특정 네트워크에서만 오류가 나는 이유입니다.

Diagnose with DechoNet

SSL Check로 서버가 443에서 유효한 인증서를 제시하는지부터 확인하세요. TLS가 실제로 설정돼 있으면 인증서 정보가 나오고, 평문 HTTP가 서빙되면 TLS 프로브가 핸드셰이크에서 실패합니다 — 이 진단을 확정해 줍니다.
Port Check로 443이 열려 있고 도달 가능한지 확인해 “리스너 없음”과 “잘못된 리스너”를 분리합니다.
HTTP Check로 애플리케이션 자체가 80/443에서 응답하는지 확인해, 앱은 정상이고 결함이 TLS 계층에만 있음을 압니다.

Resolution Checklist

패턴 확인: http://는 되고 https://는 실패하나요? 그렇다면 앱은 정상이고 TLS 종단이 문제입니다.
nginx에서 모든 listen 443 줄에 ssl 키워드가 있는지: listen 443 ssl; (IPv6는 listen [::]:443 ssl;). 맨 listen 443;이 전형적 원인입니다.
Apache에서 :443 가상 호스트에 SSLEngine on과 유효한 SSLCertificateFile / SSLCertificateKeyFile이 있는지 확인합니다.
해당 호스트에 SSL Check를 실행합니다. 핸드셰이크를 못 하는데 Port Check는 443이 열려 있다고 나오면, 리스너가 비 TLS 트래픽을 서빙하는 겁니다.
앞단에 로드밸런서/프록시가 있으면 443에서 TLS를 종단하고 평문 HTTP를 클라이언트로 전달하지 않는지 확인합니다.
웹 서버를 리로드하고 SSL Check를 재실행해 이제 진짜 인증서가 제시되는지 확인합니다.

When to Escalate

오리진에서는 SSL Check가 정상 인증서를 보여주는데 엣지를 거치면 오류가 계속되면, 로드밸런서/CDN 담당자에게 에스컬레이션하세요 — 평문 HTTP 응답이 엣지와 브라우저 사이에서 생성되고 있습니다.
최근 사이트를 이전했거나 인증서를 막 설치했다면 설정이 절반만 적용된 경우를 의심하세요: 인증서는 디스크에 있지만 443 리스너에 ssl 지시어나 SSLEngine이 끝내 켜지지 않은 것입니다.