인증서 수명 주기와 폐기
인증서가 발급된 후 갱신되고 폐기되는 과정을 살펴보며, CRL과 OCSP가 폐기 상태를 실시간으로 전달하는 방법을 학습합니다.
인증서 수명 주기와 폐기은(는) CoddyKit의 무료 Security+ Academy 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Security+ Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
Certificate 수명 주기
모든 Digital 인증서는 생성부터 폐기까지 정의된 수명 주기를 따릅니다. 단계는 다음과 같습니다. Request and Enrollment(키 쌍 생성, CSR Create), Issuance(CA가 검증하고 서명), Deployment(Server 또는 장치에 Install), Use(활성 운영 기간), Renewal(만료 전), Revocation 또는 Expiry(수명 종료)입니다. 이 수명 주기를 대규모로 관리하려면, 특히 수천 개의 인증서를 사용하는 기업에서는 자동화 및 인증서 수명 주기 관리(CLM) 도구가 필요합니다. 수동으로 추적하면 결국 만료된 인증서로 인해 서비스 중단이 발생하기 때문입니다.
Certificate Signing Request (CSR)
인증서 수명 주기는 Certificate Signing Request (CSR)로 시작합니다. 요청자는 키 쌍을 생성한 다음 공개 키, Subject 정보(CN, O, C)를 포함하고 Private 키로 서명한 CSR을 생성합니다. 이는 Private 키를 공개하지 않고도 해당 Private 키의 소유권을 증명합니다. CSR은 CA에 제출되며, CA는 요청자의 신원을 검증하고 승인되면 인증서에 서명합니다. Private 키는 요청자의 소유를 절대 벗어나지 않습니다. CSR 생성은 키 강도가 결정되는 중요한 단계이므로 최소 2048비트 RSA 또는 256비트 ECC를 사용해야 합니다.
# Complete CSR generation workflow
# Step 1: Generate private key (RSA 2048)
openssl genrsa -out server.key 2048
# Step 2: Create CSR with all required fields
openssl req -new -key server.key -out server.csr \
-subj '/CN=www.example.com/O=Example Corp/OU=IT/C=US/ST=CA/L=San Jose'
# Step 3: Verify CSR content before submitting
openssl req -in server.csr -noout -text | grep -A5 'Subject'Certificate 갱신
인증서는 notAfter 날짜가 만료되기 전에 갱신해야 합니다. 모범 사례는 만료 최소 30일 전에 갱신 절차를 시작하는 것입니다(많은 조직은 60~90일을 목표로 합니다). 갱신에는 일반적으로 새 CSR과 Private 키를 생성하고, CA에 제출한 다음, 인증서가 배포된 모든 Server에서 기존 인증서와 키를 교체하는 과정이 포함됩니다. Let's Encrypt는 ACME 프로토콜을 사용해 이 과정을 자동화합니다. certbot 도구는 인증서의 남은 기간이 30일 미만이 되면 자동으로 갱신합니다. 만료된 인증서는 브라우저 오류를 일으켜 사용자가 서비스에 접근하지 못하게 합니다.
# Automated renewal with Certbot (Let's Encrypt)
# Install certbot and obtain a certificate
certbot --nginx -d example.com -d www.example.com
# Certbot sets up automatic renewal via cron or systemd timer
# Manual renewal test (dry run)
certbot renew --dry-run
# Check when certificates expire
certbot certificates
# Certificate Name: example.com
# Expiry Date: 2026-09-15 (VALID: 87 days)Certificate를 폐기하는 이유
Certificate 폐기는 예정된 만료일 전에 인증서를 무효화하는 과정입니다. 폐기 사유로는 다음이 있습니다. Private 키가 손상된 경우(가장 긴급하며 즉시 폐기해야 함), 인증서가 잘못 발급된 경우(잘못된 도메인 또는 조직), Subject 정보가 변경된 경우(회사 이름 변경 또는 직원 퇴사), 또는 CA 자체가 손상된 경우입니다. 폐기는 매우 중요합니다. 인증서가 폐기되었다는 사실을 모르는 브라우저와 시스템은 해당 인증서를 계속 신뢰하기 때문입니다. 이 경우 도난당한 Private 키를 가진 공격자는 인증서가 만료되거나 폐기 사실이 알려질 때까지 능동적인 MITM 기능을 사용할 수 있습니다.
Certificate Revocation Lists (CRL)
Certificate Revocation List (CRL)은 CA가 게시하는 서명된 목록으로, 아직 만료되지 않았으며 CA가 폐기한 모든 인증서의 일련 번호가 포함됩니다. Client는 CRL을 Download하여 캐시한 뒤, 제시된 인증서의 일련 번호가 목록에 있는지 확인합니다. CRL에는 상당한 한계가 있습니다. 매우 커질 수 있고(대규모 CA에는 폐기된 인증서가 수백만 개 있을 수 있음), Client가 몇 시간 또는 며칠 동안 캐시하여 지연이 발생할 수 있으며, 모든 연결마다 전체 CRL을 Download하는 것은 비효율적입니다. CRL은 여전히 사용되지만 점점 더 OCSP로 보완되거나 대체되고 있습니다.
# Download and view a CRL
# First get the CRL URL from the certificate
openssl x509 -in cert.pem -noout -text | grep -A4 'CRL Distribution'
# URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl
# Download and decode the CRL
openssl crl -inform DER -in DigiCertGlobalRootCA.crl -noout -text | head -40
# Shows: Revoked Certificates list with serial numbers and revocation datesOCSP: Online Certificate Status Protocol
OCSP (Online Certificate Status Protocol)는 Client가 전체 CRL을 Download하지 않고도 실시간으로 인증서 폐기를 확인할 수 있게 합니다. Client는 인증서의 일련 번호를 포함한 Query를 CA의 OCSP 응답자에게 보냅니다. 응답자는 인증서가 정상인지, 폐기됨인지(폐기 날짜와 사유 포함), 또는 알 수 없음인지 나타내는 서명된 Response를 반환합니다. OCSP는 CRL보다 빠르고 최신 상태를 반영하지만, 모든 TLS 연결에 OCSP 응답자와의 추가 HTTP 왕복이 필요하므로 지연 시간이 늘어납니다. OCSP Response에는 변조를 방지하기 위해 CA가 서명합니다.
# Query OCSP status manually
# Get OCSP URL from certificate
OCSP_URL=$(openssl x509 -in cert.pem -noout -ocsp_uri)
echo $OCSP_URL # http://ocsp.digicert.com
# Check certificate revocation status via OCSP
openssl ocsp -issuer intermediate_ca.pem \
-cert cert.pem \
-url $OCSP_URL \
-text -noverify
# Response: cert.pem: goodOCSP Stapling: 성능 문제 해결
OCSP Stapling은 실시간 OCSP 확인에서 발생하는 지연 문제를 해결합니다. 각 TLS 핸드셰이크 중에 클라이언트가 CA의 OCSP 응답자에게 질의하는 대신, 서버가 CA에서 자체 OCSP 응답을 미리 가져와 TLS 핸드셰이크에 '스테이플링'(첨부)합니다. 클라이언트는 추가 왕복 통신 없이 서버로부터 최신 상태이며 CA가 서명한 OCSP 응답을 직접 받습니다. 서버는 스테이플링한 OCSP 응답을 주기적으로(일반적으로 매시간) 갱신합니다. OCSP Stapling은 연결 속도를 높이고 CA의 OCSP 응답자 부하를 줄이면서 인증서 폐기 확인을 유지합니다.
# Enable OCSP Stapling in nginx
# In your server block:
# ssl_stapling on;
# ssl_stapling_verify on;
# ssl_trusted_certificate /path/to/chain.pem;
# resolver 8.8.8.8 8.8.4.4 valid=300s;
# Verify OCSP Stapling is working
openssl s_client -connect example.com:443 -status 2>/dev/null | \
grep -A 20 'OCSP Response Status'
# OCSP Response Status: successful (0x0)
# Cert Status: GoodOCSP Must-Staple 확장
OCSP Must-Staple은 서버가 스테이플링된 OCSP 응답을 반드시 제공해야 한다는 사실을 브라우저에 알리는 X.509 확장입니다. 이 확장이 없으면 OCSP 확인에 실패할 때 브라우저는 '소프트 실패'를 수행합니다. 즉, OCSP 응답자 장애로 인해 모든 TLS 연결이 차단되는 것을 막기 위해 연결을 허용합니다. 공격자는 클라이언트의 OCSP 요청을 차단하여 소프트 실패 동작을 악용할 수 있으며, 그러면 인증서가 폐기된 후에도 여전히 유효한 것처럼 보이게 됩니다. OCSP Must-Staple은 유효한 스테이플링 응답을 요구하여 이를 방지하며, 응답이 없으면 브라우저가 연결을 거부합니다. 다만 배포가 복잡하기 때문에 도입은 여전히 제한적입니다.
인증서 고정과 폐기 비교
인증서 폐기와 인증서 고정은 모두 사기성 인증서를 신뢰하는 문제를 다루지만, 서로 다른 방식으로 접근합니다. 폐기(CRL/OCSP)는 문제가 발견된 후 CA가 인증서를 무효화하는 사후 대응 메커니즘입니다. 고정은 사전 승인된 인증서가 아니면 애플리케이션이 모두 거부하는 사전 예방 메커니즘입니다. 고정은 CA가 즉시 폐기하지 못하더라도 작동하므로 폐기보다 더 강력한 보장을 제공하지만, 배포의 유연성이 떨어집니다. Security+ 시험에서는 두 메커니즘을 모두 알고, 폐기는 표준 PKI 메커니즘인 반면 고정은 선택적으로 적용하는 심층 방어 수단이라는 점을 이해해야 합니다.
인증서 고정과 폐기 요약
인증서가 폐기되면 CA는 클라이언트와 관리자가 폐기 사유를 이해하는 데 도움이 되는 폐기 사유 코드를 할당합니다. RFC 5280에 정의된 일반적인 사유 코드는 다음과 같습니다: keyCompromise(개인 키가 유출됨), cACompromise(발급 CA가 침해됨), affiliationChanged(주체의 조직이 변경됨), superseded(대체용 새 인증서가 발급됨), cessationOfOperation(도메인이 더 이상 활성 상태가 아님), privilegeWithdrawn(권한이 철회됨). 사유 코드는 CRL 항목과 OCSP 응답 모두에 나타나므로, 폐기 사건을 조사하는 사고 대응 팀에 맥락을 제공합니다.
자동화된 인증서 관리: ACME
Let's Encrypt에서 사용하는 ACME (Automatic Certificate Management Environment) Protocol은 인증서 수명 주기 전체를 자동화합니다. ACME 클라이언트(예: certbot)는 사람의 개입 없이 인증서를 자동으로 요청하고, 갱신하고, 배포합니다. CA는 도메인 확인 challenge를 사용하여 도메인 소유권을 확인합니다. HTTP-01 challenge에서는 특정 URL에 특정 file을 배치해야 하고, DNS-01 challenge에서는 DNS TXT 레코드를 생성해야 합니다. ACME는 인증서 관리를 크게 변화시켰습니다. 이제 Let's Encrypt의 90일 인증서가 인터넷 HTTPS 트래픽의 상당 부분을 지원하며, 이 인증서들은 모두 자동으로 갱신됩니다.
# ACME/certbot lifecycle
# Initial certificate issuance (HTTP challenge)
certbot certonly --webroot -w /var/www/html \
-d example.com -d www.example.com
# Or DNS challenge (for wildcard certs)
certbot certonly --dns-route53 \
-d '*.example.com' -d example.com
# Automatic renewal via cron (certbot installs this)
# 0 12 * * * root certbot renew --quiet빠른 확인
이 lesson에서 다룬 CompTIA Security+ (SY0-701) 개념을 얼마나 이해했는지 확인해 보십시오.
lesson 요약
이 lesson에서는 다음을 배웠습니다. 인증서 수명 주기는 CSR generation에서 시작하여 발급, 배포, renewal 또는 revocation으로 이어집니다. CRL은 일괄 폐기 목록을 제공하고 OCSP는 인증서별 실시간 상태를 제공합니다. OCSP Stapling은 실시간 OCSP의 지연을 제거합니다. 또한 ACME (Let's Encrypt)는 전체 갱신 수명 주기를 자동화합니다. 다음에는 PKI Use Cases를 살펴보겠습니다.
자주 묻는 질문
“인증서 수명 주기와 폐기” 강의는 무료인가요?
네 — “인증서 수명 주기와 폐기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Security+ Academy 강의 전체를 잠금 해제할 수 있습니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“인증서 수명 주기와 폐기”에서 뭘 배우나요?
인증서가 발급된 후 갱신되고 폐기되는 과정을 살펴보며, CRL과 OCSP가 폐기 상태를 실시간으로 전달하는 방법을 학습합니다. 브라우저에서 직접 실행하는 실습 코드로 Security+ Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Security+ Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Security+ Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.
“인증서 수명 주기와 폐기” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Security+ Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Security+ Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.