조회수: 106
NET::ERR_CERT_REVOKED: 폐기된 인증서 해결
NET::ERR_CERT_REVOKED는 CA가 인증서를 폐기했다는 뜻입니다. 폐기 여부와 서버가 내보내는 인증서를 확인해 재발급합니다. 무료 SSL 진단으로 바로 확인.
내 도메인에 이 문제가 있는지 지금 확인
무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.
문제
Chrome이 연결이 비공개로 설정되어 있지 않습니다와 함께 NET::ERR_CERT_REVOKED 코드를 보여줍니다. 만료나 이름 불일치 오류와 달리 이건 날짜나 오타 문제가 아닙니다. 이 인증서를 발급한 인증기관(CA)이 신뢰를 능동적으로 철회한 것입니다 — “이제 이것을 믿지 마라”라고 세상에 알렸고, 방문자의 브라우저가 그 사실을 알아챈 것이죠. 폐기에는 이유가 있습니다: 개인키 유출, 잘못된 발급, 또는 옛 인증서를 은퇴시킨 교체 발급. 브라우저는 해야 할 일을 정확히 하고 있습니다. 문제는 그 폐기가 이 인증서에 대해 진짜인지, 아니면 이미 교체한 인증서를 아직도 내보내고 있는지입니다.
증상
- 전체 화면 경고가
NET::ERR_CERT_REVOKED(Chrome/Edge)를 표시합니다. Firefox는 같은 상태를SEC_ERROR_REVOKED_CERTIFICATE로 표현합니다. - 인증서의 유효 기간은 아직 남아 있습니다 — 만료 오류가 아닙니다.
- 폐기 확인이 브라우저마다 제각각이라, 한 브라우저에서만 뜨고 다른 브라우저에서는 안 뜰 수 있습니다(FAQ 참조).
- 페이지가 아니라 인증서의 속성이라, 새로고침이나 캐시 삭제로도 사라지지 않습니다.
주요 원인 3가지
- 인증서가 실제로 폐기됐고, 아직도 그걸 내보내고 있다 - 가장 흔한 운영상 원인입니다. 재발급(rekey/reissue)을 했고 그 과정에서 옛 인증서가 폐기됐지만, 서버·로드밸런서·CDN 엣지가 여전히 은퇴한 인증서를 내밀고 있습니다. 해결책은 새 인증서 발급이 아니라, 새 인증서가 모든 곳의 회선에서 나오게 만드는 것입니다.
- 긴급 폐기 또는 CA 측 폐기 - 키 유출 신고, 잘못된 발급, 또는 대량 폐기 사건 때문에 CA가 인증서를 폐기했습니다(실제로 일어납니다 — CA가 한 배치의 검증 결함을 발견해 CA/Browser Forum 규칙에 따라 수천 장을 한꺼번에, 흔히 24시간·5일 시한으로 폐기합니다). 여기 휘말렸다면 CA에서 폐기 통지를 받았을 것이고 신속히 재발급해야 합니다.
- 오리진이 아니라 중간장비 또는 OS 저장소 - 사내 TLS 검사(inspection) 프록시는 자체 CA로 트래픽을 재서명하며 폐기된 중간 인증서를 내보낼 수 있습니다. Windows에서는 Chrome의 CRLSet이 잠잠해도 Chrome이 시스템 인증서 저장소 자체의 OCSP/CRL 검사에서 “폐기” 판정을 물려받기도 합니다. 특정 네트워크나 특정 기기에서만 오류가 보인다면, 인증서가 아니라 경로를 의심하세요.
DechoNet으로 진단
- SSL 진단은 실제로 서빙되는 인증서 — 발급자, 시리얼, 유효 기간, 체인 — 을 읽습니다. 시리얼과 지문을 설치했다고 생각하는 인증서와 대조하세요. 불일치하면 옛 인증서가 어딘가에서 아직 살아 있는 것입니다.
- HTTP 진단은 TLS를 우회했을 때 엔드포인트가 응답하는지 확인해, 여러 엣지에 걸쳐 수정했을 때 어느 쪽이 낡았는지 가려낼 때 유용합니다.
해결 체크리스트
- 회선에서 나오는 인증서를 확인:
echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -serial -fingerprint -dates. 시리얼을 기록하세요 — 폐기된 것은 파일명이 아니라 그 시리얼입니다. - CA를 상대로 폐기 상태를 직접 조회. leaf에 OCSP URL이 있으면:
openssl ocsp -issuer chain.pem -cert cert.pem -url $(openssl x509 -in cert.pem -noout -ocsp_uri) -no_nonce. 여기서revoked판정이 나오면 그것이 결정적입니다 — 브라우저가 옳습니다. - 폐기가 맞다면 CA에서 재발급하고(새 키와 CSR을 생성 — 폐기 사유였을 수 있는 키를 재사용하지 마세요), 새 인증서와 전체 체인을 설치한 뒤 종료 지점을 모두 재적용하세요: 오리진, 리버스 프록시, 로드밸런서, CDN.
- SSL 진단을 다시 돌려 새 시리얼이 서빙되는지 확인 — 애니캐스트/CDN을 쓴다면 여러 지점에서 확인하세요. 낡은 엣지 하나가 일부 사용자에게 계속 실패를 냅니다.
- 폐기가 착오라고 확신한다면(요청한 적 없고 키가 노출된 적도 없다면) 발급 CA에 티켓을 여세요. 폐기 취소는 CA만 할 수 있고 대부분 해주지 않습니다 — 어차피 재발급을 각오하세요.
- 사내 네트워크 뒤에서만 오류가 뜬다면 거기서 체인을 살펴보세요: 오리진이 아니라 검사 프록시가 폐기된 중간 인증서를 내밀고 있을 가능성이 큽니다. 그건 여러분이 아니라 네트워크 운영자가 고칠 몫입니다.
에스컬레이션 시점
- 서빙되는 시리얼이 현재 인증서와 일치하는데도 CA의 OCSP 응답기가 여전히
revoked라고 한다면 즉시 CA에 연락하세요 — 이해해야 할 실제 유출이거나, CA만 바로잡을 수 있는 CA 오류입니다. - CA 대량 폐기 사건에 휘말렸다면 CA 상태 페이지와 Bugzilla/CA 인시던트 스레드에서 시한을 확인하세요. 흔히 24시간·5일 같은 하드 컷오프가 있어, 놓치면 재발급 여부와 무관하게 폐기가 적용됩니다.
- 폐기 확인 동작 자체가 수수께끼라면 — 인증서는 유효한데 한 플랫폼만 표시한다면 — CRLSet은 의도적으로 불완전하다는 점을 기억하세요. 그건 브라우저 커버리지 특성이지 인증서 결함이 아니며, 서버에서 고칠 것이 없습니다.
관련 도구
관련 가이드
가이드 공유
[Ad] Guide Detail Inline