SSL 인증서 유효기간이 47일로 줄어든다
이 글의 순서 9개 절
“47일”은 2029년 얘기로 들리지만 축소는 이미 시작됐다. 2026-03-15부터 발급되는 공개 TLS 인증서의 최대 유효기간은 200일이다. 1년짜리 인증서를 사서 1년 쓰던 운영은 올해로 끝났다.
다음 단계는 2027-03-15의 100일, 마지막은 2029-03-15의 47일이다. 날짜는 CA/B Forum Baseline Requirements(BR)에 들어가 있고, 현행 BR 2.3.1(2026-10-04 시행)에도 그대로다. 도메인 검증(DCV) 재사용 기간도 같이 줄어 2029년에는 10일이 된다.
SC-081 투표
SC-081v3(“Introduce Schedule of Reducing Validity and Data Reuse Periods”)는 Apple이 제안하고 Sectigo, Google Chrome, Mozilla가 지지한 투표안이다. 투표는 2025-04-04 ~ 2025-04-11(UTC)에 진행됐다.
| 투표 그룹 | 찬성 | 반대 | 기권 |
|---|---|---|---|
| 인증서 발급자(CA) | 25 | 0 | 5 |
| 인증서 소비자(브라우저) | 4 | 0 | 0 |
통과 뒤 BR 2.1.5에 반영돼 2025-05-16에 시행됐다. CA와 브라우저 어느 쪽에서도 반대가 없었다. 일정이 되돌려질 거라 보고 준비를 미룰 이유가 없다.
투표안은 2026년 3월부터 2029년 3월까지 단계적으로 이렇게 줄인다.
- TLS 인증서 최대 유효기간: 398일 → 47일
- 도메인(SAN) 검증 데이터 재사용: 398일 → 10일
- 조직 정보(비 SAN) 검증 데이터 재사용: 825일 → 398일
BR 원문 일정표
BR 6.3.2(유효기간)와 4.2.1(검증 데이터 재사용)을 한 표로 합치면 이렇다. 기준은 발급일이다.
| 발급일 | 최대 유효기간 (MUST) | 권고 상한 (SHOULD) | DCV 재사용 | SII 재사용 |
|---|---|---|---|---|
| ~ 2026-03-14 | 398일 | 397일 | 398일 | 825일 |
| 2026-03-15 ~ 2027-03-14 | 200일 | 199일 | 200일 | 398일 |
| 2027-03-15 ~ 2029-03-14 | 100일 | 99일 | 100일 | 398일 |
| 2029-03-15 ~ | 47일 | 46일 | 10일 | 398일 |
DCV는 도메인명과 IP 주소 검증이고 모든 인증서가 해당한다. SII(Subject Identity Information)는 조직 신원 검증이다. OV는 2026-03-15에 825일에서 398일로 한 번 줄고, 그 뒤로 추가 단계는 없다. EV는 EV Guidelines 3.2.2.14.3에 따라 원래 398일이었다.
재사용에는 단서가 붙는다. 이전 검증에 쓴 데이터나 문서 가운데 하나라도 허용 기간보다 오래됐으면 그 검증은 재사용할 수 없다. 가장 오래된 증빙이 기준이다.
’200일’인데 왜 199일로 나오나
지금 한도는 200일인데 CA들은 199일짜리를 발급한다. 이유는 BR 안에 있다. 단계마다 SHOULD 상한이 MUST
상한보다 하루 짧다(397/199/99/46일). BR에서 하루는 86,400초이고, 소수점 초나 윤초를 포함해 1초라도 넘으면
하루가 추가된다. 유효기간은 notBefore부터 notAfter까지 양끝을 포함해 센다.
그래서 BR은 기본값으로 최대 기간까지 발급하지 말라고 적어 두었다. 한도에 딱 맞춰 발급하면 경계 계산 하나로 위반이 된다.
CA들은 여기에 더해 시행일보다 먼저 적용했다.
| CA | 적용일 | 내용 |
|---|---|---|
| DigiCert | 2026-02-24 | 199일 초과 요청을 받지 않는다(CertCentral Services API 요청은 199일로 자동 조정). 재발급·복제 인증서도 최대 199일 |
| Sectigo | 2026-03-12 | (재)발급 인증서 최대 199일, DCV 재사용 약 6개월(198일) |
수동 갱신이 막히는 곳
교체 횟수
1년 동안 인증서를 끊김 없이 유지하려면 최소 이만큼 교체해야 한다(365일 ÷ 최대 유효기간, 올림).
| 단계 | 최대 유효기간 | 연간 최소 교체 |
|---|---|---|
| ~ 2026-03-14 | 398일 | 1회 |
| 현재 (2026-03-15 ~) | 200일 | 2회 |
| 2027-03-15 ~ | 100일 | 4회 |
| 2029-03-15 ~ | 47일 | 8회 |
만료 전에 여유를 두고 교체하니 실제 횟수는 이보다 많다. 도메인 50개를 손으로 관리하면 2029년에는 연 400회 이상이다.
교체 1회의 실패 확률이 그대로여도 횟수가 8배가 되면 사고 기회도 8배다. 만료 사고가 기술보다 절차 문제라는 점은 인증서 만료 사고는 왜 반복되는가에 적었다. 유효기간이 줄면 그 절차를 1년에 여러 번 돌려야 한다.
DCV 재사용 10일
유효기간보다 영향이 큰 쪽이다. 지금은 도메인 검증을 한 번 받으면 200일 동안 재사용한다. 2029-03-15부터는 10일이다.
47일 인증서를 수명의 2/3쯤(약 31일째)에서 갱신하면 직전 검증은 이미 10일을 넘겼다. 발급할 때마다 도메인 검증을 새로 한다고 보면 된다. DNS 담당자에게 TXT 레코드를 부탁하는 절차가 발급마다 반복된다는 뜻이다. 사람 손을 거치는 검증은 이 주기를 버티지 못한다.
이메일·전화 DCV가 단계적으로 금지된다
수동 조직이 흔히 쓰는 “admin@로 온 승인 메일 클릭” 방식에도 기한이 정해졌다. BR이 금지하는 검증 방식과
날짜는 이렇다.
| 날짜 | 금지되는 방식 (BR 절) |
|---|---|
| 2025-07-15 (이미 적용) | 3.2.2.4.2 (WHOIS 도메인 연락처로 이메일·팩스·SMS·우편), 3.2.2.4.15 (도메인 연락처 전화) |
| 2026-03-15 (이미 적용) | 3.2.2.4.8 (IP Address) |
| 2027-03-15 | 3.2.2.4.16, 3.2.2.4.17 (DNS TXT·CAA에 적은 전화 연락처), IP 주소용 3.2.2.5.2·3.2.2.5.3·3.2.2.5.5 (이메일 등·Reverse Lookup·전화) |
| 2028-03-15 | 3.2.2.4.4 (Constructed Address 이메일, admin@ 등), 3.2.2.4.13, 3.2.2.4.14 (DNS CAA·TXT에 적은 이메일 연락처) |
표의 이메일·전화 방식(3.2.2.4.4·13·14·16·17, IP 주소용 3.2.2.5.2·3.2.2.5.5)은 2026-03-15부터 이미 SHOULD NOT(비권고)이다. 금지일이 남았다고 그때까지 써도 된다는 뜻은 아니다.
어디까지 해당하나
이미 발급된 인증서
BR 한도는 발급일 기준이다. 시행 전에 발급된 인증서는 만료될 때까지 유효하다(DigiCert와 Sectigo 모두 명시). 급하게 갈아 끼울 필요는 없고, 다음 교체부터 새 한도를 받는다.
다년 구독
3년, 5년 구독 상품은 계속 팔린다. 달라진 건 구조다. DigiCert 다년 플랜은 최대 3년 치를 한 번 결제하고, 인증서 유효기간이 끝날 때마다 플랜 만료까지 무료로 재발급한다. Sectigo는 1~5년 구독을 유지하면서 기간 안에 짧은 인증서를 여러 번 재발급받는 방식이다.
구독 기간과 인증서 유효기간은 별개다. 결제는 3년에 한 번이어도 교체 작업은 200일(→100일→47일)마다 돌아온다. 구매 쪽에서 “3년짜리 샀다”고 하면 운영 쪽 달력에는 교체 일정이 여러 개 잡혀야 한다.
사설 PKI
BR은 공개적으로 신뢰되는 인증서에만 적용된다. 루트를 브라우저나 OS 공급자(BR 용어로 Application Software Supplier)가 배포하지 않는 내부 전용 사설 PKI는 대상이 아니다. 사내 CA로 발급한 내부망 인증서는 이 일정과 무관하다.
거꾸로 내부 서비스라도 공개 CA 인증서를 쓰면 전부 대상이다. 인벤토리에서 이 둘을 나눠 둔다.
EV
EV 인증서도 TLS 인증서라서 원래 BR 6.3.2와 4.2.1의 한도를 받는다. 2026-03-15부터 EV도 최대 200일이고, 이후 단계도 똑같이 따른다. DigiCert의 199일 적용에도 EV가 들어간다.
EV는 별도 문서(EV Guidelines)도 따르는데, 여기에 도메인 재사용 398일과 EV 유효기간 398일 문구가 남아 있었다. SC102(2026-07-14 통과, 발급자 19 찬성·소비자 2 찬성, EVG 2.0.4로 2026-08-13 시행)는 이 문구를 BR 4.2.1·6.3.2 참조로 바꾼 정리 작업이다. 투표안 스스로 새 요구사항이 아니라고 밝혔다.
조직 서류 심사는 대략 연 1회로 남고 도메인 검증만 점점 잦아진다. 두 검증의 주기가 갈라진다.
먼저 인벤토리
무엇이 어디에 몇 장 있는지 모르면 나머지를 시작할 수 없다. 최소한 이 항목은 모은다.
| 항목 | 왜 필요한가 |
|---|---|
| 도메인(SAN 전체) | 검증은 인증서가 아니라 도메인 단위로 돈다 |
| 설치 위치 | 웹서버, 로드밸런서, 장비. 한 인증서가 여러 곳에 복사돼 있는 경우가 많다 |
| 발급 CA·방식 | ACME 자동 / 수동 구매 / 사내 CA |
| DCV 방식 | 이메일이면 2028-03-15 전 전환 대상 |
| 담당자 | 교체, 리로드, DNS 수정을 각각 누가 하는가 |
| notAfter | 현재 만료일 |
수집 명령:
# Certbot 이 관리하는 인증서 — 도메인·만료일·경로
sudo certbot certificates
# 파일로 들고 있는 인증서
openssl x509 -in cert.pem -noout -dates
# 실제 서비스 중인 인증서 (디스크 파일과 다를 수 있다)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -enddate세 번째를 빼먹지 않는다. 파일 목록만 모으면 로드밸런서나 장비에 따로 올라가 있는 인증서가 빠진다. 도메인에서 출발해 서빙 중인 인증서를 거꾸로 확인해야 빠짐이 없다.
분류가 끝나면 우선순위는 분명하다. 수동으로 사면서 이메일로 DCV를 받는 조합이 가장 먼저다. 도메인이 수십 개라면 고객사 도메인 50개, 엑셀 없이 관리하기의 방식을 참고할 만하다.
ACME로 자동화한다
연 8회 교체와 매번 새로 하는 도메인 검증을 사람이 감당할 수는 없다. 답은 ACME다. 이미 Certbot을 쓰고 있어도 확인할 것이 있다.
Let’s Encrypt는 BR보다 먼저 줄인다
2026-09 현재 프로필:
| 프로필 | 유효기간 | 인가 재사용 | 비고 |
|---|---|---|---|
| classic | 90일 | 30일 | 기본 |
| tlsserver | 45일 | 7시간 | 2026-05-13부터 45일, opt-in |
| shortlived | 160시간 | 7시간 |
tlsclient 프로필은 2026-07-08부터 제공되지 않는다.
기본값인 classic은 이렇게 바뀐다.
| 날짜 | classic 유효기간 | 인가 재사용 |
|---|---|---|
| 2027-02-10 | 64일 | 10일 |
| 2028-02-16 | 45일 | 7시간 |
BR의 100일(2027-03-15)보다 약 한 달, 47일(2029-03-15)보다 1년 넘게 앞선다. Let’s Encrypt를 쓴다면 실제 기한은 BR 일정이 아니라 이 날짜다.
인가 재사용 축소는 정기 갱신보다 재발급에 먼저 닿는다. 지금도 classic(인가 재사용 30일) 인증서를 60일째쯤 갱신하면 직전 인가는 이미 만료돼 챌린지를 새로 통과한다. 2028-02-16에 7시간이 되면 같은 도메인을 여러 서버에서 따로 받거나, 실패 뒤 재시도하거나, 며칠 만에 재발급할 때도 매번 챌린지가 필요하다. 80 포트와 챌린지 경로, DNS API 자격증명은 갱신 때만이 아니라 늘 살아 있어야 한다. 챌린지가 깨지는 흔한 원인은 Let’s Encrypt 자동갱신이 실패하는 흔한 이유에 있다.
BR의 단기(Short-lived) 인증서 정의도 2026-03-15 발급분부터 10일 이하에서 7일(604,800초) 이하로 좁아졌다. shortlived 프로필의 160시간은 이 안에 든다.
고정 주기 갱신은 걷어낸다
Let’s Encrypt는 “60일마다” 같은 하드코딩 주기로는 부족해진다고 경고한다. 90일 인증서라면 60일 주기에도 30일 여유가 있지만, 45일 인증서는 갱신이 돌기 전에 만료된다.
대신 잔여 수명이 약 1/3 남았을 때(수명의 2/3가 지난 시점) 갱신하거나 ARI(ACME Renewal Information)를 쓰라고 권한다.
ARI는 RFC 9773(2025년 6월, Standards Track)이다.
- 클라이언트가 인증서별
renewalInfo리소스를 조회한다 - 서버가
suggestedWindow(start/end, RFC 3339 시각, 필수)와, 선택적으로explanationURL을 돌려준다 - 클라이언트는 창 안의 임의 시각에 갱신하고,
Retry-After주기로 다시 조회한다
갱신 시점을 서버가 알려 주므로 수명이 바뀌어도 클라이언트 쪽 계산식을 고칠 일이 줄어든다.
Certbot은 이렇게 따라왔다.
| 버전 | 변화 |
|---|---|
| 4.0.0 (2025-04-07) | 기본 갱신 시점 = 잔여 수명 1/3 미만 (수명 10일 미만 인증서는 1/2) |
| 4.1.0 (2025-06-10) | ARI 지원. certbot renew가 ARI를 자동 확인하고, 권고에 따라 일찍 갱신할 수 있다 |
| 4.2.0 (2025-08-05) | ARI 조회 오류가 실제 발급을 막지 않도록 수정 |
| 5.0.0 (2025-09-02) | ARI Retry-After를 실행 간에 저장해 지킨다 |
certbot --version # 4.2.0 이상인지 (가능하면 최신 5.x)
systemctl list-timers | grep certbot # renew 가 주기적으로 도는지
sudo certbot renew --dry-run --run-deploy-hooks
# 스테이징에서 챌린지·발급 + deploy hook(리로드)까지 리허설.
# --run-deploy-hooks 가 없으면 deploy hook 은 돌지 않고, dry-run 에서는 ARI 도 확인하지 않는다타이머는 자주 돌게 두고, 실제로 갱신할지는 Certbot이 수명과 ARI를 보고 판단하게 맡긴다. 직접 짠 스크립트나 cron이 “N일마다 무조건 재발급”하는 구조라면 걷어낸다.
45일을 미리 겪어 본다
tlsserver 프로필은 지금 45일짜리를 준다. 서버 한 대에서 리허설하면 2028년에 올 문제를 지금 볼 수 있다.
sudo certbot certonly --webroot -w /var/www/html -d example.com \
--preferred-profile tlsserver--preferred-profile은 해당 프로필이 없으면 기본 프로필로 폴백하고, --required-profile은 발급에
실패한다. 프로필이 갱신 설정에 저장돼 갱신 때도 유지되려면 Certbot 4.1.0 이상이어야 한다. Certbot이 이미
같은 도메인 인증서를 관리하고 있으면 아직 갱신 시점이 아니라서 새로 발급하지 않을 수 있다. 이때는
--cert-name example.com --force-renewal을 붙인다.
리허설에서는 갱신이 잔여 1/3 지점에서 도는지, 갱신 뒤 리로드까지 되는지, 감시가 이 수명에 맞게 울리는지(아래 감시 절) 본다.
영구 DCV TXT
DNS-01은 발급마다 TXT 레코드를 바꾼다. 그래서 자동화에 DNS API 권한을 열어 줘야 하고, 그 토큰이 만료되면 갱신이 죽는다. BR에는 이 부담을 줄이는 3.2.2.4.22 영구 DNS TXT 방식이 추가됐다(SC088, BR 2.1.9, 2025-11-10 시행). DNS 검증을 한 번만 설정해 두는 방식이다.
_validation-persist.example.com. IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"_validation-persist.<도메인>에 CA 도메인과 accounturi(필수)를 담은 TXT를 한 번 둔다. persistUntil(선택)로
레코드의 만료 시각을 정할 수 있다. 이 방식으로 끝낸 검증은 4.2.1 일정(현재 200일)과 무관하게 지금부터
재사용 상한이 최대 10일이다(CA가 더 짧게 정할 수 있다). 레코드가 남아 있으니 CA가 다시 조회하면 된다.
Let’s Encrypt는 같은 개념의 DNS-PERSIST-01을 개발 중이다. 쓰는 CA가 지원하는지는 따로 확인해야 한다. Let’s Encrypt(webroot, DNS-01)와 구매 인증서 CSR 발급 절차는 인증서 발급 공통 가이드에 있다.
CAA로 발급 계정을 묶는다
자동화가 늘면 누가 이 도메인으로 인증서를 받을 수 있는지가 중요해진다. CAA에 accounturi를 넣으면 특정
ACME 계정만 발급받도록 묶을 수 있다(RFC 8657). validationmethods로는 허용할 검증 방식(http-01,
dns-01, tls-alpn-01)을 제한한다.
example.org. CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<ACCOUNT_ID>"플래그는 보통 0이다. 128(critical)은 모르는 태그에만 작용하므로, 붙여도 accounturi 처리를 강제하지
않는다.
BR은 2027-03-15부터 CA가 이 두 파라미터를 처리하도록 의무화한다.
감시는 갱신과 따로 둔다
Let’s Encrypt의 만료 알림 메일 서비스는 2025-06-04에 끝났다. Let’s Encrypt는 알림이 필요하면 제3자 모니터링을 쓰라고 권한다. 갱신이 조용히 실패해도 CA가 대신 알려 주지 않는다.
감시는 갱신 도구와 분리해야 한다. Certbot의 성공 로그는 디스크의 파일이 바뀌었다는 뜻일 뿐, 서비스가 새
인증서를 내보낸다는 뜻은 아니다. 바깥에서 실제 notAfter를 본다.
# 스크립트로 저장해 cron·모니터링에서 실행한다
# 14일(1,209,600초) 안에 만료되면 exit 1, 연결·인증서 파싱 실패는 exit 2
cert=$(openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509) || { echo 'CHECK FAILED'; exit 2; }
echo "$cert" | openssl x509 -noout -checkend 1209600 >/dev/null \
|| { echo 'EXPIRES WITHIN 14 DAYS'; exit 1; }연결 실패와 만료 임박을 나눠 둔 건, 둘을 한 경보로 묶으면 DNS 오류나 방화벽 차단이 “만료 임박”으로 보고되기 때문이다.
경보 기준은 수명에 맞춰 다시 잡는다. 정상이라면 이미 갱신됐어야 하는 시점에 울리게 한다. 잔여 1/3 갱신 기준으로 계산하면 이렇다.
| 인증서 수명 | 정상 갱신 시점 (잔여) |
|---|---|
| 90일 | 30일 |
| 64일 | 약 21일 |
| 45일 | 15일 |
90일 인증서에 맞춰 잡아 둔 “잔여 21일” 경보를 45일 인증서에 그대로 두면 정상 상태에서도 매 주기 울린다. 반대로 오탐을 피하려고 경보를 너무 낮게(예: 잔여 3일) 내리면 여유가 사라진 뒤에야 알게 된다. 인증서 수명이 바뀌는 2027-02-10과 2028-02-16에 경보 기준도 같이 고친다.
여러 도메인의 만료일을 모아 슬랙으로 보내는 구성은 인증서 만료 알림 체계 직접 만들기에 있다.
날짜별로 끝낼 일
| 날짜 | 바뀌는 것 | 그 전에 끝낼 것 |
|---|---|---|
| 2026-03-15 이후 (지금) | 최대 200일, DCV 재사용 200일, SII 398일 | 인벤토리, 수동 갱신 대상 식별, Certbot 4.2.0+(ARI, 가능하면 최신 5.x) |
| 2027-02-10 | Let’s Encrypt classic 64일, 인가 재사용 10일 | 고정 주기 갱신 제거, 경보 기준 조정 |
| 2027-03-15 | 최대 100일, DCV 100일, 전화 DCV(3.2.2.4.16·17) 금지, CAA accounturi·validationmethods 처리 의무 |
연 4회 교체를 전제로 수동 절차를 자동화로 전환 |
| 2028-02-16 | Let’s Encrypt classic 45일, 인가 재사용 7시간 | 챌린지 경로·DNS API 상시 가동 확인 |
| 2028-03-15 | 이메일 DCV(3.2.2.4.4·13·14) 금지 | 이메일 검증 도메인을 DNS·HTTP 검증으로 전환 |
| 2029-03-15 | 최대 47일, DCV 재사용 10일 | 발급마다 도메인 검증이 자동으로 도는 구조 완성 |
지금 서비스 중인 인증서의 만료일과 체인 상태부터 보려면 /check에 도메인을 넣어 본다. 갱신 도구와 별개로 바깥에서 만료를 지켜볼 곳이 필요하면 도메인 5개까지는 무료 만료 감시 구독으로 걸어 둘 수 있다.
참조
- CA/B Forum Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
- CA/B Forum: Baseline Requirements (TLS Server Certificates)
- CA/B Forum: BR.md 원문 (servercert 저장소)
- CA/B Forum Ballot SC102: EV Domain Reuse and Validity Alignment
- DigiCert: Public TLS certificates 199-day validity
- DigiCert: Multi-year plans
- Sectigo, DCV Reuse Reduction to 198 Days: Implementation Guidance
- Let’s Encrypt: From 90 to 45 days (2025-12-02)
- Let’s Encrypt: Profiles
- Let’s Encrypt: 만료 알림 이메일 서비스 종료 (2025-06-26)
- Let’s Encrypt: Certificate Authority Authorization (CAA)
- RFC 9773: ACME Renewal Information (ARI)
- Certbot 4.1.0 Release
- Certbot User Guide
- OpenSSL: openssl-s_client
- OpenSSL: openssl-x509