본문으로 건너뛰기

인증서 수명주기 — 발급·갱신·폐기

인증서는 발급으로 끝이 아니라 발급 → 사용 → 갱신 → (필요 시) 폐기의 수명주기를 가집니다.

I. 발급​

키쌍 생성(개인키 보관) → CSR 작성 → CA에 제출
→ CA가 신원·도메인 소유 검증(DV/OV/EV) → 서명·발급 → 설치(풀체인)

도메인 소유 검증(DCV)은 보통 HTTP(파일 업로드)·DNS(TXT 레코드)·이메일 방식으로 "이 도메인을 당신이 통제한다"를 확인합니다.

II. 유효기간과 갱신 — 짧아지는 추세 ⭐​

과거 수년이던 인증서 수명이 꾸준히 짧아지고 있습니다. CA/Browser Forum이 2025년 4월 단계적 축소를 승인했습니다.

시점최대 유효기간도메인검증(DCV) 재사용
~2026-03-14398일—
2026-03-15200일200일
2027-03-15100일100일
2029-03-1547일10일

:::info 지금은? 오늘(2026년) 기준 이미 최대 200일 구간입니다. 수명이 짧아지는 이유는 ① 폐기 메커니즘의 약점 보완(짧으면 폐기 지연 피해가 작음) ② 알고리즘·키 교체 가속 ③ 오래된/방치 인증서 축소입니다. :::

결론: 갱신은 자동화가 필수가 되었습니다. 47일 주기를 수작업으로 감당할 수 없습니다.

ACME와 자동 갱신​

ACME(Automated Certificate Management Environment)는 발급·갱신을 자동화하는 프로토콜입니다. Let's Encrypt가 대표적(무료, 90일 유효, 자동 갱신 전제).

ACME 클라이언트(certbot 등)
  → 도메인 소유 자동 증명(HTTP-01 / DNS-01)
  → 인증서 자동 발급·설치·갱신(주기적으로 만료 전 재발급)
  • 보통 만료 1/3 지점(90일 중 60일 무렵)에 자동 갱신
  • HTTPS 무료 구현의 핵심

III. 폐기 (Revocation)​

유효기간이 남았어도 개인키 유출·오발급·도메인 소유 변경 시 인증서를 무효화해야 합니다.

방식설명한계
CRL (폐기목록)CA가 폐기된 일련번호 목록을 게시목록이 커지고 갱신 지연
OCSP인증서 하나의 폐기 여부를 실시간 질의프라이버시·지연·CA 부하
OCSP Stapling서버가 OCSP 응답을 미리 받아 핸드셰이크에 첨부클라이언트가 CA에 직접 안 물어봐도 됨(권장)
CRLite / 집계 방식브라우저가 폐기정보를 압축 배포브라우저별 구현
OCSP Stapling 흐름:
서버 ─(주기적)→ CA에 OCSP 질의 → 서명된 "유효" 응답 수신
클라이언트 ← 서버가 TLS 핸드셰이크에 그 응답을 '스테이플'로 첨부
→ 클라이언트는 CA에 직접 안 물어도 폐기 여부 확인(빠르고 프라이버시 ↑)

:::caution 폐기의 현실 OCSP/CRL은 지연·가용성 문제로 완벽하지 않습니다. 그래서 업계는 "짧은 유효기간"으로 폐기 의존도를 낮추는 방향으로 갑니다(위 II의 수명 단축과 같은 맥락). 실제로 OCSP를 단계적으로 폐지하려는 움직임도 있습니다. :::

IV. Certificate Transparency (CT)​

CA의 오발급·부정발급을 감시하기 위해, 발급된 인증서를 공개 CT 로그에 기록하도록 요구합니다.

  • 브라우저는 CT 로그에 등재된 증거(SCT)가 있는 인증서만 신뢰(크롬 등)
  • 도메인 소유자는 CT 로그(crt.sh 등)를 모니터링해 자기 도메인에 대한 미승인 발급을 탐지 가능

V. 갱신 실무 전략​

항목권장
자동화ACME(certbot/acme.sh) 또는 관리형(클라우드 LB·CDN)
모니터링만료 임박 알림(아래 06), CT 로그 감시
여유만료 상당 전 갱신(최소 1/3 지점)
키 관리갱신 시 키 교체 정책 결정(재사용 vs 신규)

VI. 결론​

인증서는 발급→갱신→폐기의 수명주기를 가지며, 수명 단축(200→100→47일) 추세로 자동 갱신(ACME) 이 사실상 필수가 되었습니다. 폐기는 CRL·OCSP·OCSP Stapling로, 오발급 감시는 CT 로그로 보완합니다.