SEC_ERROR_EXPIRED_CERTIFICATE 원인

Problem

Firefox가 Warning: Potential Security Risk Ahead와 함께, 에러 코드 아래에 **“The certificate expired on [날짜]“**와 SEC_ERROR_EXPIRED_CERTIFICATE를 띄우며 사이트를 막습니다. 발급자 레벨 사촌과 달리 이건 웹사이트 자신의 인증서 — leaf — 를 곧장 가리킵니다. Firefox가 체인을 따라가 이 호스트명에 대해 서버가 제시하는 인증서에 도달했고, 그 유효 구간이 닫혀 있음을 발견한 겁니다.

함정은 여기서 “만료”가 두 가지에 대한 주장이라는 점입니다: 인증서의 날짜, 그리고 당신 컴퓨터가 생각하는 오늘 날짜. Firefox는 인증서의 notAfter를 현재 시각과 비교해야만 만료 여부를 판단할 수 있고 — 현재 시각이 틀리면, 멀쩡한 인증서가 진짜 만료된 인증서와 정확히 똑같이 실패합니다. 갱신을 쫓아가기 전에, 둘 중 무엇을 보고 있는지부터 알아야 합니다.

Symptoms

• 정확한 코드는 SEC_ERROR_EXPIRED_CERTIFICATE이고, 체인 레벨의 SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE와 다릅니다.
• Firefox가 특정 날짜를 지목합니다: “The certificate expired on [날짜]”. 그 날짜가 과거로 조금 지났는지 아니면 몇 년 어긋났는지 보세요 — 터무니없이 오래된 날짜는 보통 인증서가 아니라 시계입니다.
• 서버 쪽 문제면 실패가 사이트에 한정되고, 그 인증서는 방문자 모두에게 만료입니다.
• 시계 문제면 다수 또는 모든 HTTPS 사이트가 한꺼번에 실패하고, 같은 기기의 다른 브라우저도 깨집니다.
• “아무것도 안 바꿨는데” 갑자기 뜰 수 있습니다 — 인증서가 달력상 notAfter를 넘겼거나, 기기 시계가 튀었기 때문입니다.

SEC_ERROR_EXPIRED_CERTIFICATE의 실제 의미

모든 인증서는 유효 구간을 담습니다: notBefore와 notAfter. 브라우저는 그 구간 안에서만 인증서를 신뢰합니다. Firefox는 NSS 라이브러리를 통해 매 핸드셰이크마다 두 경계를 현재 시스템 시각과 비교합니다. notAfter를 지나면 SEC_ERROR_EXPIRED_CERTIFICATE, notBefore 이전이면 ‘아직 유효하지 않음’인데 Firefox는 이것도 흔히 같은 방식으로 표출합니다. TLS의 신뢰가 시간에 묶인 건 의도입니다 — 인증서는 만료되는 선언이라, 유출되거나 교체된 키를 영원히 믿지 못하게 합니다.

이 설계엔 새겨둘 부작용이 있습니다: 브라우저의 시계가 신뢰 판단의 일부라는 것. 같은 서버의 동일한 인증서를 보는 두 컴퓨터가, 순전히 시계가 다르다는 이유로 유효성에 대해 의견이 갈릴 수 있습니다. 그래서 실제로는 멀쩡한 인증서에서 SEC_ERROR_EXPIRED_CERTIFICATE가 뜨는 가장 흔한 원인이 로컬 날짜 오류입니다 — CMOS 배터리가 죽어 옛 epoch로 리셋된 노트북, 시간대가 틀린 폰, NTP 동기 전의 갓 만든 VM. 인증서는 움직이지 않았습니다. 당신의 기준점이 움직인 겁니다.

시계가 맞다면, 에러는 말 그대로입니다: 서버가 notAfter가 지난 leaf 인증서를 제시하고 있고 아무도 갱신하지 않았다는 뜻. 자동 발급이 이걸 멸종시켰어야 했고 거의 그랬지만, 여전히 일어납니다 — 조용히 죽은 ACME 갱신 cron, 자동화가 커버하지 않는 서버의 인증서, 모두가 잊은 장비에 수동 설치된 cert. 현재 CA/Browser Forum 로드맵에서 인증서 수명이 몇 주 단위로 짧아지면서, “자동화를 안 해둠”과 “운영에서 만료됨” 사이의 창은 점점 좁아지고 있습니다.

주요 원인

1. 진짜로 만료된 leaf 인증서 - 서버 자신의 인증서가 notAfter를 지났고 아무도 갱신하지 않았습니다. 모두에게 만료입니다. 진짜 서버 쪽 케이스이고, 해결은 재발급-설치이지 클라이언트 손질이 아닙니다.

2. 틀린 시스템 시계 - 인증서는 멀쩡하고, 기기 날짜가 유효 구간 밖입니다. notAfter를 지나면 유효한 cert가 만료로, notBefore 이전이면 아직 유효하지 않음으로 보입니다. 서명은 여러 사이트가 한꺼번에, 여러 브라우저에서 실패한다는 것. 시계를 고치면 즉시 전부 풀립니다.

3. 죽은 자동화 파이프라인 - ACME나 다른 갱신 잡이 멈췄고 — 만료된 토큰, 바뀐 DNS, 자동화 범위 밖 호스트 — 스스로 갱신되던 인증서가 조용히 만료됐습니다. 아무도 안 보는 보조 도메인과 내부 서비스에서 흔합니다.

4. 오래된 예외나 캐시 상태 - 한 번 만료를 클릭으로 넘겨 Firefox가 예외를 기억하거나, 캐시된 OCSP/핸드셰이크 상태가 남았습니다. 드물지만, 다른 곳에서는 되는데 내 Firefox에서만 실패하는 사이트를 설명합니다.

DechoNet으로 진단

• SSL Check는 서버가 실제로 제시하는 인증서를 바깥에서, 당신 것이 아닌 우리 시계로, 진짜 notBefore·notAfter 날짜와 함께 읽습니다. 이 한 가지 사실이 진단을 깔끔하게 가릅니다. 점검 결과 leaf 인증서가 만료로 나오면 문제는 서버입니다 — 만료된 인증서를 모두에게 서빙 중이고 주인이 갱신해야 합니다. 점검 결과 leaf가 현재 유효한데도 당신 Firefox가 SEC_ERROR_EXPIRED_CERTIFICATE를 보이면 인증서는 멀쩡하고 원인은 로컬입니다 — 시스템 시계부터 보세요. 어느 쪽이든 추측이 끝납니다: 독립된 시계를 가진 외부 점검이 이 에러에 필요한 바로 그 중립 심판입니다.

해결 체크리스트

• Firefox가 지목한 날짜를 읽으세요. “expired on [날짜]“가 오늘과 몇 년 어긋났다면 다른 무엇보다 먼저 시스템 시계를 확인 — 그게 전형적인 시계 오류 지문입니다.
• 범위를 확인하세요. 한 사이트만 실패하면 서버 인증서를 가리키고, 여러/모든 HTTPS 사이트가 여러 브라우저에서 실패하면 시계·백신 HTTPS 검사·OS 신뢰 저장소를 가리킵니다.
• 시계가 틀렸으면 고치세요. 날짜·시간·시간대를 바르게 맞추고 네트워크 자동 시각을 켜세요. 시계가 맞는 순간 유효한 인증서는 실패를 멈춥니다.
• 외부 SSL 점검을 돌려 독립된 시계로 실제 유효 날짜를 보세요. 거기서 만료면 서버 쪽, 유효면 로컬입니다.
• 진짜 서버 쪽이면 현재 인증서를 재발급·설치한 뒤, 갱신했어야 할 자동화가 실제로 돌고 있는지 확인하세요 — 만료 cert는 대개 죽은 cron이고, 잡을 안 고친 채 손으로 갱신하면 다음 장애까지 타이머만 되감는 겁니다.
• 무시(고급 → 위험을 감수하고 계속)는 내 비운영 호스트에서만, 자격증명·결제를 다루는 사이트에서는 절대 하지 마세요.

언제 에스컬레이션할까

• 외부 SSL 점검이 leaf 만료를 확인하면 이건 서버 수정이고 오리진 주인의 몫입니다. 정확한 인증서와 만료일을 넘기세요. “이 호스트명의 leaf 인증서가 [날짜]에 만료됨, 재발급·재배포”는 정확하고 실행 가능합니다.
• 인증서가 주기적으로 계속 만료되면 인증서가 아니라 자동화를 에스컬레이션하세요. 반복 만료는 갱신 파이프라인이 깨졌거나 그 호스트를 커버하지 않는다는 뜻 — 그게 진짜 수정이고 일회성 cert 문제가 아니라 인프라 문제입니다.
• 시계는 맞아 보이는데 일부 클라이언트만 실패하면 한 단계 위를 보세요: HTTPS 검사를 하는 백신, 회사 프록시, 낡은 OS 신뢰 저장소가 인증서 날짜를 주입하거나 오판할 수 있습니다. 그건 웹사이트 변경이 아니라 엔드포인트 관리 에스컬레이션입니다.