MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE 해결

Problem

Firefox가 Warning: Potential Security Risk Ahead로 사이트를 막고, 에러 코드 아래에 **“The certificate will not be valid until [날짜]“**와 MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE를 띄웁니다. 이건 만료된 인증서의 정반대입니다. Firefox가 체인을 따라가 서버가 제시하는 인증서에 도달했는데, 그 유효 구간이 아직 열리지 않았다는 것 — 당신의 컴퓨터 기준으로 notBefore 날짜가 아직 미래라는 뜻입니다.

함정은 만료에서 사람들을 헷갈리게 하는 것과 똑같고, 방향만 뒤집힌 겁니다: ‘아직 유효하지 않음’은 두 가지에 대한 동시 주장입니다 — 인증서의 시작 날짜 그리고 컴퓨터가 생각하는 오늘 날짜. Firefox는 notBefore를 현재 시스템 시각과 비교해 인증서가 ‘이르다’고 판단하고, 그 시각이 틀리면 멀쩡한 인증서가 진짜 미래 날짜 인증서와 똑같이 실패합니다. 인증서를 쫓기 전에, 둘 중 무엇을 보고 있는지부터 알아야 합니다.

Symptoms

• 정확한 코드는 MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE이고, SEC_ERROR_EXPIRED_CERTIFICATE(notAfter 지남)·발급자 레벨의 MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE와 구분됩니다.
• Firefox가 날짜를 지목합니다: “The certificate will not be valid until [날짜].” 그 날짜가 지금 바로 앞인지, 몇 주·몇 년 앞인지 보세요 — 터무니없이 먼 미래면 인증서가 아니라 시계입니다.
• 시계 문제라면 여러·모든 HTTPS 사이트가 한꺼번에 실패하고, 같은 기기의 다른 브라우저도 깨집니다.
• 서버 문제라면 특정 사이트에만 나타나고, 인증서 교체 직후에 뜨며, 대개 한 시간 안에 저절로 풀립니다.
• “어제까지 됐던” 기기에서 갑자기 뜰 수 있습니다 — 시계가 과거로 뛰었거나 배터리가 죽어 날짜가 리셋됐기 때문입니다.

MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE가 실제로 뜻하는 것

모든 인증서는 두 경계로 유효 구간을 정의합니다: notBefore와 notAfter. 브라우저는 그 구간 안에서만 인증서를 신뢰합니다. Firefox는 NSS / mozilla::pkix 검증 경로를 통해 매 핸드셰이크마다 두 경계를 현재 시스템 시각과 비교합니다. notAfter를 지나면 SEC_ERROR_EXPIRED_CERTIFICATE, notBefore 이전이면 MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE. 같은 구간, 반대쪽 끝입니다.

Chrome은 두 끝을 ERR_CERT_DATE_INVALID 하나로 보고하고 어느 쪽인지는 당신이 알아내게 둡니다. Firefox는 나눠서, 코드 자체가 불일치의 방향을 알려줍니다. ‘아직 유효하지 않음’은 지금이 인증서가 기대하는 시점보다 이르다는 뜻 — 거의 항상 시계가 너무 과거로 맞춰졌다는 의미입니다. 미래 날짜로 발급된 인증서는 드물지만, 과거에 멈춘 시계는 흔하니까요.

내재화할 만한 부수효과는 만료와 같습니다: 브라우저의 시계가 신뢰 결정의 일부라는 것. 같은 서버의 같은 인증서를 보는 두 기기가, 순전히 시계가 다르다는 이유만으로 ‘아직 유효한지’를 놓고 의견이 갈릴 수 있습니다. 오늘 아침 발급된 인증서의 notBefore는 오늘 아침이고, 아직 작년이라 믿는 기기는 그걸 미래로 보고 연결을 거부합니다. 인증서는 움직이지 않았습니다 — 당신의 기준점이 움직인 겁니다.

주요 원인

1. 과거로 맞춰진 시스템 시계 — 압도적 1순위. 기기 날짜가 인증서 notBefore보다 뒤처져 있어 유효한 현재 인증서가 ‘이른’ 것으로 보입니다. 과거로 리셋된 죽은 CMOS 배터리, 수동으로 잘못 맞춘 폰, 틀린 시간대, NTP 동기 전의 새 VM/컨테이너. 지문은 범위입니다: 여러 사이트가 브라우저를 가로질러 동시에 실패합니다. 시계를 고치면 전부 즉시 해결됩니다.
2. 진짜로 미래 날짜인 leaf 인증서 — 정확한 시계 기준으로도 notBefore가 아직 안 온 인증서를 서버가 서빙합니다. 이게 진짜 서버측 케이스이고, 대개 작은 시계 오차입니다: 발급 즉시 배포한 인증서를 시계가 몇 분 느린 방문자가 받는 상황. 공개 CA는 바로 이 오차를 흡수하려고 notBefore를 약 한 시간 앞당기므로, 내부·사설 CA나 즉시 배포에서 더 자주 보입니다. 지문은 한 사이트가 모두에게 실패하고 한 시간 안에 자가 해결된다는 점입니다.
3. 체인 속 미래 날짜 발급자 — 이른 인증서가 leaf가 아니라 중간/루트라면 Firefox는 MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE로 보고합니다. 여기선 leaf를 갱신해도 소용없고, 고칠 대상은 서버가 보내는 체인 — 올바른 현재 유효 중간 인증서 번들을 설치하는 겁니다.

DechoNet으로 진단

• SSL 진단은 서버가 실제로 제시하는 인증서의 진짜 notBefore·notAfter를, 당신의 시계가 아니라 우리 시계로 외부에서 읽습니다. 그 한 가지 사실이 진단을 깔끔하게 가릅니다. 진단이 leaf의 notBefore가 이미 과거(인증서가 현재 유효)라고 나오는데도 당신의 Firefox가 여전히 MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE를 던지면, 인증서는 멀쩡하고 잘못은 로컬 — 시스템 시계부터 보세요. 진단 자체가 인증서를 아직 유효하지 않음으로 보고하면, 서버가 모두에게 미래 날짜 인증서를 서빙하는 것 — 문제는 당신 기기가 아니라 오리진의 발급·배포입니다.

해결 체크리스트

• Firefox가 지목한 날짜를 읽으세요. “will not be valid until [날짜]“가 오늘보다 몇 주·몇 년 앞이면, 무엇보다 시스템 시계부터 확인 — 그게 시계 오류의 지문입니다.
• 범위를 확인하세요. 여러·모든 HTTPS 사이트가 브라우저를 가로질러 실패하면 시계, 한 사이트가 모두에게 실패하면 서버 인증서입니다.
• 시계가 틀렸으면 고치세요. 날짜·시간·시간대를 올바로 맞추고 자동 네트워크 시각(NTP)을 켜세요. 시계가 맞는 순간 유효한 인증서는 실패를 멈춥니다.
• 외부 SSL 진단으로 독립된 시계 기준의 진짜 notBefore를 읽으세요. 거기서 notBefore가 과거면 로컬 문제, 미래면 서버측입니다.
• 서버측이고 간격이 한 시간 미만이면 갓 발급된 인증서에 대한 시계 오차일 가능성이 큽니다 — 기다렸다가 확인하세요. 간격이 크면 올바른 notBefore로 재발급하거나, 내부 PKI라면 발급 CA의 시계를 고치세요.
• Firefox가 발급자를 지목하면(MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE) leaf를 건드리지 말고 현재 유효 중간 번들을 설치하세요.

언제 에스컬레이션할까

• 외부 SSL 진단이 leaf의 notBefore가 미래임을 확인하면, 이건 서버측 수정이고 오리진 소유자의 몫입니다. 정확한 notBefore 날짜를 건네고 올바른 시작 날짜로 재발급하거나 배포·발급 시계를 고쳐 달라고 하세요 — “이 호스트명 인증서는 [날짜]까지 유효하지 않다”는 정확하고 실행 가능한 요청입니다.
• 인증서가 아주 작은 폭으로만 미래 날짜이고 한 시간 안에 자가 교정되면, 갓 발급된 인증서에 대한 시계 오차였던 겁니다 — 확인 외에 고칠 건 없지만, 다음엔 notBefore를 앞당기거나 배포를 늦추도록 발급 담당자에게 알리세요.
• 여러 클라이언트가 시계는 멀쩡해 보이는데 실패하면 한 단계 위를 보세요: HTTPS 검사 백신이나 회사 프록시가 자기(잘못 맞춰진) 시계로 인증서를 재서명할 수 있습니다. 그건 웹사이트 변경이 아니라 엔드포인트 관리 에스컬레이션입니다.