크롬이 나온 뒤 대부분의 시간 동안 — 그 전의 인터넷 익스플로러와 사파리도 마찬가지로 — “내 브라우저가 이 인증서를 신뢰하는가?”라는 질문의 답은 지루했다. 운영체제가 신뢰하는 걸 신뢰한다. 윈도우의 크롬은 윈도우 인증서 저장소에 물었다. 맥의 크롬은 키체인에 물었다. 브라우저는 세입자였고, 어느 인증기관이 웹을 보증할 자격이 있는지 정하는 집주인은 OS였으며, 크롬은 그저 그 집에 얹혀살았다. 이게 너무 당연해서 대부분은 이걸 하나의 ‘결정’이라고 생각조차 하지 않았다. 그냥 신뢰란 원래 그렇게 작동하는 것이었다.

그러다 2022년 9월, 크롬은 묻기를 멈췄다.

크롬 105는 Chrome Root Store라는 것을 실었다. 크롬이 실행되는 기계와 무관하게, 크롬이 스스로 지니고 스스로 갱신하는 신뢰 인증기관 목록이다. 플랫폼별로 순차 배포됐다 — 윈도우와 맥이 먼저(크롬 108부터 기본 적용), 크롬 114에서 크롬OS·리눅스, 크롬 115까지 안드로이드. 릴리스 노트를 안 읽었다면 알아챌 방법도 없었다. (사용자나 회사 IT가 직접 설치한 루트는 지금도 존중한다. 크롬이 더는 따르지 않는 건 OS 벤더가 정한 공개 목록이다.) 어제 열리던 사이트는 오늘도 열렸다. 이 변화의 요점은 눈에 보이는 일이 아무것도 일어나지 않는다는 것, 바로 그것이었다.

실제로 이 변화가 한 일은 결정권 하나를 옮긴 것이었고, 그게 무슨 뜻인지 대부분이 알아보는 데는 2년이 더 걸렸다.

옮겨진 일자리

옛 방식은 편할 뿐 아니라 눈에 안 보이는 통치였다. 크롬이 OS 루트 저장소를 신뢰할 때, 웹 전체에 인증서를 발급할 수 있는 CA를 실질적으로 정하던 사람들은 마이크로소프트와 애플의 루트 프로그램 팀이었다. 그들의 목록은 서로 완전히 같지도 않았고, 브라우저가 그 차이를 대충 덮었으며, 큰 CA들이 하나같이 모든 저장소에 동시에 들어가고 싶어 했기에 이 체계는 그럭저럭 굴러갔다.

Chrome Root Program은 그 펜을 쥔 사람을 바꾼다. 크롬은 이제 자기 팀이 자기 정책 문서에 비추어 정한 자기 루트 목록을 싣고, 다른 컴포넌트 업데이트가 도착하는 방식 그대로 — OS 벤더가 아니라 구글의 주기에 맞춰, 대역 밖으로 — 브라우저에 배포한다. 포함되려면 OS 저장소가 과거엔 그만큼 엄격히 강제하지 않던 요건을 지켜야 한다. 인증서는 Certificate Transparency 로그에 나타나야 하고, CA는 모든 걸 서명하는 루트 하나가 아니라 TLS 전용 계층을 따로 운영해야 하며, 사고를 잘못 처리한 CA는 문밖으로 내보낼 수 있다. 이 모든 것의 공용 원장은 CCADB지만, 신뢰 결정 — 브라우저를 자물쇠로 이끌지 경고로 이끌지 실제로 가르는 그 부분 — 은 이제 오롯이 크롬의 몫이다.

오랫동안 이건 이론이었다. 그러다 아니게 됐다.

그 대가로 산 것: 엔트러스트

엔트러스트는 이 글을 읽는 대부분의 회사보다 오래된 인증기관이다. 사실상 처음부터 OS 신뢰 저장소에 들어 있었다. 그런데 2024년 6월, 크롬 보안팀은 크롬이 엔트러스트 신뢰를 중단하겠다고 발표했다.

방식은 이런 일이 늘 그렇듯 구체적이었다. 크롬은 엔트러스트 루트로 이어지는 TLS 인증서 중 가장 이른 Signed Certificate Timestamp가 2024년 11월 11일 이후인 것들을 불신하기로 했다 — 그 선 이후 발급된 인증서는 신뢰를 못 받고, 이미 현장에 나간 것들은 만료 때까지 계속 동작한다는 뜻이다. 크롬 131에 실렸다. 차단은 11월 12일에 시작됐고, 그때부터 새로 발급된 엔트러스트 인증서는 자물쇠 대신 전체 화면 경고를 받았다. 발표된 이유는 극적인 단일 침해가 아니었다. 크롬의 표현으로는 약 6년에 걸친 “규정 준수 실패의 패턴”이었고, “공개 신뢰 CA 소유자로서의 역량·신뢰성·성실성”에 대한 팀의 신뢰가 침식될 만큼 쌓였다는 것이다. 수십 년간 자기 루트 저장소를 운영해 온 모질라는 11월 30일에 비슷한 선을 그었다. 애플은 11월 15일에 그었다.

여기서 핵심을 만드는 디테일이 있다. 윈도우는 그해 11월에 엔트러스트를 끊지 않았다. 마이크로소프트는 몇 달 뒤인 2025년 2월 루트 업데이트에서야 자체 기준선을 넣었고, 그것도 2025년 4월 16일 이후 발급분에만 적용했다. (애플은 예외처럼 보이지만 오히려 요점을 보여 준다. 애플의 루트 저장소는 곧 OS 자체라서, 11월 15일 선은 macOS에 그대로 적용됐다.) 그래서 그 겨울 내내, 크롬이 보안 경고를 띄운 윈도우 기계에서 그 아래의 운영체제는 같은 엔트러스트 인증서를 여전히 완벽하게 믿을 만한 것으로 여겼다 — 그리고 시스템 신뢰 저장소를 쓰는 앱이라면, 스크립트 언어의 HTTP 클라이언트든 업무용 데스크톱 앱이든, 아무 불만 없이 접속했다. 인증서는 폐기된 게 아니었다. 만료된 것도 아니었다. 딱 한 가지 이유로 실패했다: 당신이 연 그 특정 프로그램이 자기만의 의견을 가졌고, 그 의견이 더 이상 컴퓨터의 의견과 일치하지 않았다.

그 상태 — 살아 있고 만료도 안 된 인증서를 두고, OS는 신뢰하는데 브라우저는 거부하는 상태 — 자체는 처음이 아니었다. 크롬은 전에도 OS 저장소 위에 손으로 짠 예외를 덧대 이런 상태를 만든 적이 있다. 2015년 CNNIC, 2016~17년 WoSign·StartCom, 2018년 시만텍. 하지만 그때마다 남의 목록에 붙인 특별 패치였다. 이제는 목록 자체가 크롬의 것이고, OS와 의견이 갈리는 게 비상조치가 아니라 기본 상태다.

당신이 한 거래

나는 크롬이 이렇게 한 게 옳았다고 보고, 그리 아슬아슬한 판단도 아니라고 본다. 웹 신뢰를 OS 신뢰에 묶어 두면 CA 규율이 윈도우 업데이트와 맥OS 포인트 릴리스의 속도로 움직인다는 뜻이었고, CA는 불신당하는 일의 엄청난 번거로움에 기대 게으름을 부릴 수 있다는 뜻이었다. 자기 저장소를 싣는 브라우저는 규정 준수 문제에 10년이 아니라 릴리스 한 주기 안에 대응할 수 있고, 다섯 개의 서로 다른 기준을 물려받는 대신 모든 플랫폼에 일관된 잣대를 들 수 있다. 최근 몇 년간 CA 생태계에 일어난 가장 좋은 일인 Certificate Transparency가 강제 가능한 것도, 브라우저가 그것을 신뢰의 조건으로 요구하고 그 말을 지킬 수 있기 때문이다.

하지만 무엇을 내주었는지는 이름 붙여 둘 가치가 있다. “눈에 보이는 일은 아무것도 없었다”는 말이 그 크기를 가리기 때문이다. 신뢰는 예전엔 단수였다 — 기계 위의 모든 것이 떠받드는, 대체로 하나뿐인 목록. 이제는 복수이고 프로그램마다 다르다. 크롬은 자기 저장소를, 모질라는 늘 그래 왔듯 자기 것을, 애플은 자기 것을, 마이크로소프트는 자기 것을 갖고 있고, 이들은 더 이상 서로 합의할 필요가 없다. “사파리에선 되는데 크롬에선 깨진다”는 이제 반드시 렌더링 버그나 캐시 문제인 게 아니다 — 인증기관을 애초에 신뢰해야 하는가에 대한 명백한 견해차일 수 있고, 두 브라우저 다 각자의 규칙에 따라 옳다.

그리고 그 지렛대는 이제 한곳에 몰려 있다. 구글은 자기 시간표와 자기 판단으로, 웹 브라우징의 약 3분의 2를 차지하는 크롬 사용자 전체에 대해 어떤 인증기관이 끝났다고 혼자 결정할 수 있고, 그 사이에서 속도를 늦추거나 뒤집을 OS 벤더는 이제 없다. 지금까지는 그 판단이 신중했고 이유가 공개적이고 구체적이었는데, 이렇게 몰린 권력을 견딜 만하게 만드는 건 오직 그것뿐이다. 엔트러스트 결정은 보도자료가 아니라 6년치 문서화된 사고 기록과 함께 왔다. 그게 매번 그들에게 들이대야 할 기준이다. 2024년에 엉망으로 운영된 CA를 잘라낸 그 메커니즘이 곧 잘 운영되는 CA를 신뢰하는 바로 그 메커니즘이고, 그것은 구글 외에 누구에게도 답하지 않기 때문이다. 예전엔 OS가 그것을 견제했다 — 대체로 우연히. 이제는 아니고, 다시 돌아오지도 않는다.