SEC_ERROR_REVOKED_CERTIFICATE: Firefox 해결

문제

Firefox가 페이지를 SEC_ERROR_REVOKED_CERTIFICATE — 보안 연결 실패. 인증서가 폐기되어 신뢰할 수 없습니다. — 로 막고, 눌러서 넘어갈 “위험 감수” 버튼도 없습니다. 그 사이트는 Chrome에서는 잘 열리는 경우가 많아서, 다들 엉뚱한 가설을 쫓게 됩니다: Firefox가 고장 났거나 유난스럽다는 가설이죠. 아닙니다. Firefox는 이 연결의 인증서가 폐기 목록에 올라 있다고 말하는 거고, 그 말은 진심입니다. 진짜 물어야 할 건 둘뿐입니다 — 어느 인증서인지(진짜 서버 것인지, 당신과 서버 사이에 끼워진 것인지), 그리고 왜 폐기됐는지.

증상

• Firefox가 보안 연결 실패와 함께 오류 코드: SEC_ERROR_REVOKED_CERTIFICATE, “인증서가 폐기되어 신뢰할 수 없습니다.” 를 표시.
• 우회 링크가 없음 — 만료·자체서명 인증서와 달리 예외를 추가할 수 없습니다.
• 똑같은 URL이 Chrome이나 Edge에서는 경고 없이 열려서 Firefox 전용 버그처럼 보임.
• 한 사이트에서만(딱 그 사이트) 뜨거나 모든 HTTPS 사이트에서 한꺼번에 뜸 — 두 패턴은 원인이 완전히 다릅니다.
• 모든 사이트에서 뜨는 경우, 대개 백신 HTTPS 검사나 회사 프록시 뒤에 있거나 관리되는 업무용 기기입니다.

이 오류가 실제로 뜻하는 것

폐기는 인증서가 자연 만료되기 전에 “이건 더 이상 신뢰하지 마”라고 선언하는 방식입니다 — 키 유출, 오발급, 사고 중 교체된 인증서 뒤에 옵니다. 늘 어려웠던 건 그 판정을 당신 브라우저에 빨리 전달하는 일이었습니다. 옛 답은 OCSP였습니다: 연결 시점에 CA에 “이 시리얼 아직 유효해?”를 실시간으로 묻는 거였죠. 느렸고(핸드셰이크를 막았습니다 — Mozilla에 따르면 중앙값 약 100ms), 당신의 브라우징을 CA에 흘렸으며, 응답자가 죽으면 그냥 통과시켰습니다.

Firefox는 이제 그걸 대부분 교체했습니다. Firefox 137(2025년 4월)부터 CRLite가 기본입니다 — Mozilla가 CT 로그와 모든 CA의 CRL에서 폐기를 모아 압축 필터 캐스케이드로 만들어 브라우저에 밀어넣고, Firefox는 폐기를 로컬에서 거의 완전한 목록에 대조하며 서버로 전화하지 않습니다. Firefox 142(2025년 8월)는 한 발 더 나아가 도메인 검증(DV) 인증서에 대한 실시간 OCSP를 아예 중단했습니다. 폐기된 중간 CA 인증서에는 두 번째, 더 오래된 목록이 있습니다 — Firefox 37(2015년)부터 이어온 OneCRL입니다.

그 역사가 진단의 전부입니다. SEC_ERROR_REVOKED_CERTIFICATE는 이제 당신 체인의 인증서가 Firefox가 이미 들고 있는 목록의 항목과 일치해서 뜨는 겁니다 — 불안정한 네트워크 확인이 딸꾹질해서가 아니라. 그리고 그 목록은 Chrome의 손수 추린 CRLSet보다 훨씬 완전하기 때문에, Firefox는 Chrome이 조용히 받아주는 폐기 인증서를 잡아냅니다. 오류를 보여주는 브라우저가 진실을 말하는 쪽입니다. Firefox 자신의 문구는 왜인지에 대해 악명 높게 불친절합니다 — 상태만 알려주고 문제의 인증서는 짚어주지 않죠(Bugzilla 1316342) — 그래서 할 일은 어느 인증서가 목록에 있는지 알아내는 겁니다.

주요 원인 3가지

1. 서버가 진짜로 폐기된 인증서를 아직 서빙 중. CA가 이 인증서를 폐기했지만(키 유출·오발급·사고 교체), 옛 노드나 오래된 로드밸런서, 잊힌 배포가 여전히 그걸 내주고 있습니다. Firefox의 CRLite는 그 폐기를 갖고 있어 막고, Chrome의 CRLSet은 안 담고 있어 통과시켜 — Firefox가 틀린 것처럼 보이게 만듭니다. 전형적인 단일 사이트 실패입니다. 해법은 서버측: 모든 곳에 현재 인증서를 배포하고 폐기된 걸 서빙하지 마세요.
2. 로컬 TLS 가로채기가 폐기된 중간 인증서를 끼워넣음. 백신 HTTPS 검사나 회사 프록시가 자기 CA로 사이트마다 재서명합니다. 그 중간 인증서가 OneCRL에 있으면 재서명된 모든 페이지가 SEC_ERROR_REVOKED_CERTIFICATE를 던집니다. 이 원인의 서명은 범위입니다: 한 사이트가 아니라 전부죠. 해법은 가로채는 소프트웨어나 그 관리자에게 있지, 어느 웹사이트에도 없습니다.
3. 진짜 체인의 폐기된 중간 인증서. 덜 흔하지만, CA 수준 불신이나 폐기돼 OneCRL에 들어간 중간 인증서는 그 아래 발급된 모든 리프 인증서를 무너뜨립니다 — 그래서 특정 사이트, 또는 한 발급자에서 나온 사이트 묶음이 실패하고 나머지 웹은 멀쩡합니다. 여기선 사이트 운영자가 현재의 신뢰된 중간 인증서로 재발급해야 합니다.

DechoNet으로 진단

• SSL 진단은 네트워크 외부에서 호스트로 완전한 TLS 핸드셰이크를 돌려 진짜 서버가 실제로 제시하는 인증서 — 발급자, 시리얼, 유효기간, 체인 — 을 보고합니다. 당신 Firefox가 막고 있는 것과 비교하세요. 외부 진단이 옛/교체된 인증서를 서빙한다고 나오면 서버측 폐기 인증서 문제가 확정됩니다(그리고 목록이 얇은 Chrome이 왜 통과시켰는지도 설명되죠). 외부 진단이 깨끗한 현재 인증서를 보여주는데 Firefox가 여전히 폐기라고 하면, 폐기 인증서는 당신 쪽에서 끼워진 겁니다 — 로컬 가로채기. 진짜 서버에서 오는 회선은 깨끗하니까요.
• HTTP 진단은 당신 브라우저를 완전히 벗어나 사이트를 가져옵니다. 우리 쪽에서는 정상 응답인데 당신 Firefox는 실패한다면, 그 차단이 오리진이 아니라 당신 기기에 국한됐다는 또 하나의 증거입니다.

해결 체크리스트

• 서빙되는 인증서를 먼저 읽어라. 외부 SSL 진단을 돌려 서버가 제시하는 발급자와 시리얼을 확인하세요. 뭘 바꾸기 전에, 서버측 폐기 인증서인지 로컬에 끼워진 것인지부터 가려줍니다.
• 범위를 확인하라. 한 사이트 → 서버(또는 발급 중간 인증서) 의심. 모든 HTTPS 사이트 → 로컬 TLS 가로채기(백신·프록시) 의심. 이 패턴이 당신이 가진 가장 빠른 분기입니다.
• 당신 서버라면 모든 곳에 현재 인증서를 배포하라. 폐기된 인증서를 모든 노드와 로드밸런서에서 교체하세요 — 오래된 엔드포인트 하나면 계속 Firefox를 걸리게 하기에 충분합니다. Chrome이 로드하는 걸 끝났다는 증거로 삼지 마세요. Chrome의 CRLSet은 그 폐기를 그냥 안 담고 있을 수 있습니다.
• 모든 사이트라면 로컬 가로채기를 점검하라. 백신 HTTPS/SSL 검사를 잠시 끄거나 회사 프록시에서 벗어나 재시도하세요. 오류가 사라지면, 폐기된 중간 인증서가 로컬에서 끼워지고 있던 겁니다 — 거기서 고치세요.
• 우회하려 하지 마라. 예외 버튼이 없는 건 의도된 것입니다. 폐기된 인증서는 신뢰하지 말라고 명시적으로 경고받은 인증서입니다. 우회는 폐기의 존재 이유를 통째로 무너뜨립니다.
• CRLite가 오래된 것처럼 굴 때만 시계를 의심하라. CRLite는 시간으로 버전이 매겨집니다. 시스템 시계가 크게 틀리면 드물게 폐기 상태를 혼동시킬 수 있습니다. 시계를 맞추고 Firefox가 필터를 새로고침하게 두세요.

언제 에스컬레이션

• 외부 SSL 진단이 현재의 미폐기 인증서를 보여주는데 그 한 기기의 Firefox만 여전히 사이트를 막는다면, 엔드포인트나 그 기기의 보안 소프트웨어를 관리하는 쪽에 에스컬레이션하세요 — 폐기 인증서를 끼워넣는 건 당신이 통제 못 할 수도 있는 로컬 가로채기입니다.
• 폐기된 게 당신 인증서라면 브라우저 변덕이 아니라 사고로 다루세요: CA가 왜 폐기했는지 알아내고(키 유출이나 오발급은 덮어둘 일이 아닙니다), 새 인증서를 받고, 모든 노드가 그걸 서빙하는지 확인하세요. 다른 브라우저가 여전히 옛 것을 로드하는 건 안심할 근거가 아닙니다 — Firefox가 마침 공유하지 않는, 그들의 폐기 커버리지 구멍일 뿐입니다.