인증서 유효기간 47일 시대 — CA/B Forum SC-081 일정과 지금 준비할 것
“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.0(2026-09-07 시행)에도 그대로다.
원문 일정부터 정리하고, 수동 갱신 조직이 어디서 막히는지, 지금 무엇부터 할지를 순서대로 짚는다.
요약
- 지금은 200일 단계다. 2026-03-15 ~ 2027-03-14 발급분은 최대 200일
- 2027-03-15 100일, 2029-03-15 47일. 도메인 검증(DCV) 재사용 기간도 함께 줄어 2029년에는 10일이 된다
- 유효기간보다 DCV 재사용이 더 아프다. 10일이면 사실상 발급할 때마다 도메인 검증을 새로 한다
admin@이메일 승인 방식은 2028-03-15 에 끝난다- 할 일은 셋이다 — 인벤토리, ACME 자동화(ARI), 갱신과 분리된 만료 감시
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 와 브라우저 어느 쪽에서도 반대가 없었다. 일정이 되돌려질 것을 전제로 준비를 미룰 이유가 없다.
방향은 세 줄로 요약된다.
- TLS 인증서 최대 유효기간: 398일 → 47일
- 도메인(SAN) 검증 데이터 재사용: 398일 → 10일
- 조직 정보(비 SAN) 검증 데이터 재사용: 825일 → 398일
2026년 3월에 시작해 2029년 3월에 끝난다.
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 이 금지하는 검증 방식과 날짜다.
아래 표의 이메일·전화 방식(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 절) |
|---|---|
| 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 에 적은 이메일 연락처) |
다년 구독·기존 인증서·사설 PKI·EV
이미 발급된 인증서
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 참조로 바꾼 정리다. 투표안 스스로 새 요구사항이 아니라고 밝혔다.
조직 신원 검증(SII)은 OV 가 398일로 한 번 줄고 끝이다. EV 는 원래 398일이었다. 조직 서류 심사는 대략 연 1회, 도메인 검증은 점점 자주 — 두 검증의 주기가 갈라진다.
지금 할 일 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개, 엑셀 없이 관리하기의 방식이 참고가 된다.
지금 할 일 2 — 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 지점에서 도는가, 갱신 후 리로드까지 되는가, 감시가 이 수명에 맞게 울리는가(할 일 3).
DNS 검증을 한 번만 설정한다 — 영구 DCV TXT
DNS-01 은 발급마다 TXT 레코드를 바꾼다. 그래서 자동화에 DNS API 권한을 열어 줘야 하고, 그 토큰이 만료되면 갱신이 죽는다. BR 에는 이 부담을 줄이는 방식이 추가됐다 — 3.2.2.4.22 영구 DNS TXT(SC088, BR 2.1.9, 2025-11-10 시행).
_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 가 이 두 파라미터를 처리하도록 의무화한다.
지금 할 일 3 — 갱신과 분리된 감시
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-09 (지금) | 최대 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일 | 발급마다 도메인 검증이 자동으로 도는 구조 완성 |
2029년까지 2년 반이 남았지만, Let’s Encrypt 사용자에게 실제 첫 기한은 2027-02-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