ERR_CERT_KNOWN_INTERCEPTION_BLOCKED는 ERR_CERT_AUTHORITY_INVALID와 같은 건가요?

아닙니다 — 더 구체적이고 더 심각한 판정입니다. ERR_CERT_AUTHORITY_INVALID는 인증서가 브라우저가 신뢰 안 하는 루트로 체인된다는 것뿐이라, 원인이 self-signed 개발 인증서부터 중간 인증서 누락까지 뭐든 될 수 있습니다. ERR_CERT_KNOWN_INTERCEPTION_BLOCKED는 Chrome이 문제의 인증서를 *트래픽 가로채기에 쓰이는 것으로 알려진* 인증서로 인식했다는 뜻입니다. Chrome 자체 에러 코드 -217이 그대로 말합니다: '이 인증서는 기기 소유자가 아닌 주체의 가로채기에 쓰이는 것으로 알려져 있다.' 즉 일반적인 '신뢰 안 되는 발급자'가 아니라, 당신 연결이 조작당하는 이유가 알려진 TLS 가로채기 제품의 인증서라고 Chrome이 짚어주고, 그걸 평범한 신뢰 오류로 조용히 넘기길 거부하는 겁니다.

모든 HTTPS 사이트에서 떠요. 무슨 뜻인가요?

그 패턴은 거의 항상 가로채기가 로컬에서 — 당신 기기나 네트워크에서 — 벌어지고 있다는 뜻이지, 특정 웹사이트 문제가 아닙니다. 당신과 인터넷 사이의 무언가가 TLS를 종단하고, 모든 인증서를 자기 발급자로 다시 서명하는데, 그 발급자가 Chrome이 알려진 가로채기 주체로 인식하는 것이면서 당신 시스템은 루트로 신뢰하지 않는 것입니다. 흔한 용의자는 잘못 설치되거나 반쯤 지워진 백신·'웹 실드'의 HTTPS 검사, TLS 검사를 하는데 루트가 신뢰 저장소에 배포된 적 없는 회사 프록시/방화벽, 그리고 나쁜 쪽으로는 동의 없이 같은 짓을 하는 애드웨어나 멀웨어입니다. 한 웹사이트가 모든 사이트에 걸쳐 이걸 일으킬 순 없습니다 — 공통 요소는 그 모두 앞에 앉은 그 물건이니까요.

어떻게 고치나요 — 그냥 통과 클릭해도 되나요?

기댈 '무시하고 계속' 우회가 여기엔 없고, 그건 의도된 겁니다: 이 에러는 바로 당신이 가로채기를 손짓으로 지나치지 못하게 막으려고 존재합니다. 해결은 누가 가로채느냐에 달렸습니다. 당신이 아는 소프트웨어라면 — 회사 TLS 검사, IT팀이 운영하는 모니터링 제품 — 가로채는 쪽의 루트 인증서를 운영체제 신뢰 저장소에 제대로 설치해야 합니다. 기기 소유자가 승인하고 나면 Chrome은 차단 대신 정보성 안내로 낮춥니다. 당신이 요청 안 한 백신 HTTPS 검사라면, 그 기능이나 제품을 끄고 에러가 사라지는지 보세요. 가로채는 주체를 아예 못 알아보겠다면 적대적으로 다루세요: 애드웨어/멀웨어를 검사하고 바뀐 프록시·PAC 설정을 살피세요. 절대 답이 아닌 하나는 웹사이트를 탓하는 것입니다 — 사이트의 진짜 인증서는 멀쩡하고, 경로의 무언가가 그걸 바꿔치기한 겁니다.

조회수: 33

ERR_CERT_KNOWN_INTERCEPTION_BLOCKED 원인

NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED는 Chrome이 TLS 체인에서 가로채기 인증서를 잡아낸 것 — 누가 가로채는지 3단계로 확인. 무료 즉시 SSL 진단.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

Chrome이 NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED와 “연결이 비공개로 설정되어 있지 않습니다” 화면으로 페이지를 거부합니다. 이건 흔한 ‘신뢰 안 되는 인증서’ 에러가 아닙니다. Chrome은 당신 연결이 실제로 쓰고 있는 인증서를 보고, 그걸 알아봤고, 그 인증서가 트래픽 가로채기에 쓰인다는 것을 안다고 말하는 겁니다.

Chromium 에러 테이블은 여기서 유독 직설적입니다 — 코드 -217: “이 인증서는 기기 소유자가 아닌 주체의 가로채기에 쓰이는 것으로 알려져 있다.” 그 마지막 구절을 천천히 읽어보세요. Chrome은 그냥 모르는 발급자를 거부하는 게 아닙니다. 알려진 발급자를 거부하는 거고, 특히 그 가로채기를 기기 주인이 아닌 누군가가 하고 있다고 콕 집습니다. 그 표현이 이 에러의 핵심입니다.

Symptoms

정확한 코드가 ERR_CERT_KNOWN_INTERCEPTION_BLOCKED입니다 — 일반적인 ERR_CERT_AUTHORITY_INVALID가 아니라, Chrome이 굳이 구체적으로 짚었습니다.
한 사이트가 아니라 모든 HTTPS 사이트를 한꺼번에 치는 경우가 아주 많습니다. 그 광범위함이 가장 큰 단서입니다.
지나칠 수 있는 쉬운 “사이트로 이동(안전하지 않음)” 링크가 없습니다 — 일반 인증서 경고보다 차단이 단단합니다.
백신·‘인터넷 보안’ 소프트웨어를 설치·업데이트한 직후, 회사 네트워크에 접속한 직후, 또는 원치 않는 소프트웨어가 깔린 뒤 자주 나타납니다.
인증서를 열어보면 발급자가 사이트의 진짜 CA가 아니라 어떤 보안 제품·장비·프록시 벤더입니다.

Chrome이 가로채기인 걸 아는 방법

Chrome은 CRLSet이라는 계속 갱신되는 자료구조를 브라우저에 별도 채널로 밀어 넣습니다. 긴급 인증서 폐기와 함께, 그 집합은 가로채기에 쓰이는 것으로 알려진 인증서를 표시하는 플래그를 담습니다 — TLS 검사 미들박스, DPI 장비, HTTPS 검사 보안 제품이 서명에 쓰는 루트와 중간 인증서들이죠.

두 가지 상태가 있고, 그 차이가 중요합니다. 그런 인증서가 있어도 기기 소유자가 그 루트를 신뢰했다면 — 당신(또는 IT 부서)이 가로채는 쪽의 CA를 운영체제 신뢰 저장소에 설치했다면 — Chrome은 *detected(감지)*로 다룹니다: 차단하지 않고, 가로채기가 일어나고 있다는 것만 압니다. 하지만 가로채기 인증서가 알려진 것으로 플래그되고 동시에 당신 시스템이 그걸 정당한 루트로 신뢰하지 않으면, Chrome은 *blocked(차단)*로 올려 ERR_CERT_KNOWN_INTERCEPTION_BLOCKED를 던집니다. 다시 말해: 루트가 제대로 설치된 승인된 가로채기는 조용한 안내를 받고, Chrome은 알아보지만 당신 기기는 승인한 적 없는 가로채기는 멈춰 세워집니다.

그래서 이 에러는 사실 웹사이트가 아니라 당신 환경에 대한 진술입니다. 어떤 제품이 당신 브라우저와 서버 사이에 서서 TLS를 종단하고 인증서를 다시 발급하고 있고, Chrome이 알아보고 당신 OS는 신뢰 안 하는 자격증명으로 그러고 있습니다. 웹사이트 자신의 인증서 — 진짜 그것 — 는 당신에게 닿은 적이 없습니다.

Top Causes

백신·‘웹 실드’의 HTTPS 검사 - 암호화된 트래픽을 검사하는 보안 스위트는 로컬 루트를 설치하고 모든 인증서를 다시 서명합니다. 그 설치가 깨졌거나, 반쯤 지워졌거나, 루트가 제대로 신뢰되지 않으면 Chrome은 검증 못 하는 알려진 가로채기 주체를 보고 차단합니다. ‘모든 사이트가 깨지는’ 버전의 가장 흔한 원인입니다.
TLS 검사를 하는 회사 프록시·방화벽 - 기업망은 나가는 HTTPS를 일상적으로 복호화·재암호화합니다. 회사의 검사 루트가 관리 기기마다 배포되면 정당합니다. 그 루트가 설치된 적 없는 기기에선 — 회사 Wi-Fi에 붙은 개인 노트북, 놓친 배포 — 가로채기가 인식은 되지만 신뢰 안 돼서 Chrome이 차단합니다.
애드웨어·멀웨어가 심은 악성 루트 - 적대적 버전. 원치 않는 소프트웨어가 자기 CA를 심고 당신 트래픽을 거기로 흘려 광고를 주입하거나 데이터를 빼갑니다. 가로채는 주체를 아예 못 알아보겠다면, 반증 전까지 이걸로 가정하세요.
네트워크 경로의 미들박스·장비 - 일부 캡티브·관리형 네트워크는 게이트웨이에서 가로채기를 돌립니다. 같은 메커니즘: 당신 트래픽이 Chrome은 알고 당신 기기는 신뢰 안 하는 무언가에 의해 다시 서명됩니다.

DechoNet으로 진단

SSL 점검은 서버가 실제로 제시하는 인증서를 당신 로컬 네트워크 밖에서 검사합니다 — 그래서 당신 가로채기가 바꿔치기한 게 아니라 진짜 체인을 봅니다. 그 비교가 진단 전체입니다: DechoNet은 사이트의 진짜 공개 CA에서 나온 정상 인증서를 보고하는데 당신 브라우저는 낯선 보안 제품 발급자를 보여준다면, 가로채기는 당신과 서버 사이 로컬에서 일어나는 겁니다. 사이트는 멀쩡하고, 당신 쪽 무언가가 사이트 인증서를 바꿔치기한 거죠.
DNS 조회는 당신이 호스트를 진짜 주소로 해석하고 있고, 인증서 교체를 설명할 엉뚱한 곳으로 조용히 리다이렉트되고 있지 않은지 확인합니다. ‘가로채기’가 사실은 완전히 다른 엔드포인트와 대화하는 경우를 배제합니다.

Resolution Checklist

범위를 파악하세요. 모든 HTTPS 사이트를 치나요, 한 곳만인가요? 모든 사이트라면 로컬 가로채기 — 당신 기기의 소프트웨어나 네트워크의 장비 — 를 정확히 가리킵니다.
브라우저에서 인증서 발급자를 읽으세요(“안전하지 않음” 영역 클릭 → 인증서 세부정보). 발급자 이름이 보통 범인을 알려줍니다: 백신 벤더, 방화벽 브랜드, 프록시 제품, 또는 당신이 모르는 무언가.
SSL 점검으로 교차 확인하세요. DechoNet이 사이트의 진짜 공개 신뢰 인증서를 보고 당신 브라우저는 보안 제품 것을 본다면, 가로채기가 로컬이라는 걸 — 서버 문제가 아니라는 걸 — 확인한 겁니다.
백신·‘인터넷 보안’의 HTTPS 검사라면 그 기능을 끄고(또는 제품을 제거하고) 다시 테스트하세요. 여러 제품이 이걸 ‘HTTPS 검사’, ‘암호화된 연결 검사’, ‘웹 실드’라고 부릅니다.
승인된 회사 검사라면, 가로채는 쪽의 루트를 관리하는 사람이 당신 OS 신뢰 저장소에 설치해야 합니다 — 그게 차단을 허용된 감지 상태로 바꿔줍니다. 당신이 관리하지 않는 기기에 직접 루트를 설치하는 즉흥 대응은 하지 마세요.
가로채는 주체를 모르겠다면 적대적으로 다루세요: 평판 있는 애드웨어/멀웨어 검사를 돌리고, 당신이 설정하지 않은 프록시·PAC 설정을 감사하세요.

When to Escalate

관리형·회사 기기라면 IT에 올리세요. 승인된 TLS 검사는 루트를 모든 기기에 배포해야 하는데, 차단은 그 배포가 당신 것을 놓쳤다는 뜻이고, 신뢰 설정을 제대로 고칠 수 있는 건 그들뿐입니다.
가로채는 주체가 모르는 것이고 제거할 수 없다면, 브라우저 성가심이 아니라 보안 사고로 다루세요. Chrome이 가로채기 주체로 인식하는 인증서가 당신 동의 없이 트래픽에 앉아 있다는 건, 무언가가 당신 암호화된 연결을 읽고 있다는 뜻입니다 — 민감한 데 로그인하기 전에 기기부터 청소하세요.