Certificate Transparency는 이제 정적 파일로 돌아간다

10년간 모든 TLS 인증서는, 브라우저가 24시간 안에 온라인 상태를 유지하도록 강제하던 살아있는 append-only 암호 데이터베이스에 게시됐다. 2025년, 그 기계는 뜯겨 나가고 버킷 속 정적 파일 폴더로 대체됐다. 더 나은 설계다.

2026년 2월 28일, Let’s Encrypt는 Oak를 완전히 껐다 — 수년간 공개 인터넷에서 발급된 인증서의 상당 부분을 기록하던 Certificate Transparency 로그다. 3개월 전인 2025년 11월 30일에 이미 읽기 전용으로 바뀌었다. 당신이 CA거나 브라우저거나 자기 도메인의 인증서를 감시하는 사람이라면 이건 큰 사건이었다. 그 외 모두에겐 아무 일도 일어나지 않았는데, Oak를 대체한 물건이 이미 그 옆에서 조용히 돌고 있었기 때문이다.

흥미로운 부분은 그 대체물이다. Certificate Transparency는 예전에 Web PKI 전체에서 가장 운영이 까다로운 인프라 중 하나 위에서 돌았다: 브라우저가 온라인·일관성·상시 응답을 요구하던, 살아있는 append-only 암호 데이터베이스다. 그 대체물은 오브젝트 스토리지 버킷에 놓인 정적 파일 디렉터리다. 다운그레이드처럼 들린다. 정반대다.

CT 로그가 하는 일, 그리고 왜 고통스러웠나

모든 인증서가 공개되는 이유는 인증기관(CA)들이 계속 오발급을 했기 때문이다. 2011년 DigiNotar 침해 — 공격자가 CA를 시켜 구글 도메인용으로 작동하는 인증서를 발급받은 사건 — 는 CA가 신중하리라 그냥 믿을 수 없음을 증명했다. 단 하나만 뚫려도 누구의 인증서든 위조할 수 있으니까. 2013년 RFC 6962로 표준화된 Certificate Transparency가 그 해법이다: 공개 신뢰되는 모든 인증서는 공개 append-only 로그에 제출돼야 하고, 그래서 누구든 — 도메인 소유자, 연구자, 브라우저 벤더 — 자기 이름으로 무엇이 발급되는지 지켜보고 악성 인증서를 사후에 잡아낼 수 있다. 2018년부터 Chrome은 로그에 올랐다는 암호학적 증거 없이는 인증서를 신뢰하지 않는다.

보안 아이디어는 우아하다. 구현은 괴물이었다.

RFC 6962 로그는 끝없이 자라는 단일 Merkle 트리이고, 표준은 운영자에게 어려운 약속을 시킨다: CA가 인증서를 제출하면 로그는 즉시 서명된 타임스탬프 — SCT — 를 돌려주는데, 이는 인증서를 Maximum Merge Delay(관례상 24시간)라는 고정 창 안에 트리에 병합하겠다는 약속이다. 그 순간부터 로그는 살아있는 질의 API로 임의의 포함 증명(“이 특정 인증서가 트리에 있음을 증명하라”)과 일관성 증명(“트리가 자라기만 했고 역사를 다시 쓴 적 없음을 증명하라”)을 제공해야 하고, 그 병합 지연보다 오래되지 않은 서명된 트리 헤드를 계속 게시해야 한다.

그건 암호학 의상을 입은 분산 시스템 문제다. 항목을 절대 잃지 않고, 역사를 절대 분기하지 않고, 자기 24시간 약속에 절대 뒤처지지 않고, 브라우저가 눈치챌 만큼 절대 다운되지 않는 데이터베이스를 돌려야 한다 — 그러다 실패하면 브라우저가 그 로그를 불신할 수 있으니까. 그리고 실제로 그랬다. 하나 이상의 CT 로그가 병합 지연 약속을 못 지켜 신뢰 집합에서 빠졌고, 로그를 불신하는 건 그에 의존하던 모두에게 파괴적이다. 규정을 지키는 CT 로그 운영은 PKI에서 가장 즐겁지 않은 일 중 하나로 알려졌다: 판돈 크고, 고가용성 요구되고, 화려하지 않고, 실패하기 쉽다.

재건: 트리를 질의하지 말고 게시하라

이 모든 걸 풀어낸 통찰은 이렇다. Merkle 트리는 이미 해시 더미다. 살아있는 서비스에서 그것에 관한 영리한 질문에 답하려는 걸 그만두고 그냥 전체를 파일로 게시하면, 어려운 부분이 증발한다.

그게 Static CT API — “static-ct-api” — 이고, 그걸 현실로 만든 구현이 Sunlight다. 암호학자 Filippo Valsorda가 Let’s Encrypt와 협력해 설계·작성했고 2024년 3월에 공개했다. 정적 로그는 제출 쪽은 예전과 정확히 같다: CA가 인증서를 POST하면 SCT를 돌려받는다. 하지만 읽기 쪽은 완전히 다르다. 요청 시 증명을 계산하는 살아있는 API 대신, 로그는 자기 트리를 타일(tile) 이라 부르는 정적 파일 계층 — 고정 높이에서 연속된 Merkle 트리 해시를 이어붙인 것 — 과 서명된 체크포인트로 게시한다. 그 타일을 S3든 CDN이든 아무 멍청한 파일 호스트에서 서빙한다. 감시자는 타일을 내려받아 증명을 스스로 계산한다.

이게 무엇을 지우는지 보라. 부하 속에서 응답성을 유지할 살아있는 증명-서빙 API가 없다. 분기할 수 있는 데이터베이스가 없다. 오브젝트 스토리지가 내구성과 가용성을 공짜로 준다 — 버킷 속 파일을 가용하게 만드는 건 아마존이 오래전에 푼 문제다. 그리고 모든 운영자 머리 위에 걸려 있던 24시간 칼, Maximum Merge Delay는 모델에서 그냥 사라진다; 트리 상태는 가장 최근 게시된 체크포인트가 말하는 그것이다. append-only·공개 감사 가능이라는 보안 속성은 온전히 살아남는다 — 그건 앞단의 API가 아니라 언제나 Merkle 트리 안에 있었으니까. 오직 운영의 고통만 제거됐다.

비용 숫자가 요점을 무뚝뚝하게 찍는다. Valsorda는 프로덕션 Sunlight 로그를 단일 서버에서 연간 1만 달러 정도로 돌린다고 밝혔다. 딸꾹질 한 번에 브라우저가 신뢰를 회수하는, 전역 이중화·상시 일관·상시 온라인 암호 데이터베이스를 세우는 것과 비교해 보라. 이건 당신이 두려워하는 인프라와 있는지도 잊는 인프라의 차이다.

실제로 출시됐다

이게 제안이 아니라 역사로 읽히는 이유는, 중요한 타임라인 — 브라우저 신뢰 — 에서 전환이 이미 일어났기 때문이다. Chrome은 2025년 초 업데이트(Chrome 134)에서 static-ct-api를 CT 정책에 추가했고, Apple이 Safari로 뒤따랐고, 2025년 내내 새 정적 로그들이 브라우저 로그 프로그램에서 자리를 얻었다 — 그 로그의 SCT가 실제로 인정받게 하는 자격이다. Let’s Encrypt는 자체 정적 로그 Sycamore와 Willow를 세워, 새것이 완전히 신뢰될 때까지 Oak 옆에서 돌렸다. 그런 뒤에야 옛 세계의 끝을 알렸다: 2025년 11월 Oak 읽기 전용, 2026년 2월 종료.

그 순서가 아무것도 안 깨진 이유의 전부다. 10년치 인증서가 의존하는 로그는, 그 인증서들이 만족시켜야 할 브라우저가 대체물을 신뢰하기 전엔 끄지 않는다. 그래서 옛것과 새것이 나란히 돌았고, 신뢰가 조용히 넘어갔고, 종료는 설계상 김빠지는 사건이었다.

지루한 종류의 승리

나는 이게 얼마나 화려하지 않은지로 자꾸 돌아온다. 그게 요점이니까. 근래 Web PKI에서 가장 성공적인 프로토콜 이전은 새 암호 원시함수도, 영리한 공격 방어도 아니었다. 비싸고, 취약하고, 상시 켜져 있는 서비스를 들여다보고 같은 보안 보장을 정적 파일 게시로 전달할 수 있음을 — 더 싸게, 더 안정적으로, 작은 운영자가 호출기 없이 돌릴 수 있게 — 깨달은 것이었다.

짚어야 할 진짜 트레이드오프가 있다: 감시 쪽이 바뀌어야 했다. 살아있는 CT 로그에 질문을 던지는 도구를 만들었다면, 이제 타일을 가져와 훑어야 한다. 로그를 지켜보는 사람들에겐 실질적인 이전 작업이다. 하지만 그건 옛 설계가 못 주던 걸 산다: 정적 로그는 그냥 파일이므로, 하나를 돌리는 것도 — 그리고 독립적으로 검증하는 것도 — 이제 구글쯤 돼야 참여할 수 있는 게 아닐 만큼 싸다. 분산되고 독립적인 관측이 존재 목적인 투명성 시스템은, 그걸 관측하는 게 소수의 여유 있는 조직에게만 허락된 특권이 아닐 때 더 잘 작동한다.

교훈은 “정적이 늘 낫다”가 아니다. 인프라를 고통스럽게 만드는 많은 부분이 우연적이라는 것 — 굳이 필요 없던 데이터 앞에 세워둔 까다로운 살아있는 API 같은 것. Certificate Transparency는 10년을 운영하기 어려운 시스템으로 보냈다. 알고 보니 어려운 부분은 보안이 아니었다. 배관이었고, 그 배관은 선택 사항이었다.

토론 참여

← 블로그로 돌아가기