인증서가 47일마다 만료되는 시대 — TLS 수명 단축 일정과 ACME 자동 갱신 운영법

인증서를 1년에 한 번 갱신하던 시대가 끝나갑니다

웹 서비스를 운영하다 보면 SSL/TLS 인증서 갱신은 1년에 한 번 돌아오는 연례 행사처럼 여겨지곤 했습니다. 캘린더에 만료일을 적어두고, 때가 되면 새 인증서를 발급받아 교체하는 식이었죠. 그런데 이 주기가 앞으로 몇 년에 걸쳐 크게 짧아집니다.

국제 표준을 정하는 CA/Browser Forum이 공개 TLS 인증서의 최대 유효기간을 단계적으로 줄이기로 결정했기 때문입니다. 최종적으로는 인증서 한 장의 최대 수명이 47일까지 짧아집니다. 한 해에 여러 번 갱신해야 한다는 뜻인데요, 지금까지처럼 사람이 만료일을 챙겨 손으로 교체하는 방식으로는 감당하기 어려워집니다.

이 글에서는 무엇이 어떻게 바뀌는지를 공식 발표 기준으로 정리하고, 빈번해진 갱신을 사고 없이 처리하기 위한 자동화 운영 관점을 함께 살펴보겠습니다. CDN 환경에서 인증서를 어디에 어떻게 적용하는지에 관한 설정 절차는 3월 11일(수) 발행 CDN SSL 인증서 설정 가이드에서 따로 정리했으니, 이 글은 수명 단축이라는 변화와 운영 전략에 집중합니다.

무슨 일이 있었나 — CA/Browser Forum SC-081v3

CA/Browser Forum은 인증기관(CA)과 브라우저 제조사 등이 모여 공개 인증서의 발급·운영 기준을 정하는 협의체입니다. 이곳에서 SC-081v3 안건, 정식 명칭으로는 Introduce Schedule of Reducing Validity and Data Reuse Periods가 표결에 부쳐졌고, CA/Browser Forum 공식 안건 페이지에 따르면 투표 기간이 2025년 4월 11일에 종료되며 통과됐습니다.

표결 결과는 인증서 발급자 그룹에서 찬성 25, 반대 0, 기권 5, 인증서 소비자 그룹에서 찬성 4, 반대 0으로, 반대표 없이 가결됐습니다. 이 안건은 Apple이 제안했으며, 앞서 90일 상한을 주장했던 Google도 표결에서 Apple의 제안에 찬성표를 던졌습니다.

안건은 TLS Baseline Requirements 문서의 두 부분을 손봅니다. 인증서 최대 유효기간 단축 일정을 규정하는 항목과, 도메인 검증 정보를 얼마나 오래 재사용할 수 있는지를 규정하는 항목입니다. 이용자가 체감하는 첫 변화는 2026년 3월부터 시작됩니다.

398일에서 47일까지, 단계별 단축 일정

핵심은 한 번에 47일로 떨어지는 게 아니라, 2026년부터 2029년까지 세 차례에 걸쳐 단계적으로 줄어든다는 점입니다. DigiCert 공식 정리에 따르면 공개 TLS 인증서의 최대 유효기간은 다음과 같이 짧아집니다.

표에서 보듯 인증서 수명만 줄어드는 게 아닙니다. 한 번 검증한 도메인 정보를 재사용할 수 있는 기간도 함께 짧아져, 2029년에는 10일까지 내려갑니다. 인증서를 새로 발급할 때 도메인 소유권 검증을 그만큼 자주 다시 해야 한다는 의미입니다.

참고로 47일이라는 숫자는 임의로 정해진 값이 아니라 단순한 계산식에서 나왔습니다. 공식 설명에 따르면 47일 = 한 달(31일) + 30일 한 달의 절반(15일) + 여유 1일로 구성됩니다.

왜 줄이나 — 인증서 신뢰성과 검증 정보 재사용

수명을 짧게 만드는 이유는 보안과 직결됩니다. 공식 자료는 그 배경을 이렇게 설명합니다. 인증서에 담긴 정보는 시간이 지날수록 점점 신뢰하기 어려워지고, 이 문제는 정보를 자주 재검증하는 방법으로만 완화할 수 있다는 것입니다.

예를 들어 어떤 도메인의 소유자가 바뀌거나 회사가 사라져도, 한 번 발급된 인증서는 유효기간이 끝날 때까지 그대로 신뢰됩니다. 유효기간이 길수록 이런 시차가 길어지죠. 게다가 잘못 발급된 인증서를 무효화하는 폐기 체계(CRL·OCSP)가 신뢰하기 어렵다는 점도 함께 지적됐습니다. 인증서를 무효화하기 어렵다면, 애초에 수명을 짧게 만들어 위험에 노출되는 기간 자체를 줄이자는 접근입니다.

도메인 검증 정보 재사용 기간을 10일까지 줄인 것도 같은 맥락입니다. 발급 시점에 도메인 소유권을 더 자주, 더 최근 시점에 확인하도록 만들어 인증서가 담고 있는 정보의 신선도를 높이려는 의도입니다.

수동 갱신으로는 감당할 수 없는 빈도

운영 입장에서 가장 직접적인 변화는 갱신 빈도입니다. 유효기간을 기준으로 1년에 몇 번 갱신해야 하는지를 단순 산술로 환산하면 그 부담이 한눈에 보입니다.

유효기간 398일이면 사실상 1년에 한 번이지만, 47일이 되면 한 해에 여덟 번 가까이 갱신해야 합니다(365일을 유효기간으로 나눈 산술 환산값입니다). 인증서가 한두 장이라면 어떻게든 손으로 챙길 수 있겠지만, 도메인과 서브도메인, 내부 서비스까지 합쳐 수십·수백 장을 운영하는 환경이라면 이야기가 달라집니다.

갱신을 한 번이라도 놓치면 그 순간 서비스 접속이 막히고 보안 경고가 노출됩니다. 빈도가 여덟 배로 늘어난다는 것은 곧 만료 사고가 날 확률도 그만큼 늘어난다는 뜻입니다. 그래서 공식 자료도 이번 변화를 두고 자동화가 필수가 됐다고 표현합니다.

ACME 기반 자동 갱신으로 운영 체계 잡기

잦은 갱신을 사람의 손에서 떼어내는 표준 방법이 바로 ACME입니다. ACME는 RFC 8555로 정의된 Automatic Certificate Management Environment 프로토콜로, 2019년 3월 IETF 표준으로 발행됐습니다. 공식 초록은 이를 인증기관(CA)과 신청자가 검증과 인증서 발급 과정을 자동화하기 위해 사용하는 프로토콜이며, 인증서 폐기 같은 다른 관리 기능도 제공한다고 설명합니다.

ACME를 쓰면 클라이언트가 인증기관과 자동으로 통신해 도메인 소유권을 검증하고, 인증서를 발급·설치·갱신하는 과정을 사람 개입 없이 처리합니다. 유효기간이 47일로 짧아져도, 갱신 주기를 스케줄에 맡겨두면 빈도 자체는 운영 부담이 되지 않습니다. 다만 자동화를 켜두는 것만으로 끝나지 않고, 다음 세 가지를 함께 잡아야 사고를 막을 수 있습니다.

1) 인증서 인벤토리부터 파악합니다

자동 갱신을 적용하려면 먼저 우리 조직이 어떤 도메인에, 어떤 인증서를, 어디에 적용해 두었는지 목록이 있어야 합니다. 수명이 길 때는 흩어져 있어도 큰 문제가 없었지만, 갱신이 잦아지면 누락된 인증서 한 장이 곧 장애로 이어집니다. 도메인·서브도메인·내부 서비스까지 빠짐없이 정리하는 것이 출발점입니다.

2) 만료 전에 미리 갱신되도록 여유를 둡니다

자동 갱신은 보통 유효기간이 끝나기 일정 시점 전에 미리 새 인증서를 받아두도록 설정합니다. 갱신이 한 번 실패하더라도 만료 전에 재시도할 시간이 남아 있어야 하기 때문입니다. 유효기간이 짧아질수록 이 여유 구간을 어떻게 잡을지가 중요해집니다.

3) 갱신 실패를 감지하는 알림을 둡니다

자동화의 가장 큰 함정은 조용한 실패입니다. 갱신이 멈췄는데 아무도 모르고 있다가 만료일에 장애가 터지는 경우인데요. 갱신 성공·실패와 임박한 만료를 모니터링해 사람에게 알리는 장치를 함께 두어야, 자동화가 진짜 안전망이 됩니다.

이것만 기억하세요

자주 묻는 질문