정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#인증서폐기#CRL#OCSP#OCSP Stapling#PKI
최종 업데이트 · 2026-10-24

인증서 폐기 검증(CRL·OCSP·OCSP Stapling)

1. 개요

가. 정의

인증서 폐기(Certificate Revocation) 란 아직 유효기간이 남아 있는 공개키 인증서(X.509)를 어떤 사유로 인해 더 이상 신뢰할 수 없게 되었을 때, 발급 기관(CA)이 그 인증서를 '무효'로 선언하는 행위를 말한다. 폐기 검증(Revocation Checking) 은 인증서를 신뢰하기 전에 "이 인증서가 폐기 목록에 올라 있지 않은가"를 확인하는 절차이며, 대표 메커니즘이 CRL(Certificate Revocation List), OCSP(Online Certificate Status Protocol), 그리고 OCSP를 성능·프라이버시 측면에서 보완한 OCSP Stapling이다.

공개키 기반구조(PKI)에서 인증서는 '유효기간(notBefore~notAfter)' 동안 유효하다고 가정되지만, 현실에서는 유효기간이 끝나기 전에 개인키가 유출되거나 발급 정보가 바뀌는 사고가 발생한다. 이때 유효기간만으로는 신뢰를 철회할 방법이 없으므로, PKI는 '유효기간'과 별개로 '폐기'라는 능동적 신뢰 철회 수단을 둔다. 즉 인증서 검증은 서명 체인 검증(신뢰 경로)과 폐기 검증(철회 여부)이라는 두 축으로 완성되며, 폐기 검증이 빠지면 탈취된 키로 서명한 가짜 서버를 정상으로 신뢰하게 되는 치명적 공백이 생긴다.

폐기 검증의 본질적 어려움은 '실시간성'과 '확장성·프라이버시'의 상충에 있다. 폐기 사실을 최대한 빨리 전 세계 검증자(브라우저·클라이언트)에게 알려야 신뢰 철회가 효과를 내지만, 수억 장의 인증서를 수십억 클라이언트가 매 접속마다 조회하게 하면 네트워크·CA 부하와 지연, 그리고 "누가 어떤 사이트에 접속하는가"가 CA에 노출되는 프라이버시 문제가 동시에 발생한다. 아래에서 다룰 CRL·OCSP·Stapling·CRLite 등은 모두 이 상충을 서로 다른 방식으로 절충한 결과물이다.

나. 등장 배경과 필요성

초기 PKI 표준(RFC 5280 등)은 폐기 수단으로 CRL을 먼저 정의했다. CRL은 CA가 폐기된 인증서의 일련번호(Serial Number)를 모아 서명한 '블랙리스트'를 주기적으로 배포하는 방식으로, 구조가 단순하고 오프라인 검증이 가능하다는 장점이 있었다. 그러나 인터넷 규모가 커지면서 CRL 파일 자체가 수 MB에 달해 매번 내려받기 어려워졌고, 최신 폐기 정보가 반영되기까지 수 시간~수일의 지연이 생기는 적시성(Timeliness) 한계가 드러났다.

이를 보완하기 위해 RFC 6960으로 표준화된 OCSP가 등장했다. OCSP는 특정 인증서 하나의 상태만 실시간으로 질의·응답하는 방식으로 전송량과 지연을 줄였다. 하지만 OCSP는 클라이언트가 접속하려는 사이트를 CA에 그대로 노출하는 프라이버시 문제, OCSP 응답 서버가 느리거나 장애일 때 접속 지연이 발생하는 가용성 문제를 낳았다. 또한 응답 서버 장애 시 대부분의 브라우저가 '안전하게 차단'하지 않고 '일단 통과'시키는 소프트 실패(Soft-fail) 를 택하면서, 공격자가 OCSP 트래픽만 차단하면 폐기 검증을 무력화할 수 있는 근본 한계가 드러났다.

이러한 배경에서 응답을 서버가 대신 받아 TLS 핸드셰이크에 실어 보내는 OCSP Stapling, 브라우저가 폐기 정보를 압축해 미리 내려받는 CRLite·CRLSets, 그리고 유효기간 자체를 짧게 줄여 폐기 의존도를 낮추는 단기 인증서(Short-lived Certificate) 전략이 차례로 제시되었다. 정보관리기술사 관점에서 폐기 검증은 "완벽한 단일 해법이 없고, 보안·성능·프라이버시·가용성을 상황에 맞게 절충하는 설계 문제"로 이해해야 한다.

특히 폐기 검증은 TLS·PKI라는 인터넷 신뢰의 뿌리에 닿아 있어, 한 CA나 한 브라우저의 설계 변경이 전 세계 수십억 접속에 즉시 영향을 미친다는 파급성을 지닌다. 따라서 폐기 메커니즘의 선택은 특정 서비스의 성능 최적화 문제가 아니라, 표준화 기구(IETF·CA/Browser Forum)와 주요 브라우저·CA가 함께 결정하는 생태계 차원의 거버넌스 문제로 다루어진다. 최근 Let's Encrypt의 OCSP 폐지나 유효기간 단축 의결이 업계 전체의 운영 방식을 바꾸는 것도 이 때문이며, 실무자는 이러한 상위 표준 변화를 상시 추적해 자신의 인증서 운영 체계에 선제적으로 반영해야 한다.

2. 폐기 검증의 전체 구조와 폐기 사유

인증서 폐기 검증은 발급(CA)–배포(검증 인프라)–검증(클라이언트)의 3계층 흐름으로 이루어진다. 아래 전체 구조도는 CA가 폐기를 선언한 뒤 그 정보가 CRL·OCSP·Stapling 경로를 거쳐 검증자에게 도달하는 과정을 보여준다. 어떤 경로를 쓰든 출발점은 CA의 폐기 선언이며, 차이는 "폐기 정보를 누가·언제·어떻게 가져오느냐"에 있다.

flowchart TD
  CA["인증 기관(CA) - 폐기 선언·서명"]
  REPO["폐기 저장소(CRL 배포점·OCSP Responder)"]
  SERVER["대상 서버(TLS 종단)"]
  CLIENT["검증 클라이언트(브라우저)"]
  CA -->|"폐기 일련번호 등록"| REPO
  REPO -->|"① CRL 전체 목록 다운로드"| CLIENT
  REPO -->|"② OCSP 단건 질의·응답"| CLIENT
  REPO -->|"③ 서버가 OCSP 응답 미리 수신"| SERVER
  SERVER -->|"③ TLS 핸드셰이크에 응답 첨부(Stapling)"| CLIENT
  CLIENT -->|"폐기 여부 판정 후 신뢰·차단"| CLIENT
  style CA fill:#e8f0fe,stroke:#2f6fed,stroke-width:1px
  style REPO fill:#eafbea,stroke:#2f9e44,stroke-width:1px
  style CLIENT fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px

가. 폐기가 필요한 상황(폐기 사유)

폐기는 임의로 일어나지 않고 명확한 사유 코드(reasonCode)에 근거한다. 가장 심각한 사유는 키 침해(keyCompromise) 로, 인증서에 대응하는 개인키가 유출·탈취된 경우다. 이때는 공격자가 해당 키로 정상 서버를 가장할 수 있으므로 즉시·광범위한 신뢰 철회가 필요하다. 2014년 OpenSSL의 Heartbleed 취약점으로 수많은 서버 개인키가 메모리에서 노출될 수 있다는 사실이 밝혀지자, 전 세계적으로 대규모 재발급·폐기가 일어나 CRL이 폭증했던 사례가 대표적이다.

그 밖에 CA 운영상의 사유로는 발급 정보 변경(affiliationChanged), 상위 인증서 폐기에 따른 연쇄 폐기, 가입자의 업무 중단(cessationOfOperation), 오발급(불충분한 도메인 검증 등 CA 정책 위반) 등이 있다. 실제로 CA가 도메인 소유 검증을 잘못해 발급한 인증서가 발견되면, CA/Browser Forum 규정에 따라 CA는 정해진 기한(대개 24시간~5일) 내에 해당 인증서를 의무적으로 폐기해야 한다. 이처럼 폐기는 보안 사고뿐 아니라 CA 신뢰 체계의 책임성(Accountability) 을 담보하는 제도적 장치이기도 하다.

폐기 사유 가운데 특히 중요한 것은 상위(중간·루트) CA 인증서의 폐기다. 신뢰 체인의 상위 인증서가 폐기되면 그 밑에서 발급된 모든 하위 인증서가 한꺼번에 신뢰를 잃으므로, 영향 범위가 단일 서버가 아니라 CA 전체 가입자로 확산된다. 실제 CA 운영 위반으로 중간 CA가 루트 스토어에서 퇴출·불신(distrust)된 사례들은, 폐기가 개별 인증서 문제를 넘어 신뢰 생태계 전체의 위험 관리 문제임을 보여준다. 따라서 조직은 자신이 의존하는 CA의 신뢰도·운영 이력까지 폐기 대응 계획의 변수로 삼아야 한다.

나. 폐기 검증의 기본 원리

검증자는 인증서 체인을 따라 각 인증서에 대해 (1) 서명·유효기간·이름 제약 등 '정적 검증'과 (2) 폐기 여부라는 '동적 검증'을 함께 수행한다. 인증서 안에는 폐기 정보를 어디서 얻을지 알려주는 두 확장 필드가 들어 있다. CDP(CRL Distribution Points) 는 CRL을 받을 URL을, AIA(Authority Information Access) 의 OCSP 항목은 OCSP 응답 서버의 URL을 가리킨다. 검증자는 이 포인터를 따라 폐기 정보를 조회한 뒤, 대상 인증서의 일련번호가 폐기되었는지 판정한다.

여기서 핵심 설계 쟁점은 "조회가 실패하면 어떻게 할 것인가" 이다. '하드 실패(Hard-fail)'는 폐기 정보를 확인하지 못하면 연결을 차단하는 안전 우선 정책이고, '소프트 실패(Soft-fail)'는 일단 연결을 허용하는 가용성 우선 정책이다. 대부분의 상용 브라우저는 사용자 경험과 가용성을 이유로 소프트 실패를 채택해 왔는데, 이는 공격자가 폐기 조회 트래픽만 차단하면 폐기된 인증서도 통과시킬 수 있다는 구조적 약점을 남긴다. 바로 이 약점이 OCSP Stapling과 브라우저 내장형 폐기 목록(CRLite 등)이 등장한 직접적 동기다.

소프트 실패가 보편화된 이유는 역설적이게도 '폐기 인프라 자체의 불안정성'이다. OCSP Responder나 CRL 배포점이 다운되었을 때 하드 실패를 적용하면, 정상 서버인데도 폐기 조회가 안 돼 전 세계 사용자가 접속하지 못하는 대규모 장애가 발생할 수 있다. 과거 주요 CA의 OCSP 장애가 광범위한 접속 불능을 유발한 경험이 쌓이면서, 브라우저는 "폐기 검증 실패로 인한 가용성 사고"를 피하려 소프트 실패로 기울었다. 이 선택은 보안을 일부 양보한 현실적 타협이며, 그 공백을 메우기 위해 검증을 네트워크 조회에서 분리(Stapling·내장형)하려는 흐름이 강해진 것이다.

3. 폐기 검증 메커니즘

세 메커니즘은 '폐기 정보를 누가 가져와 누구에게 전달하느냐'의 책임 분담이 다르다. 아래 상세도는 OCSP Stapling이 적용된 TLS 핸드셰이크에서 서버가 OCSP 응답을 대신 받아 클라이언트에 첨부하는 흐름을 나타낸다. 일반 OCSP에서는 클라이언트가 직접 Responder에 질의하던 단계를 서버가 사전에 대신 수행한다는 점이 핵심 차이다.

sequenceDiagram
  participant R as OCSP Responder(CA)
  participant S as 웹 서버
  participant C as 클라이언트(브라우저)
  S->>R: 자기 인증서 상태 사전 질의(주기적)
  R-->>S: 서명된 OCSP 응답(유효기간 포함)
  Note over S: 응답을 캐시(Staple 준비)
  C->>S: TLS ClientHello(status_request 확장)
  S-->>C: 인증서 + 첨부된 OCSP 응답(Stapled)
  Note over C: 서버 접속만으로 폐기 확인 완료
  C->>C: 서명·유효기간 검증 후 신뢰·차단

가. CRL(Certificate Revocation List)

CRL은 CA가 폐기한 인증서들의 일련번호와 폐기 시각·사유를 모아 CA 개인키로 서명한 목록이다. 검증자는 CDP가 가리키는 URL에서 CRL을 내려받아 캐시해 두고, 대상 인증서의 일련번호가 목록에 있는지 대조한다. 서명이 되어 있으므로 위변조가 불가능하고, 한 번 받아 두면 다음 갱신(nextUpdate) 전까지 오프라인 검증이 가능하다는 것이 큰 장점이다.

단점은 규모와 적시성이다. 대형 CA의 CRL은 수십만수백만 건의 항목을 담아 파일이 수 MB에 이를 수 있고, 클라이언트가 이를 모두 받아 파싱하는 비용이 크다. 또한 CRL은 보통 수 시간수일 주기로 갱신되므로, 방금 폐기된 인증서가 다음 발행 전까지는 목록에 반영되지 않는 시차가 존재한다. 이를 완화하기 위해 변경분만 담는 Delta CRL, 세그먼트로 쪼개는 Partitioned CRL 같은 기법이 있으나, 근본적으로 "전체 목록을 배포한다"는 구조적 부담은 남는다.

규모 문제는 사고 상황에서 더욱 극명해진다. 2014년 Heartbleed 당시에는 짧은 기간에 수십만 장의 인증서가 폐기 대상이 되면서 일부 CA의 CRL이 급격히 커져, 모든 클라이언트가 매번 이를 내려받는 비용이 비현실적이라는 점이 드러났다. 이 경험은 "폐기 정보를 클라이언트가 직접, 전량 내려받는다"는 전제 자체를 재고하게 만들었고, 뒤이어 등장한 브라우저 내장형(CRLite)·서버 주도형(Stapling) 접근의 설계 동기가 되었다.

그럼에도 CRL은 최근 다시 주목받고 있다. Let's Encrypt가 2025년 8월 OCSP 서비스를 종료하고 폐기 정보를 CRL로만 제공하기로 전환한 것이 대표적이다. 대신 클라이언트가 거대한 CRL을 직접 받는 대신, 브라우저가 전 CA의 CRL을 수집·압축해 내장하는 CRLite·CRLSets 방식과 결합함으로써, CRL의 '오프라인·프라이버시' 장점을 살리면서 '크기' 단점을 보완하는 방향으로 진화하고 있다. 즉 CRL은 '배포 단위'로는 살아남고, '검증 시점의 네트워크 조회'는 사라지는 방향으로 역할이 재정의되고 있다.

나. OCSP(Online Certificate Status Protocol)

OCSP는 검증자가 인증서 한 장의 상태만 OCSP Responder에 질의하고 "good / revoked / unknown" 응답을 서명된 형태로 받는 프로토콜이다. 전체 목록을 받을 필요가 없어 전송량이 작고, CRL보다 최신 상태에 가깝게 응답할 수 있다. HTTP로 동작하며 응답에도 자체 유효기간이 있어 Responder나 중간 캐시에서 재사용된다.

그러나 OCSP에는 세 가지 구조적 약점이 있다. 첫째, 프라이버시: 클라이언트가 접속하려는 사이트의 인증서를 CA에 질의하므로, CA(또는 경로상의 관찰자)가 "누가 어떤 사이트를 방문하는지"를 알 수 있다. Let's Encrypt가 OCSP를 폐지한 핵심 이유가 바로 이 프라이버시 위험이었다. 둘째, 성능: 매 신규 접속마다 제3자인 Responder에 왕복 질의가 필요해 TLS 핸드셰이크 지연이 커진다. 셋째, 가용성·보안: Responder가 느리거나 장애일 때 소프트 실패로 인해 폐기 검증이 사실상 무력화된다. 이 세 약점을 한꺼번에 완화하려는 시도가 OCSP Stapling이다.

성능 관점을 수치로 보면 문제가 분명해진다. 제3자 Responder에 대한 OCSP 왕복이 네트워크 상태에 따라 수십~수백 밀리초가 걸리면, 이는 TLS 핸드셰이크 전체 지연에 그대로 더해진다. 전 세계 수억 사용자가 매 신규 접속마다 이 왕복을 수행하면 Responder에는 초당 막대한 질의가 몰려 가용성 확보 비용이 급증하고, 사용자 체감 응답 속도도 나빠진다. 결국 "실시간성을 위해 매번 조회한다"는 OCSP의 설계 전제가 대규모 환경에서는 오히려 성능·가용성의 병목이 된다는 역설이 드러난다.

다. OCSP Stapling

OCSP Stapling(TLS Certificate Status Request 확장)은 폐기 상태 질의의 주체를 클라이언트에서 서버로 옮기는 기법이다. 웹 서버가 자신의 인증서에 대한 OCSP 응답을 주기적으로 미리 받아 캐시해 두었다가, 클라이언트와 TLS 핸드셰이크를 할 때 인증서와 함께 그 서명된 응답을 '첨부(staple)'해 보낸다. 클라이언트는 서버 접속만으로 폐기 상태를 확인하므로 CA에 별도 질의를 하지 않는다.

이 전환은 세 약점을 동시에 개선한다. 클라이언트가 CA에 직접 질의하지 않으므로 프라이버시가 보호되고, 왕복 질의가 사라져 지연이 줄며, 서버가 하나의 응답을 수많은 클라이언트에게 재사용하므로 CA Responder의 부하가 크게 감소한다. 예컨대 OCSP 응답 유효기간이 수 일이라면, 서버는 그 기간 동안 응답을 한 번만 받아 캐시해 두고 수백만 건의 핸드셰이크에 재사용할 수 있어, CA에 대한 질의량을 사실상 '접속 수'에서 '서버 수 × 갱신 주기'로 떨어뜨린다.

다만 서버가 Stapling을 설정하지 않으면 효과가 없고, 공격자가 Stapled 응답을 '누락'시켜 다시 소프트 실패로 되돌릴 수 있다는 한계가 남는다. 또한 서버 캐시의 응답이 만료되었는데 갱신에 실패하면 오히려 신선하지 않은 응답을 제시하거나 Stapling이 끊길 수 있어, 서버 측의 안정적인 OCSP 응답 갱신 운영이 전제된다. 이러한 '누락 되돌리기' 약점을 제도적으로 막는 것이 다음의 Must-Staple이다.

라. 보완·대체 기법(Must-Staple·CRLite·단기 인증서·CT)

OCSP Must-Staple은 인증서에 "이 인증서는 반드시 Stapled OCSP 응답과 함께 제시되어야 한다"는 플래그를 넣어, 응답이 누락되면 클라이언트가 하드 실패로 연결을 차단하게 하는 확장이다. 소프트 실패의 구멍을 메우지만, 서버·CA 지원이 제한적이고 운영 난도가 높아 널리 쓰이지는 못했다.

브라우저 진영은 아예 폐기 조회를 클라이언트 내부로 끌어들였다. 크롬의 CRLSets는 구글이 중요 폐기 항목을 선별·집계해 브라우저에 푸시하는 방식이고, 파이어폭스의 CRLite는 전 CA의 폐기 정보를 블룸 필터 캐스케이드로 압축해 수 MB 수준으로 내장하는 방식이다. 둘 다 접속 시점의 네트워크 조회 없이 로컬에서 폐기를 판정하므로 프라이버시·성능·가용성을 동시에 확보한다. 다만 선별·갱신 주기에 따라 완전성·적시성에 한계가 있을 수 있다.

CRLite의 공학적 핵심은 '폐기된 것'과 '폐기되지 않은 것'을 모두 아는 상태에서, 블룸 필터를 여러 단계로 쌓아 오탐(False Positive)을 반복 제거하는 필터 캐스케이드 구조다. 이렇게 하면 수억 건의 폐기 상태를 손실 없이 수 MB로 압축하면서도, 조회 결과가 결정적(확실한 good/revoked)이 되도록 보장할 수 있다. 이는 확률적 자료구조를 '근사 판정'이 아니라 '정확 판정'에 활용한 사례로, 폐기 검증이라는 보안 문제를 자료구조·압축이라는 전산학적 접근으로 풀어낸 좋은 예다. 다만 전 CA의 신선한 폐기 정보를 모아 주기적으로 빌드·배포하는 백엔드 파이프라인이 전제되므로, 이 방식은 대규모 브라우저 벤더만이 감당할 수 있다는 현실적 제약도 함께 가진다.

가장 근본적인 흐름은 인증서 유효기간 단축이다. 유효기간이 짧으면 폐기가 아니라 '곧 만료'로 위험을 자연 해소할 수 있어 폐기 의존도가 낮아진다. CA/Browser Forum은 2025년 4월 SC-081 투표로 공개 신뢰 TLS 인증서의 최대 유효기간을 2026년 3월 200일, 2027년 3월 100일, 2029년 3월 47일로 단계적으로 줄이기로 의결했다. 이는 자동화된 인증서 관리(ACME)를 전제로 한 것으로, 폐기 검증의 무게중심을 '사후 철회'에서 '사전 만료'로 옮기는 전환을 뜻한다. 한편 인증서 투명성(CT, Certificate Transparency) 은 폐기와 별개로 오발급을 '사후 감지'하는 보완 축으로, 모든 발급 로그를 공개해 CA의 오발급을 탐지하게 한다.

4. 기법 비교와 실무 적용

세 메커니즘은 우열 관계가 아니라 적용 환경에 따른 선택지다. 비교의 핵심은 '네트워크 조회 위치', '프라이버시', '적시성', '장애 시 동작'이며, 이 차이가 곧 실무 배치의 근거가 된다. 예컨대 대규모 공개 웹 서비스는 Stapling으로 지연·프라이버시를 잡고, 폐쇄망·IoT처럼 상시 연결이 어려운 환경은 오프라인 검증이 가능한 CRL을 쓰는 식이다.

구분 CRL OCSP OCSP Stapling
조회 주체 클라이언트(전체 목록) 클라이언트(단건) 서버가 대신 수신
전송량/지연 큼(수 MB) 작음(단건, 왕복) 작음(핸드셰이크 포함)
프라이버시 양호(접속지 미노출) 취약(CA에 노출) 양호
적시성 낮음(주기 갱신) 높음 높음(응답 유효기간 내)
오프라인 검증 가능 불가 서버 캐시 의존
주 한계 크기·시차 프라이버시·가용성 서버 설정·응답 누락

실무 사례를 보면, 글로벌 CDN·대형 포털은 TLS 종단에서 OCSP Stapling을 기본 활성화해 수억 건의 핸드셰이크에서 CA 질의를 제거한다. 반대로 Let's Encrypt는 2025년 OCSP를 폐지하고 CRL+브라우저 내장 방식으로 전환했는데, 이는 "개별 질의의 프라이버시 위험을 없애고, 폐기 정보 배포는 브라우저 CRLite에 위임한다"는 설계 판단이다. 한편 금융·공공처럼 하드 실패가 요구되는 고보증 환경에서는 Must-Staple이나 전용 검증 서버를 두어 "검증 실패 시 차단"을 강제하기도 한다. 이처럼 폐기 전략은 서비스의 위험 수용 수준·연결성·규모에 따라 달라진다.

연결성이 제약되는 환경은 또 다른 선택을 강요한다. 폐쇄망·OT(운영기술)·IoT 기기는 외부 OCSP Responder에 상시 접근하기 어렵거나, 접근하더라도 지연·전력 비용이 크다. 이런 환경에서는 오프라인 검증이 가능한 CRL을 기기에 주기적으로 밀어 넣거나, 아예 사설 CA를 운영하면서 짧은 유효기간으로 폐기 의존도를 낮추는 방식이 현실적이다. 반대로 결제·인증처럼 단 한 건의 폐기 누락도 금전·법적 손실로 직결되는 거래는, 성능을 다소 희생하더라도 하드 실패와 Stapling을 결합해 '확인되지 않으면 진행하지 않는다'는 원칙을 택한다. 결국 동일한 세 메커니즘이라도 위험·연결성·비용의 조합에 따라 전혀 다른 배치로 귀결되며, 이 판단이 곧 보안 아키텍트의 설계 역량이다.

5. 심화 — 폐기 검증 패러다임의 전환

폐기 검증은 최근 몇 년 사이 세 가지 방향으로 빠르게 재편되고 있다. 첫째는 프라이버시 우선으로의 이동이다. Let's Encrypt의 OCSP 폐지(2025.08)는 "폐기 조회가 사용자의 열람 이력을 CA에 넘겨서는 안 된다"는 원칙을 전면에 세운 상징적 사건으로, 다른 CA에도 영향을 미치고 있다. 폐기 검증의 평가 기준이 '실시간성'에서 '실시간성 + 프라이버시'로 확장된 것이다.

둘째는 단기 인증서와 자동화로의 이동이다. CA/Browser Forum의 SC-081(2025.04)에 따라 유효기간이 2029년까지 47일로 줄면, 폐기에 의존해 위험을 제거하던 모델이 "짧게 발급하고 자주 교체한다"는 모델로 바뀐다. 이는 ACME 기반 자동 발급·배포·교체가 운영의 전제가 된다는 뜻이며, 수작업 인증서 관리는 사실상 불가능해진다. 폐기는 사라지지 않지만, '최후의 안전장치'로 성격이 바뀐다.

셋째는 검증 책임의 클라이언트 내재화이다. CRLite·CRLSets처럼 브라우저가 폐기 정보를 압축해 미리 내장하는 방식은, 접속 시점의 네트워크 조회 자체를 없애 성능·프라이버시·가용성 세 마리 토끼를 잡는다. 블룸 필터 캐스케이드 같은 확률적 자료구조로 수억 건의 폐기 정보를 수 MB로 압축하는 공학적 진보가 이를 뒷받침한다. 정보관리기술사 수준에서는 이 세 흐름이 "폐기라는 사후 통제를, 사전 통제(단기 발급)와 분산 통제(클라이언트 내장)로 재배치하는 과정"임을 읽어내는 것이 중요하다.

6. 고려사항 및 시사점

첫째, 실패 정책(Fail Policy)을 위험 수준에 맞게 명시적으로 설계해야 한다. 가용성이 중요한 공개 서비스는 소프트 실패가 현실적이지만, 그 자체가 보안 공백임을 인지하고 Stapling·Must-Staple·내장형 폐기로 공백을 메워야 한다. 금융·국방처럼 무결성이 최우선인 환경은 하드 실패를 택하되, 폐기 인프라의 고가용성을 함께 확보해야 한다. 실패 시 동작을 '기본값에 맡기는 것'이 가장 위험하다.

둘째, 폐기 전략은 인증서 수명주기 자동화(Certificate Lifecycle Management)와 분리될 수 없다. 47일 유효기간 시대에는 ACME 기반 자동 발급·교체·모니터링 체계 없이는 운영이 붕괴한다. 조직은 인증서 인벤토리·만료 알림·자동 갱신·장애 대응을 통합한 CLM 플랫폼을 선제적으로 갖추어, 폐기 대응과 교체 대응을 하나의 파이프라인으로 통합해야 한다.

셋째, 프라이버시와 규제 정합성을 설계 요소로 포함해야 한다. OCSP의 열람 이력 노출 문제처럼, 보안 메커니즘 자체가 개인정보 위험을 만들 수 있다. 개인정보보호 규제(GDPR·국내 개인정보보호법) 관점에서 폐기 검증 경로가 이용자 행태 정보를 제3자에 노출하지 않는지 점검하고, Stapling·클라이언트 내장 방식을 우선 검토하는 것이 바람직하다.

넷째, 폐기는 단독 통제가 아니라 PKI·관측·대응 체계의 일부로 운영해야 한다. CT 로그 모니터링으로 오발급을 조기에 탐지하고, 키 침해 시 신속 폐기·재발급이 가능한 사고 대응 절차(IR)와 연계해야 실효성이 생긴다. 장기적으로는 포스트 양자 암호(PQC) 전환과 맞물려 인증서 알고리즘 교체가 대규모 재발급·폐기를 유발할 수 있으므로, 폐기 인프라의 처리 용량과 자동화 수준을 미리 확보하는 전망적 투자가 필요하다.

다섯째, 표준·브라우저 정책 변화를 상수가 아닌 변수로 관리해야 한다. OCSP 폐지, 유효기간 47일 단축처럼 외부 생태계의 결정이 조직의 인증서 운영을 근본적으로 바꾸고 있다. 특정 CA나 특정 폐기 방식에 종속되지 않도록 멀티-CA 전략과 표준 기반 자동화(ACME)를 갖추고, CA/Browser Forum·주요 브라우저의 로드맵을 정기적으로 검토하는 거버넌스 프로세스를 운영해야 한다. 이는 기술 선택을 넘어 '신뢰 공급망(Trust Supply Chain)'의 리스크를 관리하는 기술사 수준의 전략적 과제다.

참고자료

한 줄 요약: 인증서 폐기 검증은 CRL(전체 목록)·OCSP(단건 질의)·OCSP Stapling(서버 첨부)으로 유효기간 내 신뢰 철회를 확인하는 절차이며, 프라이버시·성능·가용성의 상충 속에서 OCSP 폐지·단기 인증서·브라우저 내장형(CRLite)으로 패러다임이 전환되고 있다.