요약

  • Geoff Huston은 2026년 4월 21일 Let’s Encrypt 시험용 인증서를 폐기하고 발급 기관의 폐기 목록에서 일련번호를 확인했다. 48시간 뒤 그가 시험한 세 브라우저 버전은 여전히 접속을 허용했다.
  • 이후 APNIC 62 발표에서는 몇 주가 지난 뒤 Firefox가 같은 인증서를 거부했지만 Chrome과 Safari는 그의 시험에서 계속 받아들였다. 기록이 바뀐 시점과 접속이 막힌 시점 사이가 핵심이다.

인증서는 공식적으로 폐기됐다. 브라우저 앞에서는 아직 출입증이 먹혔다. Geoff Huston은 시험 사이트용 Let’s Encrypt 인증서를 발급한 뒤 네 시간 만인 2026년 4월 21일 폐기했다. 발급 기관의 폐기 목록에는 해당 일련번호가 있었다. 이제 남은 일은 한 가지였다. 사용자가 접속할 때 브라우저도 그 소식을 알고 있을까.

Huston의 APNIC 원문 기록에 따르면, 48시간 뒤 Firefox 148.0.2, Chrome 147.0.7727.117, Safari 25.4는 모두 연결을 허용했다. 인증서 한 장과 특정 버전에 대한 날짜가 있는 관찰이다. 모든 브라우저의 현재 행동으로 확대할 근거는 없다. 다만 권한이 갈리는 지점은 또렷하다. 발급자는 상태를 폐기로 바꿀 수 있고, TLS 연결을 실제로 받아들일지는 클라이언트가 정한다. 목록의 한 줄이 직접 문을 잠그지는 못한다.

시간이 더 흐르자 그림도 조금 달라졌다. APNIC 62 발표 자료에서 Huston은 몇 주 뒤 Firefox가 인증서를 거부한 반면 Chrome과 Safari는 자신의 시험에서 여전히 받아들였다고 밝혔다. 4월 글과 나중 발표는 다른 시점의 사진이다. 하나를 버리고 단순한 승패표를 만들면 가장 흥미로운 부분을 놓친다. 발급 기관에서는 이미 폐기된 열쇠가 사용자 쪽에서는 얼마나 오래 살아남는가.

나쁜 소식을 전달하는 방법마다 청구서가 있다. 폐기 목록을 통째로 받으면 크기가 부담이다. 온라인 상태 조회는 접속 지연과 서버 가용성 문제를 낳고, 사용자가 언제 어느 사이트에 갔는지 발급 기관에 알릴 수 있다. 서버가 서명된 상태 응답을 TLS에 덧붙이면 왕복을 줄이지만, 폐기된 인증서를 내미는 서버가 자신에게 불리한 증거를 자발적으로 내놓을지는 의문이다. 브라우저가 배포하는 선별 목록도 갱신 주기에 매인다.

인증서 수명을 줄이는 해법에도 시계가 남는다. 90일을 45일, 다시 6일로 줄이면 악용 가능한 기간은 짧아진다. 첫날 열쇠가 탈취되면 조기 폐기는 여전히 필요하다. 유효기간을 몇 시간으로 압축하면 현행 발급 체계가 감당해야 할 갱신량이 달라진다. Huston은 발표 마지막 부분에서 서비스 키 정보를 DNS에 두고 DNSSEC으로 서명하며 짧은 TTL로 오래된 답의 최대 나이를 정하는 DANE 설계를 제안한다. 검증 사슬을 TLS 연결에 붙이는 구상도 있다. 이는 그가 제시한 대안이지 오늘의 웹 전체가 이미 채택한 방식은 아니다. 질문은 간단하다. 브라우저가 믿는 답은 지금 몇 분 전의 진실인가.