NET::ERR_CERT_AUTHORITY_INVALID 해결

Problem

Chrome이 NET::ERR_CERT_AUTHORITY_INVALID를 표시하며 “연결이 비공개로 설정되어 있지 않습니다”로 페이지를 차단합니다. 인증서는 존재하지만, 브라우저가 발급자를 신뢰하지 않습니다.

Symptoms

• Chrome은 NET::ERR_CERT_AUTHORITY_INVALID, Firefox는 SEC_ERROR_UNKNOWN_ISSUER, Safari는 “신뢰할 수 없는 인증서”를 표시합니다.
• 일부 브라우저나 기기는 접속되는데 다른 곳은 거부합니다.
• openssl s_client -connect host:443 -showcerts가 인증서를 하나만 반환합니다.

Top 3 Causes

1. 중간 인증서 누락 - 서버가 leaf만 보내, 브라우저가 인증서에서 신뢰 루트까지의 경로를 만들지 못하는 경우. 가장 흔한 원인이며 간헐적입니다: 다른 곳에서 중간 인증서를 캐시한 클라이언트는 성공하고, 나머지는 실패합니다.
2. 자체 서명 인증서 - 공인 CA가 관여하지 않은 경우. 내부·스테이징 용도로는 괜찮지만 공개 브라우저는 절대 신뢰하지 않습니다.
3. 사설 또는 미신뢰 CA가 발급 - 사내 루트, TLS를 가로채는 백신·프록시, 또는 브라우저 루트 저장소에 없는 CA입니다.

Diagnose with DechoNet

• SSL Check로 전체 체인이 제공되며 신뢰 루트까지 이어지는지 확인합니다.
• HTTP Check로 체인 수정 후 최종 HTTPS 응답을 확인합니다.

Resolution Checklist

• openssl s_client -connect host:443 -showcerts를 실행합니다. leaf와 최소 하나의 중간 인증서가 보여야 합니다. 인증서가 하나만 나오면 체인이 불완전한 것입니다.
• leaf만이 아니라 전체 체인 파일(보통 fullchain.pem)을 배포합니다.
• 자체 서명 인증서는 공인 CA 발급 인증서로 교체합니다. Let’s Encrypt는 무료이며 기본 신뢰됩니다.
• 사설 CA가 의도된 것이라면 그 루트를 모든 클라이언트 신뢰 저장소에 배포하세요 — 공개 브라우저가 신뢰할 것이라고 기대하지 마세요.
• 체인 배포 후 SSL Check를 다시 실행해 신뢰 루트까지 이어지는지 확인합니다.

When to Escalate

• 어떤 인증서 번들이 제공되는지 직접 제어할 수 없다면 관리형 호스팅이나 CDN 제공업체에 문의하세요.
• 사내 프록시나 백신이 자체 CA를 주입하고 있다면, 이는 서버가 아니라 관리 기기 정책의 문제입니다.