OCSP와 단기 인증서로 설계하는 인증서 상태 검증
OCSP, OCSP Stapling, SLC의 인증서 상태 검증 방식과 장단점, PKI 환경별 선택 기준을 정리한다.
2026-08-14 · 최초 발행 2025-06-15
인증서 상태 검증은 유효기간만으로 끝나지 않는다
디지털 인증 환경에서 신뢰를 유지하려면 인증서가 아직 유효한지뿐 아니라, 중간에 폐기되지 않았는지도 확인해야 한다. OCSP와 SLC는 이 문제를 서로 다른 방식으로 다룬다. 전자는 인증서 상태를 조회하고, 후자는 인증서 수명을 짧게 가져가 폐기 확인의 부담을 줄인다.
OCSP가 인증서 상태를 조회하는 방식
OCSP(Online Certificate Status Protocol)는 X.509 디지털 인증서의 상태를 실시간으로 확인하는 인터넷 프로토콜이다. 1999년 RFC 2560으로 제정됐고, 현재는 RFC 6960으로 업데이트됐다.
클라이언트의 OCSP 요청자(requester)가 상태 조회를 보내면 OCSP 응답자(responder)가 인증서 데이터베이스를 확인해 응답한다. 반환 상태는 good, revoked, unknown 중 하나다.
CRL처럼 전체 목록을 내려받지 않고 특정 인증서만 확인하므로 대역폭 측면에서 효율적이다. 폐기 정보도 실시간으로 반영할 수 있고, 상태 조회를 백그라운드에서 처리할 수 있다.
반면 OCSP 응답자는 단일 장애점(SPOF)이 될 수 있다. 응답 서버 장애 시 검증이 어려워지며, 클라이언트가 어떤 웹사이트에 접속하는지 응답자에게 노출될 가능성도 있다. 실시간 조회에 따른 지연과 안정적인 네트워크 연결 의존성도 운영 시 고려해야 한다.
Stapling으로 조회 부담을 서버로 옮기기
OCSP Stapling은 OCSP의 한계를 보완하는 TLS/SSL 확장 기술이며 RFC 6066에 정의돼 있다. 웹 서버가 OCSP 응답자에게서 인증서 상태 정보를 주기적으로 받아 캐시하고, TLS 핸드셰이크 때 인증서와 함께 전달한다.
클라이언트는 OCSP 응답자에 별도로 요청하지 않고도 상태를 확인할 수 있다.
여러 클라이언트가 하나의 OCSP 응답을 재사용하므로 서버 측 처리에 유리하다. 클라이언트가 응답자에 직접 접속하지 않아 프라이버시를 보호할 수 있고, 캐시된 응답이 있다면 OCSP 서버 장애 상황에서도 연결을 유지할 수 있다. 별도 조회가 사라져 연결 지연도 줄어든다.
짧은 수명으로 폐기 확인을 단순화하는 SLC
SLC(Short Lived Certificate)는 인증서 유효기간을 매우 짧게 설정하는 접근이다. 일반적으로 몇 시간에서 며칠, 보통 24~48시간으로 설정하며, 만료 전에 갱신하는 자동화 체계가 전제된다.
짧은 수명 덕분에 별도의 폐기 확인 절차를 줄일 수 있다. 보안 문제가 생긴 인증서는 갱신하지 않고 자연 만료되도록 처리한다.
SLC는 OCSP나 CRL을 통한 별도 폐기 확인 과정을 생략할 수 있고, 폐기 목록 관리 필요성도 낮춘다. 인증서가 노출됐을 때 피해가 지속되는 기간을 제한하며, 상태 확인을 위한 추가 통신도 필요하지 않다.
대신 갱신 인프라가 지속적이고 안정적으로 동작해야 한다. 대규모 환경에서는 빈번한 갱신 관리가 복잡해지고, 발급 요청 증가가 CA 시스템 부하로 이어질 수 있다. 자동화가 실패하면 서비스 중단 위험도 생긴다.
상태 조회와 짧은 수명의 선택 기준
| 항목 | OCSP | SLC |
|---|---|---|
| 메커니즘 | 인증서 상태 실시간 검증 | 짧은 유효기간으로 검증 필요성 감소 |
| 구현 복잡성 | 중간 (OCSP 서버 필요) | 높음 (자동 갱신 인프라 필요) |
| 네트워크 의존성 | 높음 | 낮음 (갱신 시에만 필요) |
| 실시간성 | 즉각적인 폐기 반영 | 유효기간 종료 시점까지 지연 |
| 확장성 | OCSP 서버 확장 필요 | CA 시스템 확장 필요 |
OCSP는 대부분의 주요 웹 브라우저(Chrome, Firefox, Safari 등), 금융권 보안 시스템, 정부 및 공공기관 인증 시스템, AWS Certificate Manager와 Let's Encrypt 등 주요 인증서 발급 서비스에서 적용된다.
OCSP Stapling은 Nginx, Apache 등 주요 웹 서버와 Cloudflare 같은 CDN 서비스, 대규모 전자상거래 플랫폼에서 활용된다. SLC는 AWS IoT Core의 디바이스 인증, Google BeyondCorp의 Zero Trust 구현, HashiCorp Vault의 동적 인증서 관리, DevOps 파이프라인의 임시 인증서 사용 사례와 연결된다.
Must-Staple과 하이브리드 운영
OCSP Must-Staple은 인증서에 포함되는 확장 기능이다. 해당 인증서를 사용하는 서버가 OCSP Stapling을 반드시 제공해야 함을 명시한다. 클라이언트는 Stapling이 없으면 연결을 거부하며, TLS 확장과 X.509v3 인증서 확장으로 지정된다. 브라우저와 웹 서버의 지원도 확대되고 있다.
OCSP와 SLC를 함께 쓰는 방식도 가능하다. 몇 주 정도의 유효기간을 가진 인증서에 OCSP를 적용하면 긴급 상황에서 즉각적인 폐기를 지원하면서 주기적인 갱신을 병행할 수 있다. 시스템 중요도에 따라 고위험 시스템에는 SLC를, 일반 시스템에는 OCSP를 적용하는 계층적 관리도 가능하다.
선택 전에는 네트워크 안정성과 대역폭, 보안 요구사항 수준, 시스템 규모와 분산 정도, 자동화 인프라의 성숙도를 함께 봐야 한다. 고가용성이 필요한 환경에서는 OCSP Stapling 또는 SLC를, 즉각적인 폐기가 필요한 환경에서는 OCSP를 고려할 수 있다. 오프라인 또는 간헐적 연결 환경에는 SLC가 맞고, 대규모 분산 환경에서는 하이브리드 접근법이 선택지가 된다.
어떤 방식을 택하든 인증서 수명주기 관리의 자동화와 모니터링이 운영 안정성을 좌우한다.