Hacker News 2026.04.28 31

X.509 인증서 폐기, 왜 30년이 지나도 깔끔하게 안 풀리는 걸까

무슨 일이 있었냐면요

APNIC(아시아태평양 인터넷 주소 관리 기관) 블로그에 X.509 인증서 폐기(revocation)의 현재 상황과 한계를 정리한 글이 올라왔어요. 우리가 https로 시작하는 사이트에 접속할 때마다 보이지 않는 곳에서 동작하는 "인증서가 아직 유효한가?" 검증, 그게 어떻게 굴러가고 있고 왜 자꾸 문제가 생기는지를 다룬 글이에요.

잠깐, X.509 인증서가 뭐냐면요. https 사이트에 접속하면 브라우저가 그 사이트의 "신분증"을 받아서 검사해요. 이 신분증을 발행하는 기관이 CA(Certificate Authority)고, 발행된 신분증의 표준 포맷이 X.509예요. 신분증에는 "이 사이트는 진짜 naver.com이 맞다"는 보증이 들어 있죠. 그런데 신분증이 도난당하거나 발급이 잘못됐을 때, 만료일 전에 미리 "이거 무효야"라고 알려야 할 때가 있어요. 그게 폐기(revocation)예요.

폐기 메커니즘은 왜 어렵나

원래 표준은 두 가지 방법을 제시했어요. CRL(Certificate Revocation List)과 OCSP(Online Certificate Status Protocol)예요.

CRL은 "폐기된 인증서 목록을 한 파일로 만들어서 배포"하는 방식이에요. 단순하지만 목록이 커지면 수십 메가바이트가 되기 때문에 모든 사용자에게 매번 다운받게 하기 어려워요. OCSP는 "이 인증서 상태 어때?"라고 매번 질문하는 방식인데, 이번엔 프라이버시 문제가 생겨요. CA 서버가 "이 사용자가 어떤 사이트들을 방문하는지"를 다 알게 되거든요. 그리고 CA 서버가 다운되면 https가 다 멈출 수도 있고요.

그래서 나온 게 OCSP Stapling이에요. 사이트 서버가 미리 OCSP 응답을 받아서 "내 인증서 아직 유효해"라는 도장을 찍어둔 채 사용자에게 같이 건네주는 방식이죠. 그러면 사용자 브라우저는 CA에 따로 안 물어봐도 돼요. 그런데 이것도 모든 서버가 다 지원하는 게 아니어서 보급률이 들쭉날쭉해요.

결국 브라우저들은 "실시간 검증을 사실상 포기"하는 길로 가고 있어요. 크롬은 CRLSets라는 자체 압축 폐기 목록을 미리 다운받아두고, 모질라는 CRLite라는 더 정교한 방식을 쓰고 있어요. 각 브라우저 벤더가 "우리가 알아서 정리해서 너희한테 나눠줄게"라는 형태로 가고 있는 거죠.

왜 깔끔한 해결이 어려운가

글에서 짚는 핵심은 "폐기는 본질적으로 분산 시스템 문제"라는 점이에요. 전 세계에 수억 개의 인증서가 있고, 수십억 명의 사용자가 있고, 수백 개의 CA가 있는데 "누가 진실을 갖고 있고, 누가 그걸 얼마나 빨리 모두에게 전파할 수 있는가"를 푸는 건 정말 어려워요. 게다가 네트워크가 일시적으로 끊겨도 사용자는 계속 인터넷을 써야 하니, "폐기 정보를 못 받았으면 어떻게 동작할 거냐"는 질문에 대한 답이 "무조건 차단"일 수가 없어요. 그러면 약간의 네트워크 장애에도 인터넷 절반이 멈추니까요.

그래서 업계는 다른 방향으로 가고 있어요. 인증서 유효 기간을 짧게 줄이는 거예요. 예전엔 2~3년이던 게 1년으로, 그리고 90일로(Let's Encrypt가 시작했죠), 최근엔 47일까지 줄이자는 논의가 진행 중이에요. "폐기를 잘 하는 것보다 그냥 자주 갱신해서 사고 났을 때 자연 만료되게 하자"는 발상의 전환이에요. 짧은 인증서는 자동화가 필수라서 ACME 같은 자동 갱신 프로토콜이 표준이 되고 있고요.

업계 맥락

Let's Encrypt가 무료로 90일짜리 인증서를 뿌린 이후 https 보급률이 급격히 올라간 게 큰 변화였어요. 지금은 https가 기본이고 http가 예외인 시대죠. 한편 Apple, Google, Mozilla가 주도하는 CA/Browser Forum에서 인증서 유효기간 단축을 계속 밀고 있는데, 일부 기업들은 "우리는 자동화 준비가 안 됐다"며 반발하고 있어요. 특히 사내 PKI나 IoT 기기처럼 수동으로 인증서를 관리하는 곳에선 부담이 커요.

새로운 대안으로 Merkle Tree 기반 투명성 로그(Certificate Transparency)가 이미 운영 중이에요. 모든 발급된 인증서를 공개 로그에 기록해서, 잘못 발급된 인증서를 누구나 발견할 수 있게 하는 시스템이죠. "폐기를 잘 하는 것"보다 "잘못된 발급을 빨리 잡아내는 것"으로 초점이 옮겨가는 흐름이에요.

한국 개발자에게는

웹 서비스를 운영하시는 분들에겐 두 가지가 중요해요. 첫째, 인증서 자동 갱신 파이프라인을 갖춰두세요. Let's Encrypt + certbot, AWS ACM, Cloudflare 같은 도구를 활용하면 갱신을 잊어버려서 사이트가 다운되는 사고를 막을 수 있어요. 한국에선 아직도 "인증서 갱신을 사람이 캘린더에 적어두고 하는" 회사가 꽤 있는데, 이건 시한폭탄이에요.

둘째, 사내/모바일 앱의 인증서 핀닝(pinning)을 신중히 하세요. 핀닝은 "이 특정 인증서만 신뢰한다"고 코드에 박아두는 건데, 인증서가 갱신되거나 폐기되면 앱이 통째로 멈춰요. 보안성은 높지만 운영 리스크가 커서, 핀닝 대상을 인증서 자체가 아니라 상위 CA로 두거나 백업 핀을 두는 패턴이 권장돼요.

IoT나 임베디드 쪽에 계신 분들은 "기기가 인터넷에 자주 연결되지 않을 때 폐기 검증을 어떻게 할까"가 진짜 어려운 문제예요. 짧은 인증서 + 자동 갱신 인프라를 어떻게 디자인할지 미리 고민해두는 게 좋아요.