NET::ERR_CERT_DATE_INVALID

NET::ERR_CERT_DATE_INVALID는 브라우저가 접속 중인 사이트의 SSL/TLS 인증서 유효기간을 신뢰하지 못해 연결을 차단하고 "연결이 비공개로 설정되어 있지 않습니다(Your connection is not private)" 경고 화면을 표시하는 상태입니다.

이 오류는 인증서 자체의 유효기간 문제뿐 아니라, 접속 기기의 날짜·시간이 어긋났을 때도 동일하게 나타납니다.

이 문서가 맞는 조건

브라우저에 NET::ERR_CERT_DATE_INVALID 또는 같은 인증서 날짜 경고가 표시되는지와 대상 URL을 먼저 기록합니다. 인증서 오류처럼 보인다는 이유만으로 인증서를 교체하거나 브라우저 경고를 우회하지 않습니다.

관찰 결과	다음 판단
브라우저에 NET::ERR_CERT_DATE_INVALID가 표시됨	이 문서에서 기기 시각과 서버 인증서 유효기간을 나눠 확인
Cloudflare 오류 화면에 Error 525: SSL handshake failed가 표시됨	Error 525: SSL handshake failed 문서를 확인
오류 화면이나 코드가 확인되지 않음	인증서 파일을 바꾸지 말고 대상 URL·시각·브라우저 경고 문구를 먼저 기록

이 문서는 브라우저가 인증서 유효기간을 신뢰하지 못한 상태를 다룹니다. 원본 서버와 Cloudflare 사이의 핸드셰이크 실패는 별도 오류로 구분합니다.

두 방향을 구분해야 하는 이유

브라우저는 인증서의 유효기간(Not Before ~ Not After)이 현재 시각을 포함하는지 검사합니다. 따라서 다음 두 경우가 같은 오류로 보일 수 있습니다.

관찰 위치	확인할 내용	대표 원인
접속 기기	시스템 날짜·시간의 정확성	기기 시계가 과거·미래로 어긋남
서버 인증서	유효기간이 현재를 포함하는지	인증서 만료 또는 갱신 누락

Google Chrome 공식 안내는 이 오류가 "컴퓨터나 모바일 기기의 날짜와 시간이 정확하지 않을 때" 발생할 수 있다고 설명하며, 먼저 기기의 시간과 날짜가 올바른지 확인하도록 안내합니다. [Observation] 이 경우 여러 사이트에서 동시에 같은 경고가 나타나는 경향이 있습니다.

인증서 만료 관점

서버 인증서에는 정해진 유효기간이 있고, 그 기간이 지나면 브라우저는 인증서를 더 이상 유효하지 않은 것으로 취급합니다. 예를 들어 Let's Encrypt의 기본 인증서는 발급 후 90일 동안만 유효하며, 만료 전 갱신이 이뤄지지 않으면 방문자에게 인증서 관련 경고가 노출될 수 있습니다.

• 만료가 원인이라면 인증서를 재발급·갱신하고 웹 서버·CDN·로드 밸런서 등 인증서를 제공하는 모든 지점에 최신 인증서가 반영됐는지 확인합니다.
• 자동 갱신을 사용하는 경우, 갱신은 되었지만 서비스에 새 인증서가 다시 로드되지 않아 옛 인증서가 계속 제공되는 상황이 실제 운영 사례에서 반복 관찰됩니다. [Observation] 디스크의 인증서 파일이 최신이어도 웹 서버 프로세스가 재로드되지 않으면 만료된 인증서가 그대로 제공되므로, 실제로 제공되는 인증서의 유효기간을 함께 확인합니다.

원인 분포

공식 안내는 원인을 "기기 시계"와 "서버 인증서 만료" 두 방향으로 설명합니다. 그러나 운영 사례를 모아 보면 "서버측"이 다시 여러 갈래로 나뉩니다. [Observation] 아래는 관측된 사례 기준의 분류이며, 실제 발생 빈도와 같다고 단정하지 않습니다.

갈래	무엇이 일어났나	대표 관찰
기기 시계 오류	클라이언트 시스템 시각이 어긋남	특정 기기에서만 재현
갱신 후 재로드 누락	인증서는 갱신됐으나 서버가 옛 인증서를 계속 제공	"갱신했는데 그대로 만료"
갱신 자동화 실패	갱신 도구가 만료 인증서를 건너뛰거나 발급에 실패	certbot이 "갱신 대상 아님"으로 스킵
체인 상위 인증서 만료	리프는 유효하나 루트·중간 인증서가 만료	리프 유효기간만 보면 정상
인증서 파일 결합 오류	체인 파일이 잘못 결합돼 서버가 인식 못함	새 인증서 적용 후에도 오류

오진 함정

공식 문서만으로는 놓치기 쉬운, 실제 사례에서 반복된 오진 정황입니다. [Observation]

• "인증서 유효기간은 정상인데 오류가 난다" → 제공되는 체인의 상위 인증서가 만료됐을 수 있습니다. 서버 리프 인증서만 확인하면 원인을 찾지 못하므로 체인 전체를 확인합니다.
• "갱신했는데 계속 만료로 표시된다" → 서버가 새 인증서를 재로드하지 않았을 수 있습니다. 디스크 파일의 날짜와 실제 제공되는 인증서의 날짜가 다른지 확인합니다.
• "갱신 도구가 성공했다는데 만료다" → 갱신 도구가 해당 인증서를 건너뛰었을 수 있습니다. 도구의 로컬 상태가 아니라 실제 만료일을 확인합니다.
• "내 컴퓨터에서만 오류가 난다" → 클라이언트 시계 문제일 수 있습니다. 다른 기기·다른 네트워크에서 재현되는지로 구분합니다.

환경 매트릭스

인증서를 제공하는 환경에 따라 지배적인 실패 양상이 다릅니다. [Observation]

환경	자주 관찰되는 실패	확인할 지점
Let's Encrypt + 자동 갱신 도구 + 웹 서버	갱신 후 서버 재로드 누락	갱신 후 서버 재로드가 자동으로 이뤄지는지
CDN·프록시(예: Cloudflare)	엣지와 원본 인증서 상태 불일치	엣지와 원본을 각각 확인
국내 서버호스팅(수동 설치)	체인 파일 결합 오류·재시작 누락	체인 파일 형식과 서버 재시작
구형 클라이언트·라이브러리	상위 인증서 만료 이후 체인 신뢰 실패	제공 체인과 신뢰 저장소 갱신 여부

진단 순서

관찰 결과에 따라 갈래를 좁힙니다.

1. 다른 기기·다른 네트워크에서 재현되지 않으면 클라이언트 시계를 확인합니다.
2. 재현되면 실제로 제공되는 인증서의 유효기간을 확인합니다(디스크 파일이 아니라 서버가 응답으로 제공하는 인증서).
3. 제공되는 리프 인증서가 만료됐다면, 디스크 파일 날짜와 비교해 갱신 자체가 안 된 것인지 재로드가 안 된 것인지 구분합니다.
4. 리프 인증서는 유효한데 오류가 나면 체인의 상위 인증서 만료와 체인 결합 오류를 확인합니다.
5. CDN·프록시를 사용하면 엣지와 원본을 각각 확인합니다.

재검사

접속 경로별로 상태를 나눠 관찰하면 원인 구간을 좁힐 수 있습니다. 재검사 절차는 SSL 인증서 점검 후 확인을 참고합니다.

경고 화면을 우회해 접속되는 것만으로 해결됐다고 판단하지 말고, 원인을 제거한 뒤 같은 조건에서 오류가 사라졌는지 다시 확인합니다.