NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 해결

Problem

Chrome이 전체 화면 경고 NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED와 함께 사이트 로드를 거부합니다. 인증서가 만료되지도, 이름이 틀리지도 않았습니다 — 문제는 그 인증서가 공개 Certificate Transparency 로그에 게시됐다는 증거를 Chrome이 못 찾는다는 것입니다.

Symptoms

• Chrome(또는 Edge/Brave)의 “연결이 비공개로 설정되어 있지 않습니다” 전면 경고 아래에 CT 코드가 붙습니다.
• 같은 사이트가 Firefox에서는, 다른 기기에서는, 또는 사무실 Wi-Fi 대신 모바일 데이터에서는 잘 열립니다.
• 모든 HTTPS 사이트에서 한꺼번에 뜨거나, 특정 사이트 하나에서만 뜹니다 — 둘 중 어느 쪽이냐가 가장 큰 단서입니다.
• 인증서 자체는 멀쩡해 보입니다: 호스트명 정확, 만료 안 됨, 신뢰된 발급자.

What This Error Actually Means

Chrome 68(2018년 7월)부터, 2018년 4월 30일 이후 발급된 모든 공개 신뢰 인증서는 Certificate Transparency에 기록됐음을 증명해야 합니다. CT는 인증서의 공개·추가 전용 원장입니다 — 누구나 자기 도메인으로 발급된 모든 인증서를 볼 수 있게 하는 바로 그 시스템이죠. 로그에 절대 나타나지 않는 오발급 인증서야말로 CT가 잡으려고 만들어진 것이라, Chrome이 이를 강제합니다.

증거는 SCT(Signed Certificate Timestamp) 형태로 인증서와 함께 이동합니다 — CT 로그가 발급 시점에 인증서에 보통 임베드해 주는 작은 영수증입니다. Chrome 정책은 서로 다른 로그 운영자 최소 2곳의 SCT를 원하고, 인증서 수명에 따라 2~3개를 요구합니다. 충분한 SCT가 없으면 신뢰도 없습니다.

이 오류를 진단 가능하게 만드는 지점: Chrome은 공개 신뢰 루트로 끝나는 체인에만 CT를 강제합니다. 관리자가 로컬에 설치한 루트 — 회사 CA, 사내 CA — 로 연결되는 인증서는 의도적으로 면제됩니다. 그래서 이 오류가 보이면 이미 두 가지를 알 수 있습니다: 체인이 공개 루트로 끝난다는 것, 그리고 그 공개 체인에 투명성 영수증이 빠져 있다는 것. 여기서 실제 원인은 둘로 좁혀집니다.

조용한 세 번째 변수도 있습니다. Chrome은 번들된 로그 목록이 신선할 때 — 약 70일 이내 — 만 CT를 강제합니다. 몇 달째 업데이트 안 된 Chrome은 CT 강제를 아예 멈췄다가, 업데이트 후 다시 시작합니다. 브라우저 업데이트 직후 오류가 “난데없이” 나타났다면, 그 타이밍은 우연이 아닙니다.

Top 3 Causes

1. 내 기기·네트워크의 TLS 가로채기 — HTTPS 검사 켠 백신, 회사 프록시, 디버깅 도구가 중간에 앉아 TLS를 종료하고 재서명합니다. 그 루트가 깔끔한 로컬 신뢰 앵커로 설치돼 있지 않으면, Chrome은 대체 인증서를 SCT 빠진 공개 체인으로 취급합니다. 단서: 모든 사이트에서 뜨고, 그 네트워크를 벗어나거나 검사기를 끄는 순간 사라집니다.
2. 정말로 로그 안 된 공개 인증서 — 진짜 서버 인증서가 공개 루트로 연결되지만 충분한 SCT와 함께 로그되지 않았습니다. SCT를 자동 임베드하는 요즘 CA에서는 드물지만, 공개 루트로 연결되는 사설 운영 중간 인증서, 제대로 로그 안 하는 무명 CA, 또는 이후 은퇴한 CT 로그로 기준을 맞췄던 인증서에서 발생합니다. 단서: 모든 네트워크·기기에서 한 사이트에만 뜹니다.
3. 오래됐거나 부분 업데이트된 브라우저 — 원인이라기보다 교란 변수입니다. CT 로그의 자격 상실이나 Chrome 로그 목록 교체는, 경계선에 있던 인증서를 업데이트를 사이에 두고 적합→부적합으로 뒤집을 수 있습니다. “어제는 됐는데”가 서버가 멀쩡하다는 증거가 아닌 이유입니다.

Diagnose with DechoNet

• SSL 점검은 서버가 실제로 제시하는 인증서를 읽어 crt.sh / Certificate Transparency 로그와 대조합니다. 도메인 인증서가 CT에 존재하면 진짜 서버 인증서는 로그된 것이고 — 원인은 서버가 아니라 내 쪽 가로채기를 가리킵니다. 서빙되는 인증서가 CT에 있는 것과 다르면, 무언가 트래픽을 재서명하고 있는 것입니다.
• HTTP 점검은 우리 서버에서, 즉 당신 네트워크 완전히 바깥에서 사이트에 접속합니다. 브라우저는 CT 오류를 내는데 이쪽은 깨끗하게 연결되면, 문제는 로컬입니다 — 사이트가 아니라 당신과 인터넷 사이의 프록시나 검사기.

Resolution Checklist

• 로컬 대 서버부터 격리하세요. 오류가 한 사이트에 뜨나요, 모든 사이트에 뜨나요? 모든 사이트 = 내 기기·네트워크의 가로채기. 한 사이트 = 인증서. 이 질문 하나가 작업의 대부분을 아껴줍니다.
• 모든 사이트라면: 백신의 HTTPS/SSL 검사를 잠시 끄고 다시 테스트하세요. 풀리면 검사기가 제대로 설치된 로컬 루트 없이 가로채는 것입니다. 다시 켜고, 벤더 문서대로 그 루트를 로컬 신뢰 앵커로 설치하거나 해당 사이트를 검사에서 제외하세요.
• 회사 네트워크라면: 검사 루트를 IT가 OS/엔터프라이즈 신뢰 저장소에 배포해야 합니다. Chrome은 로컬 추가 루트를 CT에서 면제하고, 그렇게 설치되지 않은 루트가 바로 이 오류를 냅니다. 브라우저 설정이 아니라 IT의 몫입니다.
• 한 사이트이고 내가 소유했다면: SCT를 임베드하는 CA에서 인증서를 재발급하세요 — 주요 ACME·상용 CA는 전부 합니다. 배포 전에 새 인증서가 임베드 SCT를 갖고 CT 로그에 나타나는지 확인하세요.
• Chrome을 업데이트하고 재시도하세요. 업데이트 직후 오류가 떴다면, 로그 목록 변경이 늘 경계선이던 인증서를 드러낸 것일 수 있습니다.
• SSL 점검을 다시 돌려, 서빙되는 인증서가 로그됐고 체인이 예상한 곳에서 끝나는지 확인하세요.

When to Escalate

• 관리되는 회사 기기에서 모든 HTTPS 사이트가 깨지면, 당신이 아니라 IT의 문제입니다. 검사 루트를 신뢰 저장소에 올바로 배포해야 하고, 정책으로 관리되는 프록시는 브라우저에서 고칠 수 없습니다.
• 내 사이트가 방문자에게 CT 오류를 내고 SSL 점검이 인증서가 CT 로그에 없다고 나오면, CA에 에스컬레이션하세요. 로그되지 않은 공개 신뢰 인증서는 CA 쪽 오발급이며, 해결은 서버 설정 우회가 아니라 재발급입니다.