NET::ERR_CERT_VALIDITY_TOO_LONG: 398일 초과 해결

문제

Chrome이 연결이 비공개로 설정되어 있지 않습니다와 함께 NET::ERR_CERT_VALIDITY_TOO_LONG를 보여줍니다. 이 부분을 잘 읽어야 합니다. 사람들이 여기서 헷갈립니다. 인증서는 만료되지 않았고, 이름도 맞고, 체인도 온전합니다. 딱 한 숫자만 빼면 다 정상입니다. 유효 구간 — notBefore에서 notAfter까지의 거리 — 이 이제 브라우저가 허용하는 길이보다 깁니다. Chrome 85부터, 공개 신뢰 CA로 연결되며 2020-09-01 이후 발급된 TLS 인증서는 유효기간이 398일 이하(약 13개월)여야 합니다. 하루라도 넘으면 나머지가 아무리 멀쩡해도 브라우저는 그 인증서를 잘못 발급된 것으로 보고 거부합니다.

증상

• Chrome과 Edge에서 전체 화면 경고가 NET::ERR_CERT_VALIDITY_TOO_LONG로 뜹니다. Safari와 Firefox도 같은 인증서를 거부합니다 — 동일한 398일 상한을 강제합니다.
• 인증서 날짜는 현재 유효합니다. 이건 ERR_CERT_DATE_INVALID가 아닙니다. 오늘은 유효 구간 안에 편안히 들어 있습니다.
• “고급”을 눌러도 공개 사이트에는 쓸 만한 “계속 진행”이 없습니다 — 브라우저는 인증서 자체를 비규정으로 보지, 단지 미신뢰로 보지 않습니다.
• 모든 네트워크와 새 프로필에서 나타납니다. 연결이나 캐시가 아니라 인증서의 속성이기 때문입니다.

주요 원인 3가지

1. 유효 구간이 398일을 넘게 발급된 공개 CA 인증서 - 문자 그대로의 원인. 상용 CA는 몇 년 전부터 이런 걸 발급하지 않으므로, 2026년에는 대개 공개 신뢰 루트로 연결되면서도 긴 수명의 리프를 서명하도록 설정된 사설 중간 CA에서 옵니다 — 크로스 서명된 내부 PKI, 장비 내장 서브 CA, 예전 방식으로 2~3년짜리 인증서를 발급하는 기기 관리 플랫폼. Chrome은 체인 어디서 긴 수명이 설정됐든, 공개 루트로 끝나는 모든 것에 398일 규칙을 적용합니다.
2. 소급된 notBefore - 교묘한 경우. 일부 운영자는 클라이언트 시계 오차를 견디려고 notBefore를 며칠 앞당깁니다. 그렇게 해놓고 앞으로의 유효기간을 397일로 잡으면, 브라우저가 재는 전체 구간이 조용히 398일을 넘습니다. 사람 눈에는 1년짜리로 보이는데 브라우저에는 너무 길게 읽힙니다. “오늘부터 몇 개월”이 아니라 항상 notAfter 빼기 notBefore로 재세요.
3. 유효 구간 안에 아직 남은 옛 장수 인증서 - 컷오프 이전에 2~3년 수명으로 발급된 인증서는 2020-09-01 이전 발급인 경우에만 예외로 인정됩니다. 그 이후에 옛 수명으로 발급된 것 — 내부 템플릿 재사용, 백업에서 복원, 규정을 모른 펌웨어가 생성 — 은 서빙되는 순간, 발급 몇 년 후라도 실패합니다.

DechoNet으로 진단

• SSL 진단은 회선의 인증서를 읽어 notBefore, notAfter, 발급자, 체인을 보여줍니다. 두 날짜를 빼세요. 구간이 398일을 넘고 발급자가 공개 루트로 연결되면, 한눈에 원인을 확인한 것입니다. 생각한 인증서를 실제로 서빙 중인지도 알려줍니다.
• HTTP 진단은 TLS를 논외로 하고 엔드포인트가 정상인지 확인합니다 — 여러 엣지에 걸쳐 재발급할 때 교체가 각 지점에 실제로 반영됐는지 알아야 할 때 유용합니다.

해결 체크리스트

• 서빙되는 인증서의 실제 구간을 재세요: echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -dates. notAfter − notBefore를 계산합니다. 398일을 넘으면 그게 문제 전부입니다.
• 소급된 notBefore를 확인하세요. notBefore가 발급일보다 며칠 앞서 있으면, 앞으로의 유효기간에 소급분이 더해져 구간이 넘었을 수 있습니다. 앞으로의 유효기간을 줄여 보정하세요.
• 규정에 맞는 수명으로 재발급하세요. 상한보다 넉넉히 아래로 잡으세요 — 업계는 계속 줄이는 중입니다: CA/Browser Forum 투표 SC-081v3가 최대치를 이미 2026-03-15부로 200일로 낮췄고, 2027년 100일, 2029년 47일로 갑니다. 90일 인증서(Let’s Encrypt식, 자동 갱신)면 이 모든 단계를 비껴갑니다.
• 긴 수명이 자체 중간 CA에서 왔다면, 이 리프 하나가 아니라 발급 템플릿을 고치세요 — 아니면 갱신 때마다 오류가 재현됩니다.
• 재설정할 수 없는 장비나 펌웨어가 장수 인증서를 스스로 만든다면, 규정에 맞는 인증서로 TLS를 종단하는 리버스 프록시를 앞에 두세요.
• 종단하는 모든 계층 — 오리진, 로드밸런서, CDN 엣지 — 에 재설치하고 재확인한 뒤, SSL 진단을 다시 돌려 새 구간이 여러 지점에서 398일 미만인지 확인하세요.

에스컬레이션 시점

• 상용 공개 신뢰 CA가 컷오프 이후에 실제로 398일 넘는 리프를 발급했다면, 이건 그쪽의 오발급입니다. 신고하세요 — CA는 CA/Browser Forum 규칙에 묶여 있어 이를 알고 싶어 합니다.
• 재설정할 수 없는 하드웨어(로드밸런서 장비, 원격 관리 컨트롤러, 프린터)가 인증서를 만든다면, 기기와 싸우지 마세요. 앞단 프록시에 규정 인증서를 두고, 기기는 뒤쪽에서 자체 서명 인증서를 유지하게 하세요.
• 내부 전용 호스트인데 짧게 재발급이 정말 곤란하다면, 발급 루트를 수동 신뢰 CA로 함대에 배포하세요. 그러면 398일 규칙에서 빠집니다 — 다만 이건 통제된 함대 한정 답이지, 공개 인터넷에서 꺼낼 방법이 절대 아닙니다.