NET::ERR_CERT_INVALID 해결 (우회 링크 없음)

Problem

Chrome이 NET::ERR_CERT_INVALID를 표시하며 “연결이 비공개로 설정되어 있지 않습니다”로 페이지를 차단합니다 — 그런데 이전에 보던 인증서 오류와 달리, 클릭할 “사이트로 이동(안전하지 않음)” 링크가 없습니다. 벽이 단단합니다. 그 없는 링크가 핵심입니다: Chrome은 인증서를 불신한다고 말하는 게 아니라, 인증서를 해석조차 하지 못했다고 말하는 것입니다.

Symptoms

• Chrome이 NET::ERR_CERT_INVALID를 표시하고 경고 화면에 우회 옵션이 없습니다.
• 오류가 모든 HTTPS 사이트에서 나거나 특정 한 사이트에서만 납니다 — 이 둘은 원인이 정반대입니다.
• 같은 사이트에서 Firefox는 SEC_ERROR_BAD_DER나 일반 “문제가 발생했습니다”를 표시합니다.
• openssl s_client -connect host:443이 파싱 오류를 내거나, 다른 도구도 거부하는 인증서를 반환합니다.
• 백신의 “HTTPS 검사” 또는 “SSL/TLS 필터링”을 끄면 사라집니다.

What NET::ERR_CERT_INVALID Actually Means

Chrome의 인증서 오류는 서로 바꿔 쓸 수 있는 게 아니고, 숫자 코드가 어떤 종류인지 알려줍니다. Chromium의 net_error_list.h에서 ERR_CERT_INVALID는 -207이고, 주석은 딱 한 문장입니다: “The server responded with a certificate that is invalid. This error is not recoverable.” (서버가 유효하지 않은 인증서로 응답했습니다. 이 오류는 복구할 수 없습니다.)

마지막 부분이 중요합니다. 이웃들과 비교해 보세요:

• -200 ERR_CERT_COMMON_NAME_INVALID — 인증서는 유효, 호스트명이 불일치.
• -201 ERR_CERT_DATE_INVALID — 인증서는 유효, 만료됐거나 아직 유효하지 않음.
• -202 ERR_CERT_AUTHORITY_INVALID — 인증서는 유효, Chrome이 발급자를 불신.
• -207 ERR_CERT_INVALID — 인증서가 유효하지 않음, 그게 끝.

앞의 셋은 복구 가능합니다: 인증서는 잘 파싱됐고 신뢰·시간·이름 검사만 실패했으니, Chrome이 위험을 감수하고 우회하도록 허용합니다. -207은 복구 불가입니다 — 우회해서 이동할 온전한 인증서가 반대편에 없기 때문입니다. 손상됐거나, 형식이 깨졌거나, 파싱이 안 됩니다. 그래서 진행 링크가 없습니다. Chrome이 일부러 없앤 것입니다. 안전하게 이동할 대상이 없으니까요.

그러니 진단 질문은 “내 인증서가 신뢰되는가”가 아닙니다. “여기서 Chrome이 왜 유효한 인증서를 파싱하지 못하는가”입니다. 그리고 이걸 가장 빠르게 가르는 질문은: 모든 사이트냐, 한 사이트냐?

Top 3 Causes

1. TLS를 가로채는 중간장비가 Chrome에 깨진 인증서를 건네고 있다 (모든 사이트 실패). 백신 HTTPS 검사, 회사 MITM 프록시, 또는 애드웨어가 자체 루트를 심고 모든 HTTPS 연결을 즉석에서 재서명합니다. 그 재서명 엔진에 버그가 있거나, 루트가 제대로 설치되지 않았거나, 악성코드가 형식이 깨진 인증서를 주입하면, Chrome은 모든 사이트에서 동시에 유효하지 않은 인증서를 받습니다. 단일 PC에서 ERR_CERT_INVALID의 가장 흔한 원인입니다. 지문: 모든 HTTPS 사이트가 깨지고, 검사기를 끄면 전부 고쳐집니다.
2. 서버가 형식이 깨졌거나 손상된 인증서를 서빙한다 (한 사이트 실패). 배포된 인증서 파일이 제대로 된 X.509가 아닙니다 — 잘린 PEM, 잘못 올린 파일, 키와 인증서 불일치, 잘못된 DER 인코딩, 또는 Chrome이 파싱을 거부하는 필드로 만든 인증서. 다른 클라이언트와 openssl도 거부합니다. 지문: 한 사이트가 어디서나 모두에게 실패하고, 나머지 웹은 멀쩡합니다.
3. 사설 또는 어플라이언스 CA가 구조적으로 유효하지 않은 인증서를 발급했다. 사내 CA, 로드밸런서, 임베디드 장비가 음수 시리얼 번호, 형식이 깨진 확장, 잘못된 인코딩을 가진 인증서를 만들기도 합니다 — 옛 도구는 넘어가 줬지만 현대 Chrome은 즉시 거부합니다. 지문: 사내/장비 URL이고, 인증서가 공개 CA가 아닌 무언가에서 왔습니다.

Diagnose with DechoNet

• SSL Check는 서버가 실제로 서빙하는 인증서를 가져와 파싱과 체인이 정상인지 보고합니다 — SSL Check가 깨끗하고 유효한 인증서를 읽는데 브라우저는 여전히 ERR_CERT_INVALID를 보인다면, 문제는 서버가 아니라 내 PC입니다.
• HTTP Check는 형식이 깨진 인증서를 유효한 것으로 교체한 뒤 최종 HTTPS 응답을 확인합니다.

Resolution Checklist

• 먼저 분기를 정하세요: ERR_CERT_INVALID가 모든 HTTPS 사이트에서 나나요, 한 사이트에서만 나나요? 이 한 질문이 올바른 절반의 해결책으로 안내합니다.
• 모든 사이트 → 백신의 “HTTPS 검사” / “SSL/TLS 필터링”을 끄고 테스트하세요. 사라지면 그 엔진이 범인입니다 — 업데이트/재설치하거나 그 기능을 꺼 두세요.
• 모든 사이트인데 백신 없음 → 악성 루트를 확인하세요: 애드웨어/악성코드를 스캔하고, 내가 추가하지 않은 루트 인증서가 있는지 점검하세요.
• 한 사이트 → 네트워크 밖에서 SSL Check를 돌리세요. 거기서도 유효하지 않은 인증서로 보고되면 서버가 깨진 인증서를 서빙하는 것이고, 깨끗하게 보고되면 로컬 문제입니다.
• 서버 쪽: CA 원본 파일로 인증서를 재배포하고, 개인 키가 일치하는지 확인한 뒤, openssl x509 -in cert.pem -noout -text로 파싱되는지 검증하세요.
• thisisunsafe에 의존하지 마세요 — 나에게만 벽을 가릴 뿐, 실제 방문자에게 인증서는 여전히 유효하지 않습니다.

When to Escalate

• SSL Check는 유효한 인증서를 읽는데 회사 관리 PC에서 여전히 ERR_CERT_INVALID가 난다면, 이는 장비 정책이나 프록시 문제입니다 — 사이트가 아니라 TLS 검사 어플라이언스 관리자에게 문의하세요.
• 유효하지 않은 인증서를 내가 통제하지 않는 CDN이나 관리형 플랫폼이 서빙한다면, 형식이 깨진 인증서를 보여주는 SSL Check 출력을 첨부해 그 제공업체에 티켓을 여세요.