문제

크롬이 ERR_SSL_OBSOLETE_VERSION을 띄우고 HTTPS 페이지가 안 열립니다 — 콘텐츠도 없고, “그래도 진행” 옵션도 없습니다. 인증서 경고가 아닙니다. 인증서 검사가 문제될 틈도 없이 프로토콜 버전 단계에서 연결이 실패한 것입니다.

이 오류의 뜻은 하나입니다: 브라우저가 도달한 TLS 엔드포인트가 TLS 1.0 또는 TLS 1.1만 제공하는데, 브라우저는 더 이상 그 언어를 못 합니다. RFC 8996이 2021년 3월 둘 다 공식 지원 중단했고, 브라우저가 먼저 움직였습니다 — 크롬과 엣지는 84 버전에서, 파이어폭스는 78에서, 사파리는 14에서, 모두 2020년에 제거했습니다. 그 뒤로 TLS 1.0/1.1밖에 협상 못 하는 서버는, 현대 브라우저 눈에는 더 이상 존재하지 않는 언어를 말하는 셈입니다.

증상

  • 크롬/엣지: ERR_SSL_OBSOLETE_VERSION, 우회 없는 전체 오류 페이지.
  • 파이어폭스: 지원되지 않거나 구형인 프로토콜을 언급하는 “보안 연결 실패” 페이지.
  • 핸드셰이크 중에 연결이 죽음 — “연결이 비공개로 설정되어 있지 않습니다” 인증서 단계에 닿기도 전에.
  • 옛 기기나 옛 버전에 고정된 사내 브라우저는 같은 사이트를 여전히 열 수 있음 — 이게 바로 클라이언트가 아니라 서버가 옛 TLS에 묶여 있다는 신호.

구형 엔드포인트가 실제로 어디 있나

사람들이 건너뛰는 부분이고, “TLS 1.2를 켰는데도 실패한다”가 생기는 이유입니다. 브라우저는 그 사이트의 TLS를 종료하는 쪽과 대화하는데, 그게 당신이 고쳤다고 생각한 장비가 아닐 때가 있습니다.

  1. 오리진 앞의 CDN·로드밸런서. Cloudflare, Fastly, AWS/GCP 로드밸런서, nginx 리버스 프록시가 TLS를 종료한다면, 브라우저가 보는 프로토콜은 그 계층의 설정이지 오리진의 것이 아닙니다. 오리진의 최소 TLS 버전을 올려도 방문자 경험은 그대로입니다. 인터넷을 실제로 마주하는 엣지에서 고치세요.
  2. 오리진 웹서버 자체. 프록시가 없을 때는, 당신의 Apache/nginx/IIS 설정이 오래된 ssl_protocols 줄을 서빙하는 것입니다.
  3. 어플라이언스나 관리 패널. NAS·프린터·공유기·옛 방화벽·관리 콘솔은 펌웨어 출시일에 멈춘 TLS 스택을 싣고 다니는 경우가 많습니다. 이것들은 ERR_SSL_OBSOLETE_VERSION을 끊임없이 던지고, 진짜 해결은 펌웨어 업데이트(또는 앞에 현대적 리버스 프록시를 두는 것)뿐입니다.

해결: 옛것을 되살리지 말고 현대 TLS를 더하라

목표는 TLS 1.2와 1.3을 제공하고 1.0/1.1 제공을 멈추는 것입니다 — 중요도 순서대로. 1.2/1.3을 켜는 것이 오류를 없애고, 옛것을 끄는 것은 보안 정리입니다.

  • nginx — server 또는 http 블록에: 
    ssl_protocols TLSv1.2 TLSv1.3;
  • Apache (mod_ssl): 
    SSLProtocol -all +TLSv1.2 +TLSv1.3
  • IIS / Windows Server. 현재 지원되는 Windows Server 버전에서는 TLS 1.2가 기본 켜져 있고, 흔한 문제는 옛 빌드이거나 TLS 1.0/1.1이 켜진 채 남은 것입니다. 이건 SCHANNEL 레지스트리(HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols)에서 토글하는데, 이 키들을 손으로 편집하는 건 실수가 잦아 대부분의 관리자는 레지스트리 경로를 직접 치는 대신 검증된 보조 도구를 씁니다. TLS 1.2(와 OS가 지원하면 1.3)를 켜고, 1.0과 1.1을 끄세요.
  • CDN / 매니지드 TLS. 대시보드에서 “Minimum TLS Version” 설정을 찾아 1.2로 두세요. 공개 웹에서 가장 자주 필요한 해결인데, 브라우저가 실제로 닿는 게 엣지이기 때문입니다.

무엇을 바꾸든, 서비스를 재시작하고 새 호스트명으로 테스트하세요 — TLS 결과는 캐시되므로 낡은 확인은 한동안 옛 프로토콜을 보여줄 수 있습니다.

솔깃한 지름길 하나: 관리자가 옛 TLS를 용인하도록 한때 설정할 수 있던 엔터프라이즈 브라우저 정책(SSLVersionMin)이 있고, 일부 스택은 TLS 1.0을 강제로 다시 켜게 해줍니다. 하지 마세요. RFC 8996은 이유가 있어 이 프로토콜들을 지원 중단했고, 다시 켜는 것은 시끄럽지만 정직한 오류를 조용한 다운그레이드 위험으로 바꾸는 것입니다 — 그러면서 최신 클라이언트는 어차피 당신을 계속 거부합니다.

DechoNet으로 진단하기

  • SSL 확인은 전 세계가 실제로 닿는 엔드포인트가 어떤 TLS 버전을 제공하는지 정확히 보여줍니다 — 1.2/1.3이 있는지, 당신이 고친 계층이 방문자가 닿는 계층인지 확인할 수 있습니다.
  • HTTP 확인은 리다이렉트를 따라 최종 HTTPS 엔드포인트까지 가므로, 오리진이 아니라 CDN·로드밸런서가 옛 TLS에 묶였을 때 도움이 됩니다.
  • 포트 확인은 443이 애초에 도달 가능한지 확인해, “틀린 TLS 버전”과 “아무것도 듣고 있지 않음”을 분리합니다.

해결 체크리스트

  • 그 호스트명의 TLS를 종료하는 게 무엇인지 식별 — 오리진, CDN, 로드밸런서 — 하고 거기서 설정을 바꾼다.
  • TLS 1.2와 TLS 1.3을 켠다; 이게 ERR_SSL_OBSOLETE_VERSION을 없앤다.
  • TLS 1.0과 1.1을 끈다(설정을 보는 김에 RC4/3DES 같은 약한 cipher도 제거).
  • CDN이 앞단이면, 그 Minimum TLS Version을 1.2로 — 오리진만 바꿔선 안 됨.
  • 옛 TLS에 묶인 어플라이언스·관리 패널은 펌웨어를 올리거나 앞에 현대적 리버스 프록시를 둔다.
  • 새 호스트명으로 SSL 확인을 다시 돌려 1.2/1.3이 실제로 협상되는지 확인한다.

이럴 땐 에스컬레이션

  • CDN이나 매니지드 플랫폼이 TLS를 종료하는데 최소 버전 설정을 못 찾겠으면, 그 제공자에 에스컬레이션하세요 — 오리진에서 당신이 할 수 있는 수정이 아닙니다.
  • 임베디드 기기가 정말 TLS 1.2를 못 하고 업데이트도 안 되면, TLS 1.0 유지를 소유자의 보안 결정으로 다루고, 공개 엔드포인트를 다시 약화시키는 대신 기기를 현대적 프록시 뒤로 격리하세요.
  • 당신이 볼 수 있는 곳 전부에 TLS 1.2/1.3이 있는데 일부 사용자에게만 오류가 계속되면, 그들의 네트워크에 있는 미들박스(백신 TLS 검사, 사내 프록시)가 옛 프로토콜로 종료하고 있을 수 있습니다 — 형제 사례 ERR_SSL_VERSION_OR_CIPHER_MISMATCH를 보세요.

내 도메인에서 바로 확인

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