수동 갱신을 끝내야 하는 시점은 인증서가 몇 장인지로 결정되지 않는다.
인증서 한 장이라도 만료되면 생산 서비스가 중단되고 발급·검증·배포 과정에 사람이 개입해야 하며 새 인증서가 실제 서비스에 적용됐는지 독립적으로 확인할 수 없다면 이미 수동 갱신을 기본 경로에서 제거해야 한다.
2026년 8월 27일 현재 공개 신뢰 TLS 서버 인증서는 200일 단계에 들어와 있다. 현행 CA/Browser Forum Baseline Requirements에는 2027년 3월 15일부터 100일, 2029년 3월 15일부터 47일로 줄이는 일정이 포함돼 있다. 다만 뒤의 두 단계는 아직 시행 전이며 CA/B Forum은 필요하면 향후 일정을 변경할 수 있도록 여지를 남겼다. 미래 일정을 이미 확정된 운영 사실처럼 취급해서는 안 된다.
인증서 수명이 짧아질수록 운영자가 해결해야 할 문제는 갱신 버튼을 더 자주 누르는 것이 아니다. 어떤 인증서가 어디에서 사용되는지 알고 발급과 Domain Validation을 자동화하고 개인키를 적절한 경계 안에 보관하며 모든 TLS 종료 지점에 배포한 뒤 실제 서비스가 새 인증서를 제공하는지 확인해야 한다. 실패하면 안전하게 이전 상태로 돌아가거나 새 인증서로 복구할 수 있어야 한다.
이 전체 흐름이 Certificate Lifecycle Management다.
2026년 8월 현재 어디까지 시행됐나
CA/Browser Forum의 최신 Baseline Requirements는 v2.2.9이며 2026년 8월 6일 효력이 발생했다. 현재 일정은 다음과 같다.
| 인증서 발급 시점 | 공개 TLS 인증서 최대 유효기간 | Domain·IP 검증 정보 최대 재사용 기간 | 2026년 8월 27일 상태 |
|---|---|---|---|
| 2026년 3월 15일 이전 | 398일 | 398일 | 과거 단계 |
| 2026년 3월 15일 이상, 2027년 3월 15일 미만 | 200일 | 200일 | 현재 시행 중 |
| 2027년 3월 15일 이상, 2029년 3월 15일 미만 | 100일 | 100일 | 현행 BR의 예정 단계 |
| 2029년 3월 15일 이상 | 47일 | 10일 | 현행 BR의 예정 단계 |
200일, 100일, 47일은 최대값이다. CA/B Forum은 하루를 86,400초로 계산하며 미세한 시간 초과까지 다음 날로 취급할 수 있으므로, 기본 발급 기간은 각각 199일, 99일, 46일을 넘지 않도록 권고하는 구조다. 실제로 DigiCert와 Sectigo는 2026년 3월 시행에 앞서 또는 맞춰 현재 최대 발급 기간을 199일로 전환했다.
이 표가 모든 사설 인증서에 직접 적용되는 것은 아니다. Baseline Requirements는 인터넷을 통해 접근 가능한 서버를 인증하는 공개 신뢰 TLS 인증서를 대상으로 하며 기업이 내부 전용 Root CA로 운영하는 Private PKI는 직접적인 적용 범위 밖에 있다. 내부 인증서도 더 짧은 수명과 자동화를 채택할 수 있지만 그것은 조직이 별도로 결정해야 할 정책이다.
정책은 이미 구현 단계에 들어갔다
이 변화는 먼 미래의 논의에 머물러 있지 않다.
Chromium의 현재 인증서 검증 코드에는 2026년 200일, 2027년 100일, 2029년 47일 제한이 발급일 기준으로 반영돼 있다. Mozilla Root Store Policy도 포함 CA가 현행 CA/B Forum Baseline Requirements를 준수하도록 요구한다.
Chrome Root Program은 2027년 3월 15일부터 신뢰 체계에 포함된 각 TLS 인증서 프로필이 자동 발급·갱신 수단을 지원하도록 요구한다. ACME를 지원한다면 RFC 8555의 주요 작업뿐 아니라 RFC 9773의 ACME Renewal Information도 지원해야 한다. 이 요구는 CA 측 자동화 능력에 관한 것이며 웹사이트 운영자가 반드시 특정 ACME Client를 사용해야 한다는 뜻은 아니다. Chrome 디벨로퍼
CA별 실제 발급 기간도 이미 다르다. DigiCert와 Sectigo는 현재 최대 199일을 적용하지만 Let’s Encrypt의 기본 프로필은 여전히 90일이다. 일부 CA에서는 1년 상품이나 구독 계약을 구매하더라도 그 기간 동안 199일 이하의 개별 인증서를 재발급받는 구조가 사용된다. 구매 기간과 실제 인증서의 notBefore–notAfter 유효기간은 같은 값이 아니다. Sectigo® Official
수동 갱신을 끝내는 기준은 인증서 개수가 아니다
인증서가 열 장이면 자동화하고 한 장이면 수동으로 관리해도 된다는 기준은 안전하지 않다. 한 장뿐이어도 결제 API, 관리자 페이지, 공개 웹사이트 또는 고객 연동 Endpoint를 중단시킬 수 있다면 운영 위험은 크다.
수동 갱신을 기본 경로에서 제거해야 하는 신호는 다음과 같다.
| 현재 상태 | 발생 가능한 문제 | 기본 판단 |
|---|---|---|
| 생산 트래픽을 처리하는 인증서다 | 담당자의 부재나 작업 누락이 곧 서비스 중단으로 이어짐 | 정기 발급·갱신 자동화 |
| CDN, Load Balancer, Ingress, 여러 서버 등 배포 대상이 둘 이상이다 | 일부 지점만 이전 인증서를 계속 제공하는 부분 배포 발생 | 배포와 대상별 확인 자동화 |
| DNS·보안·인프라 등 둘 이상의 팀을 거쳐야 한다 | 승인·작업 대기 시간이 인증서 잔여기간을 소모함 | Workflow와 책임 경계 자동화 |
| DNS TXT Record를 사람이 직접 입력한다 | 휴가·야간·변경 동결 기간에 갱신이 멈춤 | DNS API 또는 전용 검증 구조 |
| 새 인증서를 내려받은 뒤 파일을 직접 복사한다 | 개인키 유출, 잘못된 Chain, 대상 누락 가능성 | Secret 배포 경로와 원자적 전환 |
| CA Portal이나 로컬 파일의 만료일만 본다 | 실제 Load Balancer·CDN이 옛 인증서를 제공해도 발견하지 못함 | 외부에서 실제 제공 인증서 확인 |
| 갱신 실패 시 이전 인증서를 다시 올리는 것 외에 계획이 없다 | 이전 인증서가 만료·폐기·유출된 경우 Rollback 불가능 | Rollback과 Emergency Issuance 분리 |
사람이 개입하는 것 자체가 문제는 아니다. 사람은 인증서 정책, 도메인 승인, 예외, 보안 사고와 긴급 복구를 책임져야 한다. 제거해야 하는 것은 일상적인 발급과 갱신이 특정 담당자의 달력, 이메일, 기억과 수작업 순서에 의존하는 상태다.
수동 갱신은 다음 조건을 모두 충족하는 경우에만 임시 예외로 남길 수 있다.
생산 서비스 중단 위험이 낮다.
사용 Endpoint와 배포 대상이 하나로 명확하다.
주 담당자와 대체 담당자가 모두 정해져 있다.
실제 서비스 인증서를 확인하는 독립된 만료 경보가 있다.
충분한 재시도 기간과 검증 시간이 확보돼 있다.
교체·폐기·긴급 재발급 절차를 실행해 본 적이 있다.
예외 종료일과 자동화 전환 책임자가 기록돼 있다.
이 중 하나라도 충족하지 못한다면 수동 갱신은 장기 운영 모델이 아니라 아직 해결되지 않은 운영 부채다.
ACME를 도입하면 Lifecycle 자동화가 끝나는가
ACME(Automatic Certificate Management Environment)는 인증서 관리를 자동화하는 공개 표준이다. RFC 8555는 계정 생성, 인증서 주문, Domain Control 증명, CSR 제출, 발급 인증서 다운로드와 폐기 요청을 위한 프로토콜을 정의한다. 일반적인 DV 인증서는 사람의 별도 개입 없이 요청·검증·발급을 온라인으로 처리할 수 있다.
그러나 ACME 연결만으로 Certificate Lifecycle이 완성되는 것은 아니다.
Certificate Inventory
↓ 발급 정책·Owner ↓ ACME Order ↓ HTTP-01 또는 DNS-01 Challenge ↓ Key·CSR 생성 ↓ Certificate Issuance ↓ 인증서·Chain 사전 검증 ↓ 모든 TLS 종료 지점에 Distribution ↓ 실제 서비스 인증서 Live Verification ↓ Renewal·Expiry Monitoring ↓ Rotation·Rollback·Revocation·Emergency Issuance ↓ Retirement와 Audit
ACME는 이 흐름의 발급 거래를 표준화한다. 하지만 조직이 어떤 인증서를 보유하는지, 누가 책임지는지, 새 인증서를 어느 Load Balancer와 CDN에 배포해야 하는지, 배포가 부분적으로 실패했는지, 이전 인증서를 다시 사용할 수 있는지까지 자동으로 판단하지는 않는다.
따라서 목표는 “ACME Client를 설치했다”가 아니라 다음 상태여야 한다.
인증서가 갱신 대상에 들어오면 발급·검증·배포·실서비스 확인이 자동으로 진행되고 실패 상태가 Owner에게 전달되며 안전한 재시도 또는 복구 행동으로 연결된다.
HTTP-01과 DNS-01 중 무엇을 선택해야 할까
두 Challenge는 어느 쪽이 더 현대적인가로 선택하지 않는다. Domain Control을 어디에서 안전하고 반복 가능하게 증명할 수 있는지가 기준이다.
| 구분 | HTTP-01 | DNS-01 |
|---|---|---|
| 검증 방법 | /.well-known/acme-challenge/ 경로에 Token 응답 제공 | _acme-challenge 아래 TXT Record 제공 |
| 필요한 권한 | 대상 웹 Endpoint의 HTTP 경로 제어 | 해당 DNS Record를 변경할 권한 |
| Network 조건 | CA가 80번 Port로 접근 가능해야 함 | Authoritative DNS에 TXT가 전파돼야 함 |
| Wildcard 인증서 | 지원하지 않음 | 지원 |
| 다중 Frontend | 모든 검증 대상 Frontend가 같은 응답을 제공하거나 중앙 검증 경로가 필요 | 웹 Frontend와 분리해 검증 가능 |
| 비공개 Web Endpoint | 일반적으로 부적합 | DNS가 공개적으로 검증 가능하면 사용 가능 |
| 대표 위험 | Port 80 차단, 잘못된 Redirect, 일부 Frontend에서 Challenge 응답 누락 | 광범위한 DNS API Credential, TXT 전파 지연, 오래된 Record 미정리 |
| 잘 맞는 환경 | 단순한 공개 Web Server, 중앙 Ingress, 자동 HTTP Route 제어 | Wildcard, 많은 Frontend, 비공개 Origin, 인증서 발급과 Web Runtime을 분리해야 하는 환경 |
RFC 8555의 HTTP-01은 정해진 Challenge 경로에 Account Key와 연결된 값을 제공하는 방식이다. 실제 구현에서는 80번 Port 접근, Redirect, IPv4·IPv6 주소, 여러 Frontend의 일관성이 영향을 준다. Let’s Encrypt의 공식 구현 문서도 HTTP-01이 Wildcard를 지원하지 않고 여러 Web Server를 사용한다면 Challenge 파일을 모든 대상에 제공해야 한다고 설명한다.
DNS-01은 Wildcard와 비공개 Web Endpoint에 사용할 수 있지만 DNS 권한이 새로운 고위험 Secret이 된다. Web Server에 Zone 전체를 변경할 수 있는 DNS API Credential을 넣으면 해당 서버가 침해됐을 때 피해 범위가 크게 넓어진다. 가능한 경우 _acme-challenge 전용 Zone을 CNAME이나 NS로 위임하고 해당 Record만 변경할 수 있는 Credential이나 별도 검증 서버를 사용해야 한다. DNS 전파 시간도 Renewal Window에 포함해야 한다.
사람이 Portal에 로그인해 TXT Record를 직접 추가하는 DNS-01은 프로토콜만 ACME일 뿐 운영은 여전히 수동이다. 생산 인증서의 정기 갱신 경로로 사용한다면 DNS API, 전용 위임 영역 또는 별도 Validation Service 가운데 하나로 반복 작업을 제거해야 한다.
인증서 개인키와 자동화 Credential은 서로 다른 Secret이다
인증서 자동화에서는 다음 네 가지를 구분해야 한다.
| Secret | 가능하게 하는 행동 | 권장 경계 |
|---|---|---|
| ACME Account Key·Credential | 인증서 주문, Authorization 관리, 구현에 따라 폐기 요청 | 허용 CA·Account·도메인 범위를 제한하고 자동화 시스템에서 보호 |
| Certificate Private Key | 해당 Endpoint의 신원을 증명하고 TLS 연결을 종료 | 실제 TLS 종료 지점 또는 승인된 중앙 Key 관리 경계 |
| DNS API Credential | ACME TXT Record를 포함한 DNS 변경 | _acme-challenge 전용 최소 권한, 가능하면 전용 Zone |
| Deployment Credential | Load Balancer, CDN, Secret Store, Appliance 등에 인증서·키 배포 | 배포 대상과 작업 범위를 제한하고 감사 기록 유지 |
RFC 8555에서 ACME Client는 Account Key로 서버에 보내는 요청을 서명한다. 인증서 발급 단계에서는 별도의 CSR을 제출한다. Let’s Encrypt도 Account Key를 Certificate Key로 재사용할 수 없다고 명시한다.
인증서 개인키를 어느 위치에서 생성할지는 TLS 종료 구조와 보안 요구에 따라 달라진다.
TLS 종료 지점에서 생성하고 외부로 내보내지 않을 수 있다.
중앙 Secret Management 또는 HSM·KMS 경계에서 생성해 승인된 대상으로만 전달할 수 있다.
CDN이나 관리형 Load Balancer가 Key를 관리하는 모델을 사용할 수도 있다.
어느 방식이든 “개인키가 어디에 있고 누가 읽거나 교체할 수 있는가”가 Inventory에 기록돼야 한다. HSM이 모든 환경의 정답은 아니지만 Ticket·메신저·공유 폴더·일반 CI Log를 통한 Key 전달은 정상 배포 경로가 되어서는 안 된다.
Certificate Inventory에 무엇을 기록해야 할까
Certificate Inventory는 만료일 목록이 아니다. 인증서와 서비스, Key, 검증 권한, 배포 대상, 복구 경로를 연결하는 운영 원장이어야 한다.
| 필드 | 기록해야 할 내용 |
|---|---|
| Certificate ID | 변경되지 않는 내부 식별자 |
| Service·Environment | 어떤 서비스의 Production·Staging·Development 인증서인지 |
| Names | FQDN, SAN 목록, Wildcard 여부 |
| TLS Termination Point | CDN, Load Balancer, Ingress, Reverse Proxy, Web Server, Appliance |
| Exposure | 공개 인터넷, Partner 전용, 내부 Private PKI |
| CA·Account·Profile | 발급 CA, ACME Account, 인증서 Profile, 상품·구독과의 관계 |
| Current Certificate | Serial, Fingerprint, notBefore, notAfter, Issuer, Chain |
| Key Boundary | 생성 위치, 보관 위치, Export 가능 여부, Key Version |
| Challenge | HTTP-01·DNS-01, Validation Endpoint, DNS Zone, Credential Reference |
| Owner | 최종 책임자와 대체 담당자 |
| Distribution Targets | 인증서와 Key가 적용돼야 할 모든 Endpoint·Region·Cluster |
| Renewal Policy | ARI 사용 여부, Renewal Start, Escalation, Last Safe Deployment |
| Monitoring | 실제 제공 인증서 확인 위치와 Alert Owner |
| Rollback | 이전 정상 인증서·Chain의 보존 위치와 사용 종료 조건 |
| Revocation | 폐기 권한, 접수 경로, 사고 시 승인자 |
| Emergency Issuance | 긴급 Account·Credential·배포 경로, 실행 책임자 |
| Lifecycle State | Planned, Active, Renewing, Failed, Revoked, Retired |
| Evidence | 마지막 성공 발급·배포·외부 검증 시각과 작업 기록 |
CA Portal에서 검색되는 인증서만 Inventory에 넣으면 누락이 생긴다. 관리형 CDN이 자동 발급한 인증서, Cloud Load Balancer가 관리하는 인증서, 과거 Appliance에 남은 인증서, 사용하지 않는 Legacy Hostname의 인증서도 실제 트래픽이나 신뢰 관계에 남아 있다면 관리 대상이다.
Certificate Lifecycle Runbook
아래 Runbook은 특정 CA 제품의 조작 절차가 아니다. 공개 TLS 인증서의 반복 가능한 운영 계약이다.
| 단계 | 표준 작업 | 완료 Evidence | 실패 시 행동 |
|---|---|---|---|
| 1. Scope 등록 | 새 Domain·Endpoint·서비스를 배포하기 전에 Certificate ID를 만들고 공개 TLS인지 Private PKI인지 분류한다. | Inventory Record, Service·Environment·Names·Exposure | 등록되지 않은 인증서는 발급·배포 Gate를 통과시키지 않는다. |
| 2. Owner 지정 | Service Owner, Certificate Automation Owner, DNS Owner와 대체 담당자를 정한다. 최종 책임자는 한 명으로 명확히 둔다. | Owner·Backup Owner, On-call·Escalation 경로 | Owner가 없거나 퇴사·이동으로 비어 있으면 갱신 예외가 아니라 운영 위험으로 경보한다. |
| 3. Issuance Policy 결정 | 허용 CA, Account, 인증서 Profile, SAN 범위, Wildcard 사용 여부, Key Algorithm과 Key 재사용 정책을 정한다. | 승인된 Policy ID와 변경 기록 | Policy를 벗어난 발급은 배포하지 않고 원인을 검토한다. |
| 4. Challenge 설계 | HTTP-01 또는 DNS-01을 선택하고 Network·DNS 전파·Wildcard·다중 Frontend 조건을 확인한다. | Challenge Test, 필요한 Route·DNS 권한 확인 | HTTP Route·DNS API가 불안정하면 수동 작업으로 우회하지 말고 전용 Validation 경로를 복구한다. |
| 5. Credential 경계 구성 | ACME Account Key, Certificate Private Key, DNS Token과 Deployment Credential을 분리한다. | Secret Reference, Scope, 접근 정책, Rotation 기록 | Credential 노출이 의심되면 해당 Credential을 폐기·교체하고 영향받은 발급 범위를 조사한다. |
| 6. Key·CSR 생성 | 승인된 위치에서 Key를 생성하고 정확한 SAN·Algorithm을 담은 CSR을 만든다. | Key Version, CSR Digest, 요청 Domain 목록 | Key 생성·CSR 검증 실패 시 발급을 중단한다. 임시 Key 파일을 공유 경로로 옮기지 않는다. |
| 7. Issuance 실행 | ACME 또는 승인된 자동화 API로 Order·Authorization·Finalize를 수행한다. Retry는 무한 반복하지 않고 Backoff와 마감 시각을 적용한다. | Order ID, Authorization 결과, 발급 Serial | Rate Limit·CAA·DNS·권한 오류를 구분하고 Owner에게 전달한다. Last Safe Deployment 전에 해결되지 않으면 Incident 단계로 전환한다. |
| 8. 발급 산출물 검증 | SAN, 유효기간, Issuer, Chain, Key–Certificate 일치, 허용 Algorithm과 Policy를 검사한다. | Pre-deployment Validation PASS | 잘못 발급된 인증서는 배포하지 않는다. 필요한 경우 재발급하고 오발급 인증서의 폐기 여부를 판단한다. |
| 9. Distribution | Versioned Artifact 또는 Secret Version으로 모든 CDN·LB·Ingress·Server·Region에 배포한다. | 대상별 Deployment Acknowledgement와 Version | 일부 대상 실패 시 전체 성공으로 기록하지 않는다. 확장을 중단하고 실패 대상과 트래픽 경로를 분리한다. |
| 10. Activation·Live Verification | 제한된 대상에서 활성화한 뒤 SNI를 포함한 실제 TLS 연결로 Serial·Fingerprint·Chain·Expiry를 확인한다. IPv4·IPv6와 주요 Region을 구분한다. | 외부 Live Probe 결과와 기대 Fingerprint 일치 | 새 인증서가 잘못 제공되면 Traffic 확대를 중단한다. 이전 인증서가 안전하면 되돌리고 그렇지 않으면 Forward Recovery한다. |
| 11. Renewal Window 운영 | ARI가 지원되면 권장 구간을 사용한다. 그렇지 않으면 자체 Lead Time으로 Renewal Start·Escalation·Last Safe Deployment를 계산한다. | 다음 갱신 구간과 Job Schedule | 첫 실패부터 만료 경보를 기다리지 않는다. Retry Budget과 남은 안전 시간을 함께 경보한다. |
| 12. Rotation 완료 | 새 인증서가 모든 대상에서 제공되는 것을 확인한 후 이전 인증서·Key의 사용 종료 시각을 기록한다. | Fleet 전체 의도된 Serial 제공, 이전 Version 비활성 | 일부 Endpoint가 이전 Serial을 계속 제공하면 부분 배포 Incident로 처리한다. |
| 13. Rollback·Forward Recovery | 이전 인증서가 아직 유효하고 폐기·유출되지 않았으며 현재 Domain·Chain에 적합할 때만 제한적으로 Rollback한다. | Rollback 조건 확인, 외부 재검증 | 이전 Key가 유출됐거나 인증서가 폐기됐다면 Rollback하지 않고 새 Key·인증서로 Forward Recovery한다. |
| 14. Revocation | Key 유출, 무단 발급, 잘못된 이름·정보, 더 이상 신뢰할 수 없는 인증서에 대해 승인된 경로로 폐기를 요청한다. | Revocation Request, CA 결과, Inventory 상태 변경 | ACME revokeCert 또는 CA의 비상 경로가 실패하면 Security Incident로 격상하고 CA 지원·대체 신뢰 경로를 사용한다. |
| 15. Emergency Issuance | 평상시 경로와 분리된 긴급 권한·Account·연락망으로 새 Key와 인증서를 발급하고 제한 배포 후 외부 검증한다. | Emergency Record, 신규 Serial, 영향 Endpoint 확인 | 긴급 경로 자체가 작동하지 않으면 Traffic 격리·점검된 대체 Endpoint·사전 검증된 발급 경로를 사용한다. |
| 16. Retirement | Domain·Service 폐기 시 인증서, Key, DNS Challenge 위임, ACME Authorization과 배포 Secret을 함께 제거한다. | Decommission Evidence, Inventory Retired | DNS·Legacy Endpoint가 남아 있으면 폐기 완료로 처리하지 않는다. |
| 17. 정기 Audit | Inventory와 실제 DNS·Endpoint·Certificate Transparency·Cloud 자산을 대조해 미등록 인증서와 Owner 공백을 찾는다. | Reconciliation 결과, 예외 목록과 기한 | Unknown 인증서는 서비스·소유자·발급 경로를 확인할 때까지 보안 검토 대상으로 둔다. |
갱신 시점을 만료 N일 전 하나로 고정하지 말아야 하는 이유
인증서마다 유효기간과 운영 Lead Time이 다르다. 199일 인증서와 90일 인증서, 45일 인증서에 같은 “30일 전 갱신” 규칙을 적용하면 너무 늦거나 불필요하게 일찍 갱신될 수 있다.
RFC 9773의 ACME Renewal Information은 CA가 인증서별 권장 갱신 구간을 Client에 제공할 수 있도록 한다. CA의 부하 분산뿐 아니라 대규모 폐기나 조기 교체가 필요한 상황에서 평소보다 이른 갱신을 안내하는 데도 사용할 수 있다. 지원되는 CA와 Client 조합이라면 고정 Cron 날짜보다 ARI를 우선하는 편이 낫다.
ARI를 사용할 수 없다면 다음 값을 조직이 직접 계산해야 한다.
마지막 안전 배포 시각
= notAfter
- 최대 Domain Validation 지연
- 승인·변경 대기 시간
- 모든 대상 배포 시간
- 실패 재시도 예산
- 변경 동결·휴일 보정
- Incident 대응 버퍼이를 기준으로 세 개의 시점을 둔다.
Renewal Start: 정상 자동 갱신을 시작하는 시점
Escalation Deadline: 자동 재시도가 계속 실패할 때 사람에게 즉시 전달하는 시점
Last Safe Deployment: 정상 변경 절차로 갱신할 수 있는 마지막 시점
notAfter는 갱신 마감일이 아니다. 그 시각은 서비스 실패가 시작되는 시각이다.
Let’s Encrypt는 현재 ARI 조회를 우선하도록 안내하고 ARI를 사용할 수 없을 때 자체 인증서에 대한 보조 기준으로 전체 수명의 일정 비율이 남았을 때 갱신하도록 권고한다. 이는 Let’s Encrypt 운영 지침이지 모든 CA에 적용되는 보편적인 30일 규칙은 아니다.
대량 인증서는 같은 시각에 일괄 갱신하지 않는다. 발급 시간과 갱신 Job을 분산하고 실패가 전체 인증서 Fleet으로 동시에 확산되지 않도록 Batch를 나눈다.
발급 성공과 배포 성공은 다른 상태다
ACME Order가 valid가 됐다는 사실은 새 인증서가 실제 서비스에 적용됐다는 뜻이 아니다.
Certificate Lifecycle에는 최소 네 단계의 독립된 성공 신호가 필요하다.
Issuance Success
CA가 올바른 인증서를 발급했다.
Artifact Validation Success
SAN, Chain, 유효기간과 Private Key가 기대한 값과 일치한다.
Distribution Success
모든 CDN·Load Balancer·Ingress·Server가 새 Version을 수신했다.
Live Serving Success
외부 Client 관점에서 실제 Endpoint가 새 Serial과 올바른 Chain을 제공한다.
Expiry Monitoring도 로컬 인증서 파일이나 CA Portal만 확인해서는 안 된다. 실제 사용자 경로에 SNI를 포함해 연결하고 현재 제공되는 인증서의 notAfter, Serial, Fingerprint와 Chain을 검사해야 한다.
다음과 같은 부분 실패도 구분해야 한다.
IPv4는 새 인증서, IPv6는 이전 인증서
서울 Region은 새 인증서, 다른 Region은 이전 인증서
CDN Edge는 새 인증서, 직접 Origin은 만료 인증서
일부 Kubernetes Ingress만 Secret Reload 실패
Load Balancer Listener 하나만 잘못된 Certificate ID 사용
새 인증서는 배포됐지만 중간 인증서 Chain이 잘못됨
따라서 “인증서 만료까지 30일” 같은 단일 경보 외에 다음 상태를 함께 경보해야 한다.
예정된 Renewal Job이 시작되지 않음
Authorization·CAA·DNS Challenge 실패
발급 완료 후 배포 미시작
목표 Endpoint 중 일부만 새 Version 적용
실제 제공 Serial이 Inventory의 목표 Serial과 다름
이전 인증서가 Rotation 종료 시각 이후에도 제공됨
Escalation Deadline 또는 Last Safe Deployment 도달
Rollback할 수 없는 인증서도 있다
새 인증서 배포가 실패했다고 무조건 이전 인증서를 다시 활성화해서는 안 된다.
이전 인증서를 Rollback 대상으로 사용할 수 있는 조건은 제한적이다.
아직 만료되지 않았다.
폐기되지 않았다.
Private Key 유출이 의심되지 않는다.
현재 Domain과 서비스 구성에 맞는다.
Client가 신뢰하는 Chain을 제공한다.
Rollback 이후 사용할 수 있는 시간이 충분하다.
새 인증서의 SAN이나 Chain이 잘못됐고 이전 인증서가 위 조건을 충족한다면 짧은 시간 동안 이전 Version으로 되돌릴 수 있다.
반면 이전 Private Key가 유출됐거나 인증서가 폐기된 상황에서는 Rollback이 보안 사고를 다시 활성화한다. 이때 필요한 행동은 이전 Version 복구가 아니라 새 Key 생성, 새 인증서 발급과 Forward Recovery다. IXC Insights의 배포 Rollback 원칙에서도 유출되거나 폐기된 Secret을 Rollback 대상으로 사용하지 않도록 구분한다. IXC 아이엑스씨
인증서와 Key를 Versioned Artifact로 관리하더라도, 이전 Version에는 반드시 사용 가능 종료 조건이 있어야 한다. 무기한 보존한 이전 Private Key는 복구 수단이 아니라 새로운 공격 자산이 될 수 있다.
Revocation과 Emergency Issuance를 별도 Runbook으로 만들어야 한다
인증서 교체와 인증서 폐기는 같은 작업이 아니다.
ACME는 revokeCert 작업을 정의하며 Account Key 또는 해당 인증서의 Key를 이용한 폐기 요청을 지원한다. 그러나 실제 사고에서는 어떤 인증서를 언제 폐기하고 먼저 Traffic을 격리할지, 새 인증서를 어느 경로로 발급할지 조직이 결정해야 한다.
Revocation을 검토해야 하는 대표 상황은 다음과 같다.
Private Key 유출 또는 유출 의심
승인하지 않은 인증서 발급
잘못된 Domain·SAN·조직 정보가 포함된 발급
Domain 소유권이나 서비스 운영권 상실
인증서가 더 이상 신뢰할 수 없는 시스템에 복사됨
CA 또는 보안팀이 폐기를 요구한 경우
Emergency Issuance 절차
사건을 선언하고 일반 변경을 동결한다. 단순 만료 위험인지, Key 유출인지, 무단 발급인지 먼저 구분한다.
영향 범위를 Inventory에서 확인한다. 같은 Key, ACME Account, DNS Token, SAN과 배포 경로를 공유하는 인증서를 찾는다.
노출된 Credential을 교체한다. Certificate Key뿐 아니라 ACME Account Key, DNS API Token, Deployment Credential도 조사한다.
새 Key와 인증서를 발급한다. 손상된 Key를 재사용하지 않는다. 평상시와 다른 CA를 사용할 경우에도 Trust Chain, CAA, Client 호환성과 배포 경로를 사전에 검증한 경우에만 사용한다.
제한된 Endpoint에 배포하고 실제 연결을 검증한다. 신규 Serial, SAN, Chain, TLS Handshake와 서비스 건강 신호를 확인한다.
가용성과 공격 위험을 함께 보고 이전 인증서를 폐기한다. 실제 악용이 진행 중이면 Traffic 격리와 폐기를 우선할 수 있다. 단순한 배포 오류라면 안전한 Replacement를 준비한 뒤 폐기할 수 있다.
모든 배포 지점을 재확인한다. 장기 연결, Cache, 옛 Load Balancer, IPv6, Legacy Hostname에 이전 인증서가 남지 않았는지 확인한다.
Inventory와 Incident 기록을 갱신한다. 원인, 노출 시간, 폐기 결과, 새 Serial, 재발 방지 작업과 책임자를 남긴다.
대체 CA를 마련하는 것이 모든 조직의 정답은 아니다. CA를 추가하면 Account, CAA, Chain, 계약, 발급 정책과 감사 범위도 늘어난다. 다중 CA는 장애·규제·Client 호환성 요구가 있고 실제 전환 경로를 시험한 경우에만 복구 선택지로 의미가 있다.
관리형 인증서도 Inventory에서 빼면 안 된다
CDN, PaaS, Managed Load Balancer가 인증서를 자동으로 발급하고 갱신해 주면 사용자가 직접 ACME Client를 운영하지 않아도 될 수 있다. 그렇다고 조직의 Lifecycle 책임이 사라지는 것은 아니다.
최소한 다음은 알아야 한다.
어떤 Hostname이 관리형 인증서에 포함되는가
실제 TLS 종료 지점은 어디인가
인증서 발급과 갱신 실패를 누가 알리는가
Domain Validation에 어떤 DNS Record나 권한이 필요한가
서비스 이전·Account 종료 시 인증서가 어떻게 처리되는가
실제 Endpoint에서 새 인증서가 제공되는지 누가 확인하는가
Vendor 장애나 Account 잠금 시 Emergency Path가 있는가
관리형 인증서에서는 발급과 Key 보관의 일부를 공급자가 소유한다. 조직은 Inventory, Owner, 설정 Drift, 실제 서비스 검증과 공급자 변경 시 복구 경로를 소유해야 한다.
자동화가 완료됐는지 확인하는 다섯 가지 질문
다음 질문에 모두 답할 수 있어야 수동 갱신을 끝냈다고 말할 수 있다.
운영 중인 모든 인증서와 TLS 종료 지점이 Inventory에 있는가?
각 인증서의 Owner, Key 위치와 Challenge Credential 경계가 정해져 있는가?
발급·검증·배포와 재시도가 사람의 반복 작업 없이 진행되는가?
자동화 도구와 별개로 실제 서비스가 제공하는 인증서를 확인하는가?
이전 인증서가 안전하지 않을 때 사용할 Revocation·Emergency Issuance 절차가 시험돼 있는가?
인증서 수명이 짧아지는 변화는 어느 CA를 선택하라는 신호가 아니다. 인증서를 1년에 한 번 처리하는 구매 항목이 아니라, 서비스 배포와 보안 운영에 포함된 반복 가능한 자격 증명 Lifecycle로 다루라는 신호다.
정상적인 발급과 갱신은 자동화하고 사람은 정책과 예외, 사고 대응에 집중해야 한다. 47일 단계가 실제 시행되는 날까지 기다릴 이유는 없다. 200일 단계는 이미 시작됐다.