SSL 인증서 오류(NET::ERR_CERT…) 원인과 해결

브라우저가 사이트 접속을 막고 NET::ERR_CERT… 같은 빨간 경고를 띄우는 일은 대부분 5가지 원인으로 좁혀집니다. 인증서 자체가 만료됐거나, 중간 인증서(체인)가 빠졌거나, 접속한 도메인이 인증서에 들어 있지 않거나, 서버와 브라우저가 합의할 TLS 버전·암호 스위트가 없거나, 인증서가 폐기·약한 서명으로 신뢰를 잃은 경우입니다. 오류 코드만 정확히 읽으면 원인은 거의 즉시 좁혀집니다.

이 글은 각 오류의 증상 → 확인 방법 → 해결 순서로 정리합니다. 코드 해석이 헷갈리면 오류 문자열을 그대로 붙여넣어 의미를 풀어 주는 인증서 오류 메시지 해석기를, 실제 인증서 만료일·체인·SAN을 서버에서 직접 조회하려면 SSL 인증서 점검를, 핸드셰이크 협상 실패가 의심되면 TLS 버전 지원 점검를 함께 쓰면 됩니다.

1. 인증서 만료 또는 시스템 시계 오류 — NET::ERR_CERT_DATE_INVALID

증상:"이 연결은 비공개가 아닙니다 / 인증서가 만료되었습니다"와 함께NET::ERR_CERT_DATE_INVALID가 표시됩니다. 인증서의 유효기간이 끝났거나, 반대로내 PC·휴대폰의 시계가 미래/과거로 틀어져 아직 유효한 인증서를 만료로 오판하는 경우입니다.

확인: 먼저 본인 기기의 날짜·시간이 정확한지 보세요. 한 사이트만 그렇다면 서버 인증서가 진짜 만료된 것입니다. SSL 인증서 점검로 도메인을 조회해notAfter(만료일)가 현재보다 과거인지 확인합니다. 여러 사이트가 동시에 같은 오류면 기기 시계 문제입니다.

해결:기기 시계는 "자동 설정(NTP)"을 켜면 끝입니다. 서버 인증서가 만료됐다면 새 인증서를 발급·교체하고, Let's Encrypt라면 certbot renew 자동 갱신(보통 60일 주기)이 제대로 도는지 cron/timer 로그를 점검하세요. 만료 30일 전 알림을 걸어 두는 것이 가장 확실합니다.

2. 신뢰되지 않거나 빠진 중간 인증서 — ERR_CERT_AUTHORITY_INVALID

증상: NET::ERR_CERT_AUTHORITY_INVALID또는 "발급기관을 신뢰할 수 없음". 흔한 함정은 서버가 리프(leaf) 인증서만 보내고 루트로 이어 주는 중간 인증서(intermediate)를 빠뜨린 경우입니다.

데스크톱 크롬은 캐시된 중간 인증서로 우연히 통과하는데, 모바일·자바·일부 API 클라이언트는 실패해 "내 컴퓨터에선 되는데" 같은 혼란이 생깁니다. 자체 서명 인증서나 사설 CA를 OS 신뢰 저장소에 등록하지 않아도 같은 오류가 납니다.

확인: SSL 인증서 점검로 조회해 체인 단계가 "리프 → 중간 → 루트"로 완성되는지 봅니다. 체인이 1단계로 끊겨 있으면 중간 인증서 누락입니다.

해결: CA가 준 풀체인(fullchain) 파일을 서버에 설치하세요. nginx는ssl_certificate에 리프+중간이 합쳐진 파일을, Apache는 SSLCertificateChainFile(또는 최신 버전은 풀체인)을 지정합니다. 사설 CA라면 루트 CA를 클라이언트 신뢰 저장소에 배포해야 합니다.

3. 도메인이 SAN에 없음 — ERR_CERT_COMMON_NAME_INVALID

증상: NET::ERR_CERT_COMMON_NAME_INVALID또는 "이 인증서는 다른 도메인용입니다". 접속한 호스트명이 인증서의SAN(Subject Alternative Name) 목록에 없을 때 발생합니다. 최신 브라우저는 옛 CN 필드를 무시하고 SAN만 보므로, CN만 있고 SAN이 비면 무조건 실패합니다.

전형적 사례: example.com용 인증서로 www.example.com에 접속하거나(또는 반대), 와일드카드 *.example.com로 2단계 하위 a.b.example.com에 접속한 경우입니다. 와일드카드는 한 단계만 덮습니다.

확인: SSL 인증서 점검로 인증서의 SAN 목록을 펼쳐 현재 주소창의 호스트명이 정확히 포함되는지 대조합니다. apex와 www를 모두 쓴다면 둘 다 있어야 합니다.

해결: 필요한 모든 호스트명을 SAN에 포함해 재발급하거나(예: example.com +www.example.com), 광범위하면 와일드카드를 발급합니다. 그 뒤 apex↔www 리다이렉트를 일관되게 설정하세요.

4. 공통 TLS 버전·암호 없음 — ERR_SSL_VERSION_OR_CIPHER_MISMATCH

증상: ERR_SSL_VERSION_OR_CIPHER_MISMATCH. 인증서는 멀쩡한데 핸드셰이크 단계에서 서버와 브라우저가 공통으로 쓸 TLS 버전이나 암호 스위트를 못 찾은 경우입니다. 서버가 TLS 1.0/1.1만 지원하는데 브라우저가 이를 차단했거나, 반대로 서버가 TLS 1.3만 강제하고 오래된 클라이언트가 못 따라오는 식입니다.

확인: TLS 버전 지원 점검로 서버가 어떤 TLS 버전을 받아 주는지 점검합니다. TLS 1.2/1.3 협상이 모두 실패하면 이 원인이 거의 확실합니다.

해결: 서버 설정에서 TLS 1.2와 1.3을 켜고 안전한 암호 스위트를 허용하세요. nginx 예시: ssl_protocols TLSv1.2 TLSv1.3;. 보안을 위해 더 이상 1.0/1.1은 쓰지 말고, 현대 클라이언트가 합의할 수 있는 암호군을 남겨 두면 됩니다.

5. 폐기되었거나 약한 서명 — ERR_CERT_REVOKED / 신뢰 불가

증상: NET::ERR_CERT_REVOKED(키 유출 등으로 CA가 인증서를 철회), 또는 SHA-1·1024비트 RSA 같은 약한 서명 알고리즘이라 최신 브라우저가 신뢰를 거부하는 경우입니다. 후자는 오래된 사설 인증서에서 종종 나타납니다.

확인: 폐기 여부는 CRL/OCSP로 검증됩니다. SSL 인증서 점검로 서명 알고리즘과 키 길이를 보고 SHA-1이나 1024비트가 아닌지 확인하고, 오류 문자열이 헷갈리면인증서 오류 메시지 해석기에 코드를 넣어 폐기/만료/체인 중 무엇인지 구분하세요.

해결: 폐기된 인증서는 새 키쌍으로 재발급하는 것 외엔 답이 없습니다(절대 우회하지 말 것). 약한 서명은 SHA-256 이상, RSA 2048비트 또는 ECDSA P-256으로 재발급하면 됩니다.

실전 예시: 하나의 오류를 끝까지 추적하기

모바일에서만 NET::ERR_CERT_AUTHORITY_INVALID가 뜨고 데스크톱은 멀쩡한 상황을 가정해 봅시다.

1. 오류 코드를 인증서 오류 메시지 해석기에 넣어 "발급기관 신뢰 실패(주로 체인 누락)"로 방향을 잡습니다.
2. SSL 인증서 점검로 서버를 조회하니 체인이 "리프" 한 단계뿐 — 중간 인증서가 빠졌습니다. 데스크톱 크롬은 캐시 덕에 통과했던 것입니다.
3. CA의 풀체인 파일로 교체하고(nginx ssl_certificate fullchain.pem;) 서비스를 리로드합니다.
4. 다시 SSL 인증서 점검로 체인이 "리프 → 중간 → 루트"로 완성됐는지 확인하면 모바일에서도 정상 접속됩니다.

아래 표로 5가지 원인을 한눈에 비교할 수 있습니다.