공개 TLS 인증서의 최대 유효기간은 2026년 3월 15일부터 200일로 줄었다. CA/Browser Forum의 현재 기준은 2027년 100일, 2029년 47일을 다음 단계로 정해 두었다. NDC Toronto 2026에서 Todd Gardner가 "SSL에 대해 배운 모든 것이 더는 유효하지 않다"고 말한 배경도 여기에 있다. 한 번 발급해 두고 달력에 만료일을 적는 방식은 이제 운영 주기와 맞지 않는다.
TLS는 유지하되 수동 갱신 절차는 끝내야 한다. 인증서 사고는 암호 알고리즘보다 자산 목록의 누락, 갱신 뒤 배포 누락, 로드밸런서와 원본 서버의 인증서 불일치에서 먼저 난다. 유효기간이 짧아질수록 사람의 역할은 실패를 빨리 발견하고 되돌리는 일로 바뀐다.
200일 인증서가 왜 수동 운영을 흔드는가
398일짜리 인증서를 기준으로 만든 절차에서는 담당자가 만료 몇 주 전 티켓을 열고, 인증서 요청을 승인하고, 파일을 서버나 장비에 복사한 뒤 재시작 여부를 확인했다. 200일 단계에서는 같은 자산이 1년에 두 번 이상 이 과정을 지나고, 47일 단계에서는 약 6주 간격이 된다. 여러 도메인, CDN, 웹 서버, API 게이트웨이, Kubernetes Ingress에 종료 지점이 나뉘어 있으면 만료 알림 하나로는 어느 위치가 실제 트래픽을 받고 있는지 알 수 없다.
짧은 수명은 보안상의 이유도 있다. CA/Browser Forum은 인증서가 발급 시점의 사실을 담는 기록이며 시간이 갈수록 도메인 통제권이나 키 접근 권한이 달라질 수 있다고 설명한다. 더 자주 검증하고 교체하면 오래된 정보가 유효한 인증서에 남아 있는 기간도 짧아진다. 이는 인증서 교체를 예외 작업으로 두지 말라는 운영 요구다.
자동화에는 발급 뒤 배포 확인까지 필요하다
ACME는 도메인 통제 확인과 인증서 발급을 프로그램이 처리하도록 만든 프로토콜이다. Let’s Encrypt는 수동 갱신을 유도하는 브라우저 기반 ACME 클라이언트를 목록에 넣지 않는 이유로, 갱신 누락 위험을 든다. Certbot 같은 클라이언트는 인증서를 갱신하고, 성공한 갱신에만 --deploy-hook을 실행할 수 있다. 이 훅에 웹 서버 재적재나 비밀 저장소·로드밸런서 반영을 연결할 수 있다.
갱신 로그가 성공이어도 서비스가 새 인증서를 내보내는지는 별도로 확인해야 한다. 인증서가 종료되는 지점을 먼저 목록으로 만들고, 각 지점의 발급 방법과 배포 경로를 한 줄로 연결해야 한다. 그 다음에 새 인증서의 일련번호 또는 만료일을 외부 TLS 연결에서 읽어 배포 결과를 확인한다. 이 검사는 배포 훅이 실패한 경우와 설정은 반영됐지만 오래된 프로세스가 계속 응답하는 경우를 함께 잡는다.
이번 분기에 바꿀 순서
첫째, 외부에서 HTTPS를 제공하는 이름과 종료 지점을 수집한다. 인증서 파일이 있는 서버 목록만으로는 부족하다. 같은 도메인이 CDN과 원본, 별도 API에서 각각 다른 인증서를 낼 수 있다. 둘째, 각 지점에 ACME 또는 인증기관 API로 갱신할 수 있는 경로를 붙이고, 수동으로 파일을 옮기는 단계를 없앤다. DNS-01 검증처럼 DNS 권한이 필요한 방식은 토큰의 범위를 해당 존으로 좁힌다.
셋째, 갱신 뒤 실제 연결을 검사하고 실패를 담당 채널로 보낸다. 만료일이 임계값 안으로 들어왔는데 새 인증서가 보이지 않으면 담당 채널로 알린다. 이 경보가 성공 알림을 쌓는 것보다 운영에 유용하다. 넷째, 만료가 임박한 인증서를 한 번 교체해 보는 연습과 잘못 배포했을 때 되돌릴 절차를 정기 작업으로 둔다. 47일 환경의 갱신 자동화는 사람이 처리할 실패를 충분히 이른 시점에 드러내야 한다.
출처: Todd Gardner, NDC Toronto 2026 발표 · CA/Browser Forum TLS Baseline Requirements · Let’s Encrypt ACME 클라이언트 문서 · Certbot 사용자 가이드