조회수: 12

NET::ERR_CERT_DATE_INVALID 해결

NET::ERR_CERT_DATE_INVALID는 인증서 만료, 미발효, 또는 기기 시계 오류 때문입니다. 세 경우를 3단계로 구분합니다. 무료 SSL 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

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

Problem

Chrome이 NET::ERR_CERT_DATE_INVALID를 표시하며 “연결이 비공개로 설정되어 있지 않습니다”로 페이지를 차단합니다. 인증서는 제시되지만, 유효 기간을 벗어났거나 — 기기가 그렇다고 판단합니다.

Symptoms

  • Chrome은 NET::ERR_CERT_DATE_INVALID, Firefox는 SEC_ERROR_EXPIRED_CERTIFICATE(만료) 또는 MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE(미발효)를 표시합니다.
  • 배포한 적 없는데 특정 시점, 흔히 밤사이에 오류가 시작됐습니다.
  • 일부 기기는 멀쩡히 접속되는데 한 대만 거부합니다.

Top 3 Causes

  1. 인증서 만료 - notAfter 날짜가 과거인 경우. 가장 흔한 원인입니다: 자동 갱신 작업이 깨졌거나, 수동 갱신을 놓쳤거나, 갱신은 발급됐지만 서버에 배포되지 않았습니다. 모든 방문자에게 동시에 영향을 줍니다.
  2. 인증서 미발효 - notBefore 날짜가 미래인 경우. 드물지만, 갓 발급한 인증서를 너무 일찍 배포했거나 서버 시계가 실제 시각보다 앞서 있을 때 발생합니다.
  3. 클라이언트 시계 오류 - 인증서는 정상이고 기기의 날짜·시간·시간대가 틀린 경우. 시계가 미래로 틀어지면 정상 인증서가 만료된 것처럼, 과거로 틀어지면 새 인증서가 미발효처럼 보입니다. 단서: 그 한 기기에서만 실패합니다.

Diagnose with DechoNet

  • SSL Check로 인증서의 실제 notBefore·notAfter 날짜를 읽어, 정말 만료됐는지 아니면 아직 유효 범위 안인지 확인합니다.
  • HTTP Check로 갱신 인증서 배포 후 최종 HTTPS 응답을 확인합니다.

Resolution Checklist

  • 먼저 클라이언트 시계부터 배제합니다: 모든 기기에서 실패하나요, 한 대에서만 실패하나요? 한 대뿐이면 그 기기의 날짜·시간을 고치고 NTP를 켜세요 — 인증서는 정상입니다.
  • openssl s_client -connect host:443 -servername host 2>/dev/null | openssl x509 -noout -dates로 정확한 notBefore/notAfter를 읽습니다.
  • 만료됐다면 인증서를 갱신하고 새 파일을 서버에 배포합니다 — 갱신 발급과 설치는 다릅니다.
  • 미발효라면 서버 자체 시계를 확인하고 발급 날짜를 점검합니다. notBefore까지 기다리거나, 날짜가 잘못됐다면 재발급합니다.
  • 갱신 파이프라인이 다시 끊기지 않도록 고칩니다(예: certbot/ACME 타이머가 오류 없이 도는지 확인).
  • SSL Check를 다시 실행해 제공되는 인증서가 유효 기간 안에 있는지 확인합니다.

When to Escalate

  • 관리형 인증서가 만료됐는데 갱신을 직접 트리거하거나 배포할 수 없다면 호스팅·CDN 제공업체에 문의하세요.
  • 인증서는 분명 정상인데 여러 기기가 모두 오류를 보고한다면, 인증서가 아니라 네트워크 전역 시간 소스(잘못된 NTP 서버, 깨진 DHCP 옵션)를 의심하세요.

관련 도구

관련 가이드

가이드 공유

[Ad] Guide Detail Inline
← 전체 가이드 보기