2025년 8월 6일, Let’s Encrypt가 OCSP 응답 서버(responder)를 완전히 내렸다. 수억 개 도메인에 인증서를 발급하는 — 압도적 격차로 인터넷 최대인 — 그 CA가, 브라우저가 자기 인증서의 폐기 여부를 확인하는 데 쓴다던 바로 그 장치를 꺼버린 것이다.
당신 사이트가 8월 내내 멀쩡히 돌아갔다면, 그리고 거의 확실히 그랬을 텐데, 이야기는 거기서 끝난다. 웹에서 인증서를 가장 많이 찍어내는 곳에서 “이 인증서 아직 유효한가?”를 묻는 기계를 뽑아버렸는데, 웹은 눈치채지 못했다. 그 기계가 애초에 무슨 일을 하고 있었는지 짐작하게 하는 대목이다.
OCSP가 하기로 되어 있던 일
인증서는 만료일이 박힌 서명된 주장이다. 문제는 만료 전에 무효화해야 할 때가 있다는 것이다 — 개인키가 유출됐거나, 도메인 주인이 바뀌었거나, CA가 오발급을 발견했거나. 폐기(revocation)는 인증서의 “실행 취소” 버튼인데, 이 버튼은 한 번도 제대로 작동한 적이 없다.
첫 번째 답은 CRL(인증서 폐기 목록)이었다. CA가 폐기한 일련번호를 전부 담은 큰 서명 파일을 게시하고 클라이언트가 내려받는 방식. CRL은 커지고 낡아갔고, 그래서 1999년 OCSP(RFC 2560, 이후 RFC 6960)가 더 좁은 대안으로 나왔다. 목록 전체를 당기는 대신 브라우저가 CA에게 실시간으로 딱 하나를 묻는다. 이 일련번호 인증서, 아직 괜찮아? CA 응답 서버가 “good”, “revoked”, “unknown” 중 하나에 서명해 돌려준다.
문서상으로는 CRL보다 깔끔하다. 그런데 실전에서는 해결한 문제보다 더 나쁜 문제 두 개를 만들어냈다.
두 가지 문제
첫째는 프라이버시고, Let’s Encrypt가 플러그를 뽑은 이유가 바로 이것이다. 브라우저가 실시간 OCSP 조회를 할 때마다, 당신이 한 번도 대화하기로 선택한 적 없는 제3자인 CA에게 — 당신이 지금 어느 사이트에 들어가려는지를, IP 주소와 함께, 실시간으로 알려준다. CA는 당신 브라우징의 일부를 흐르는 로그로 갖게 된다. Let’s Encrypt 규모의 CA에게 그 감시 장치를 굴리는 일은 프라이버시 부담인 동시에 막대한 운영 비용이었다 — 대부분 아무 일도 안 하는 확인을 위해 수십억 건의 조회에 답해야 했으니까.
그게 두 번째 문제로 이어지고, 이건 치명적이다. OCSP 응답 서버가 대답을 안 하면 브라우저는 어떻게 해야 하나? 서버가 죽었거나, 느리거나, 하필 당신이 두려워하는 바로 그 네트워크 공격자에게 막혔을 수 있다. 조회가 실패할 때마다 브라우저가 페이지 로딩을 거부하면(“hard-fail”), OCSP 장애 한 번에 그 CA가 발급한 모든 HTTPS 사이트가 죽는다 — 용납 못 할 단일 장애점이다. 그래서 브라우저는 “soft-fail”한다. 조회가 타임아웃 나거나 에러가 나면, 어깨 한 번 으쓱하고 페이지를 그냥 띄운다.
크롬 보안팀의 Adam Langley가 2012년에 가장 잘 표현했다. soft-fail 폐기 확인은 “충돌하는 순간 끊어지는 안전벨트 같다.” 폐기된 인증서를 들이밀려고 당신 연결을 가로챌 수 있는 공격자라면, OCSP 응답 서버로 가는 당신 연결도 막을 수 있다. 조회는 실패하고, 브라우저는 soft-fail하며, 당신이 믿고 있던 그 확인은 정확히 필요한 순간에 증발한다. 폐기 확인은 그게 중요해지기 직전까지만 잘 작동한다.
크롬은 이미, 몇 년 전에 떠났다
2025년의 셧다운이 사건이라기보다 요식행위처럼 느껴지게 만드는 대목이 이것이다. 사용자가 가장 많은 브라우저는 이미 10년도 더 전에 기본값으로 실시간 OCSP 확인을 그만뒀다.
크롬은 위와 똑같은 이유로 2012년 대부분 인증서에 대해 온라인 OCSP·CRL 확인을 비활성화하고, 대신 CRLSet을 도입했다 — 구글이 가치 높은 폐기 건만 골라 목록으로 만들어 업데이트 채널로 브라우저에 밀어 넣는 방식이다. 포괄적이지 않다. 구글이 넣을 만하다고 판단한 폐기 건의 요약본일 뿐이다. 같은 엔진 위에 올린 마이크로소프트 엣지도 똑같이 동작한다. 그러니 지구상 브라우저의 다수는 이미 몇 년째 Let’s Encrypt 응답 서버에 아무것도 묻지 않고 있었다. 응답 서버가 답하던 상대는 파이어폭스, 일부 사파리 트래픽, 그리고 서버 사이드·엔터프라이즈 클라이언트의 긴 꼬리였다.
파이어폭스는 OCSP를 더 오래 붙들고 있다가 CRLite로 독자 노선을 갔다. 모질라는 CA 생태계 전반의 CRL을 모아, Bloom 필터를 영리하게 계단식으로 쌓아 몇 메가바이트로 압축한 뒤 브라우저에 실어 보낸다. 폐기 확인을 로컬에서, 프라이버시를 지키며, 차단당할 수 있는 네트워크 왕복 없이 하려는 것이다. CRL 아이디어를 현대적 압축으로 부활시킨 셈인데 — 우연이 아니게도 — Let’s Encrypt가 OCSP 셧다운을 발표하며 모두에게 가리킨 방향이 바로 이쪽이다. Let’s Encrypt는 CRL은 계속 게시했다. 하나씩 묻는 질문에 답하기를 멈췄을 뿐이다.
그래서, 진짜였던 건 있었나
불편한 결론은 이렇다. 오늘날 브라우저가 실제로 하는 폐기 확인 — 크롬의 CRLSet, 파이어폭스의 CRLite — 은 전부 집계되고, 대역 밖(out of band)으로 밀려오고, 로컬에서 평가된다. 어느 것도 핸드셰이크 도중 브라우저가 CA에 전화 거는 데 의존하지 않는다. OCSP가 제공하려고 발명된 바로 그것, 실시간 조회는 이미 중요한 브라우저들에서 설계상 도려내진 상태였다. 2025년에 응답 서버를 끈 것은 작동하는 안전장치를 제거한 게 아니다. 안전장치가 있다는 겉모습을 제거한 것이다.
그리고 폐기에 대한 업계의 진짜 답은 애초에 더 나은 프로토콜이 아니었다. 인증서를 더 빨리 만료시키는 것이었다. 인증서가 몇 주만 유효하면, 유출된 키는 몇 년이 아니라 몇 주짜리 문제가 되고, 폐기의 비중도 그만큼 줄어든다. 수명 단축 행진 — 지금 200일, 2029년 47일 — 뒤에 깔린 진짜 논리가 이것이다. “실행 취소”를 작동시키지 못하니, 그것이 적용되는 창을 점점 좁혀 실패가 더는 문제되지 않을 때까지 밀어붙인 것이다.
교훈은 OCSP가 유별나게 나빴다는 게 아니다. 모두가 자기를 지켜준다고 믿지만 조용히, 열린 채로 실패하는 보안 통제는 아예 없느니만 못하다는 것 — 확신은 팔아넘기면서 실물은 배달하지 않으니까. OCSP는 20년간 브라우저가 조용히 체크를 그만둔 체크박스였다. 셧다운은 웹을 깨뜨리지 않았다. 그저 서류를 현실에 맞췄을 뿐이다.