ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN 해결

Problem

Chrome이 NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN와 “연결이 비공개로 설정되어 있지 않습니다” 화면으로 페이지를 거부합니다 — 거의 항상 Google 자산(Search·YouTube·Gmail이나 Google 리소스를 불러오는 무언가)에서요. 일반 인증서 오류가 아닙니다. 인증서는 그 외엔 유효하며, Chrome은 그 공개 키가 해당 호스트에 대해 핀해 둔 키가 아니라서 거부하는 겁니다.

Chromium 오류 표는 이 점에 대해 직설적입니다 — 코드 -150: 인증서가 “did not match the built-in public key pins for the host name”(호스트명에 대한 내장 공개 키 핀과 일치하지 않음). 잘 읽으세요. 인증서가 신뢰되지 않는다는 게 아닙니다. 신뢰되는데 틀렸다는 겁니다 — Chrome이 어느 키여야 하는지 아는 이름에 대해 틀린 키를 제시한 유효한 체인.

Symptoms

• 정확한 코드는 일반 ERR_CERT_AUTHORITY_INVALID가 아니라 ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN입니다.
• google.com·youtube.com·mail.google.com·gstatic.com 같은 Google 소유 사이트를 때리는데, 무관한 사이트는 잘 열립니다.
• 백신 / “인터넷 시큐리티” 소프트웨어를 설치·업데이트하거나 회사·공용 네트워크에 접속한 직후 시작되는 일이 잦습니다.
• 인증서를 살펴보면 발급자가 Google Trust Services가 아니라 백신 벤더, 프록시 장비, 혹은 알아볼 수 없는 무언가입니다.
• 깔끔한 “계속 진행” 우회가 없습니다 — 일반 경고보다 차단이 단단합니다.

How Chrome Decides the Key Is Wrong

Chrome은 내장된 공개 키 핀 세트를 함께 배포합니다. 핀 걸린 호스트에 대해, 서버가 제시하는 인증서 체인의 키 중 최소 하나는 그 목록의 키와 일치해야 합니다. 체인이 완벽히 검증됐는데 그 키 중 어느 것도 핀되어 있지 않으면 Chrome은 ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN를 던집니다. 이 검사는 일반 검증 뒤에 돌기 때문에, 인증서는 이미 신뢰·날짜·호스트명을 통과했고 오직 정체성에서만 실패합니다.

여기서부터가 이 미스터리를 진단으로 바꿉니다. Chrome은 체인이 로컬 설치된(사설) 신뢰 앵커에서 끝날 때 핀을 일부러 강제하지 않습니다. 당신이 — 또는 IT 부서가 — 머신에 커스텀 루트 CA를 설치했고 가로채는 인증서가 그 루트로 체인이 이어진다면, Chrome은 핀 검사를 통째로 건너뜁니다. 이건 의도된 것입니다: 회사 TLS 검사와 백신 HTTPS 스캔이 핀 걸린 사이트를 깨뜨리지 않고 동작하도록 허용하는 방식이죠.

그러니 오류가 떴다는 건 구체적인 걸 알려줍니다: 인증서를 재서명한 그 무엇이 제대로 설치된 로컬 루트로 체인이 이어지지 않는다는 것. 그 루트가 신뢰 저장소에 설치된 적이 없거나, Google 것이 아닌 공개 신뢰 인증서로 재서명하고 있거나 — 둘 다 가로채기이고, 어느 쪽도 웹사이트 문제가 아닙니다. 이게 거의 절대 아닌 것은 실제 사이트입니다 — Google의 진짜 인증서는 당신 브라우저에 닿지도 못했습니다.

Top Causes

1. 백신 또는 “웹 실드” HTTPS 스캔 — 암호화 트래픽을 검사하는 보안 제품은 모든 인증서를 재서명합니다. 그 로컬 루트가 깔끔하게 설치되지 않으면(중단된 설치, 망가진 업데이트), 재서명된 Google 인증서엔 핀된 키도 없고 면제해 줄 신뢰된 로컬 앵커도 없어 Chrome이 차단합니다. “Google만 깨지는” 버전의 가장 흔한 원인입니다.
2. 회사 프록시나 방화벽의 TLS 검사 — 기업망은 아웃바운드 HTTPS를 복호화·재암호화합니다. 검사 루트가 설치된 적 없는 기기 — 회사 Wi-Fi에 올린 개인 노트북, 누락된 배포 — 에서는 가로채기가 드러나고 면제되지 않아, 핀 걸린 Google 도메인은 깨지고 나머지 웹은 절뚝이며 돌아갑니다.
3. 악성 루트를 심는 애드웨어/멀웨어 — 적대적 버전입니다. 원치 않는 소프트웨어가 자기 CA로 트래픽을 돌려 광고를 주입하거나 데이터를 빼냅니다. 발급자를 전혀 알아볼 수 없다면, 반증되기 전까진 이것으로 가정하세요.
4. 오래된 핀 또는 HSTS 항목(역사적) — 드물게, 2018년 이전 HPKP 시절의 옛 동적 핀이 Chrome 내부 상태에 남아 있습니다. chrome://net-internals/#hsts에서 해당 호스트 항목을 지우면 그 특정 케이스는 풀리지만, 오늘날 흔한 원인은 아닙니다.

Diagnose with DechoNet

• SSL Check는 서버가 실제로 제시하는 인증서를 로컬 네트워크 바깥에서 검사합니다 — 그래서 가로채기가 바꿔치기한 게 아니라 Google의 진짜 체인을 봅니다. Google 소유 호스트에 대고 돌려보세요: DechoNet은 정상적인 Google Trust Services 인증서를 보고하는데 당신 브라우저는 낯선 보안 제품 발급자를 보인다면, 가로채기는 당신과 서버 사이 로컬에서 일어나는 겁니다. 그 대조가 진단의 전부입니다.
• DNS Check는 호스트를 진짜 Google 주소로 해석하고 있는지, 바꿔치기된 인증서를 설명할 만한 곳으로 리다이렉트되고 있지 않은지 확인합니다. 아예 엉뚱한 엔드포인트와 조용히 대화하고 있는 경우를 배제합니다.

Resolution Checklist

• 범위를 확인. Google 소유 사이트만 때리고 나머지는 잘 되나요? 그게 Chrome이 핀 걸린 도메인에서만 잡아내는 로컬 가로채기의 서명입니다.
• 브라우저에서 인증서 발급자를 읽으세요(“안전하지 않음” 영역 클릭 → 인증서 세부정보). Google Trust Services 대신 백신 벤더, 방화벽 브랜드, 프록시 제품 이름이 나오면 가로채는 주체를 찾은 겁니다.
• 바깥에서 SSL 진단으로 교차 확인. DechoNet은 Google의 진짜 인증서를 보는데 당신 브라우저는 보안 제품 것을 본다면, 가로채기가 서버가 아니라 로컬임이 확인됩니다.
• 백신 / “인터넷 시큐리티” HTTPS 스캔이면, 그 기능을 끄고(흔히 “HTTPS 스캔”, “암호화 연결 스캔”, “웹 실드”로 불림) 다시 테스트하세요.
• 허가된 회사 검사라면 IT가 검사 루트를 올바로 설치해야 합니다 — 그리고 대부분의 기업 프록시는 바로 이 문제를 피하려 핀 걸린 도메인을 우회하도록 설정됩니다. 관리하지 않는 기기에 임의로 루트를 설치하지 말고 보고하세요.
• 가로채는 주체를 알아볼 수 없다면 적대적으로 다루세요: 평판 좋은 애드웨어/멀웨어 검사를 돌리고 프록시·PAC 설정에 당신이 설정하지 않은 게 있는지 감사하세요.
• 눈에 보이는 가로채기 없이 한 호스트에서만 오류가 지속될 때만, chrome://net-internals/#hsts에서 그 호스트를 지워 남은 캐시 핀을 떨어냅니다.

When to Escalate

• 관리형·회사 기기라면 IT에 에스컬레이션하세요. 허가된 검사는 루트를 모든 기기에 배포하거나 핀 걸린 Google 도메인을 제외해야 하는데, 핀 실패는 당신 머신에서 둘 다 안 됐다는 뜻이고 오직 그들만 제대로 고칠 수 있습니다.
• 가로채는 주체가 알 수 없고 제거할 수 없다면, 브라우저 성가심이 아니라 보안 사고로 다루세요. 무언가가 동의 없이 Google로 가는 암호화 연결을 재서명하고 있습니다 — 민감한 곳에 로그인하기 전에 머신을 청소하세요.
• 웹사이트 소유자인데 방문자가 당신 사이트에서 이게 뜬다고 한다면, 서버 보는 걸 멈추세요. Google 핀 도메인을 운영하는 게 아닌 한 당신 인증서는 이 핀을 건드릴 수 없습니다 — 실패는 방문자 환경에 있습니다.