Skip to content
Published on

47일짜리 TLS 인증서까지의 일정표 — SC-081v3 원문으로 확인한 단계별 날짜, Let's Encrypt의 45일 전환, ACME ARI

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
공유하기
Authors

들어가며 — 첫 번째 마감은 이미 지나갔다

2026년 3월 15일, 공개 신뢰(publicly-trusted) TLS 인증서의 최대 수명이 398일에서 200일로 줄었습니다. 이 글을 쓰는 시점 기준으로 넉 달 전 일입니다. 연 1회 수동 갱신으로 버티던 팀이라면 올해 갱신 시점에 이미 체감했을 것이고, 아직 체감하지 못했다면 지금 쓰는 인증서가 만료되는 날 체감하게 됩니다.

이건 시작일 뿐입니다. 2025년 4월 CA/B Forum에서 통과된 투표 SC-081v3는 2029년 3월까지 최대 수명을 47일로 내리는 일정을 못 박았습니다. 그런데 이 주제는 요약 기사마다 날짜가 조금씩 다르게 돌아다닙니다. 그래서 이 글은 투표문과 TLS Baseline Requirements(BR) 원문에서 단계별 날짜를 직접 확인하는 데서 시작합니다. 그다음 Let's Encrypt가 공지한 실제 전환 날짜, 그리고 이 일정에서 살아남기 위한 도구들 — ACME 프로파일, 6일짜리 단기 인증서, ARI(RFC 9773), DNS-PERSIST-01 — 을 지금 시점의 실제 지원 현황과 함께 정리합니다.

참고로 인증서 쪽의 또 다른 큰 흐름인 포스트양자 전환은 PQ 인증서가 아직 안 오는 이유 편에서 따로 다뤘습니다. 두 흐름은 맞물립니다 — 수명이 짧을수록 알고리즘 교체가 빨라지니까요. 이 글은 수명과 자동화 쪽만 봅니다.

SC-081v3가 실제로 정한 일정 — 원문의 두 표

BR 6.3.2절의 최대 수명 일정입니다. 현행 BR(v2.2.8, 2026-06-16)에도 투표 당시 문안 그대로 실려 있는 걸 확인했습니다.

발급일 기준이 날짜 전까지최대 수명
—2026-03-15398일
2026-03-15부터2027-03-15200일
2027-03-15부터2029-03-15100일
2029-03-15부터—47일

각 단계에는 SHOULD NOT 한도가 하루씩 낮게 붙어 있습니다(397·199·99·46일). BR은 하루를 86,400초로 정의하고, 이를 1초라도 넘으면 하루를 더 센다고 명시합니다. 그래서 "최대치에 딱 맞춰 발급하지 말라(SHOULD NOT)"는 문장도 함께 들어 있습니다 — 뒤에 나올 Let's Encrypt의 45일이라는 숫자가 여기서 나옵니다.

그리고 같은 투표가 고친 4.2.1절의 도메인·IP 검증 데이터 재사용 일정입니다.

발급일 기준이 날짜 전까지검증 데이터 재사용 한도
—2026-03-15398일
2026-03-15부터2027-03-15200일
2027-03-15부터2029-03-15100일
2029-03-15부터—10일

마지막 줄을 다시 보세요. 수명은 47일로 "줄어드는" 것이지만, 도메인 검증(DCV) 재사용은 10일로 "무너집니다". 재사용 기간이 인증서 수명보다 짧아지는 최초의 구간입니다. 47일짜리 인증서를 갱신할 때마다 지난번 검증을 재사용할 수 없을 가능성이 높다는 뜻이고, 사실상 "갱신 = 매번 재검증"이 됩니다. 도메인·IP가 아닌 주체 신원 정보(OV의 조직 정보 같은 것)의 재사용도 825일에서 398일로 줄었습니다(2026-03-15부터).

이 일정이 노리는 게 뭔지는 투표문이 직접 말합니다 — 인증서는 발급 시점의 사실을 증명하는 스냅숏인데 시간이 지날수록 현실과 벌어진다는 것, 그리고 폐지(revocation) 인프라가 인터넷 규모에서 확장성·신뢰성·사용자 비용 면에서 제 역할을 못 하니 수명 자체를 짧게 해 보호를 "확실하게" 만들겠다는 것입니다. 흥미로운 대목 하나 — 자동화 확산은 투표문 스스로 "부수적 이득(ancillary benefit)"이라고 적었습니다. 자동화를 시키려고 수명을 줄이는 게 아니라, 수명을 줄이는 김에 자동화가 따라온다는 순서입니다.

투표 결과가 말해주는 것 — 2019년과 2025년

이런 시도가 처음이 아닙니다. 2019년의 SC22 투표는 최대 수명을 1년으로 줄이자는 안이었는데, CA 측 투표에서 찬성 11 대 반대 20(기권 2)으로 부결됐습니다. 찬성률 35%. 반면 브라우저 측(Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360)은 7표 전원 찬성이었습니다. 결과적으로는 부결이 무색하게, BR 개정 이력 기준 2020-09-01부로 최대 398일이 발효됐습니다 — 루트 프로그램들이 포럼 표결 밖에서 방향을 정한 셈입니다.

2025년의 SC-081v3는 그림이 완전히 다릅니다. Apple의 Clint Wilson이 발의하고 Sectigo·Google Chrome·Mozilla가 배서했으며, 2025-04-11에 끝난 투표에서 CA 측 30표 중 찬성 25, 반대 0, 기권 5(Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA)로 통과됐습니다. 브라우저 측은 4표 전원 찬성. 2019년에 반대표를 던졌던 GoDaddy·GlobalSign·D-TRUST·Izenpe·SwissSign이 이번엔 찬성으로 돌아섰고, 2019년의 반대파 중 SECOM과 TWCA는 기권으로 물러났습니다. 반대 0표라는 결과는 업계가 이 방향을 받아들였다는 뜻이기도 하지만, 루트 프로그램이 어차피 강제할 수 있다는 2020년의 학습효과가 반영된 결과로 읽는 게 정직할 겁니다.

Let's Encrypt의 실제 전환 날짜 — 90 → 64 → 45

BR 일정은 상한선이고, 실제 운영자가 체감하는 건 자기 CA의 일정입니다. Let's Encrypt는 2025년 12월 90일에서 45일로 줄이는 계획을 공지하면서 날짜를 못 박았습니다. 전환은 ACME 프로파일 단위로 굴러갑니다.

  • 2026-05-13 — tlsserver 프로파일이 45일 인증서로 전환. 옵트인 프로파일이라 얼리어답터·테스트용입니다. 이건 이미 시행됐고, 현재 프로파일 문서에 45일로 반영돼 있습니다.
  • 2027-02-10 — 기본값인 classic 프로파일이 64일 인증서 + 인증(authorization) 재사용 10일로 전환. 프로파일을 따로 고르지 않은 모든 사용자가 여기에 해당합니다.
  • 2028-02-16 — classic이 45일 인증서 + 인증 재사용 7시간으로 전환.

각 변경은 프로덕션 약 한 달 전에 스테이징에 먼저 배포됩니다. 눈에 띄는 점 두 가지 — 45는 47보다 작습니다(앞서 본 86,400초 규칙과 "최대치로 발급하지 말라"는 BR 문장에 대한 여유), 그리고 2028-02-16이라는 날짜는 BR이 47일을 강제하는 2029-03-15보다 열세 달가량 빠릅니다. Let's Encrypt는 BR 마감보다 한 해 먼저 움직입니다.

현재 프로덕션 디렉터리가 광고하는 프로파일 세 개를 문서 기준으로 비교하면 이렇습니다(2026-07-14 갱신본 기준).

속성classictlsservershortlived
인증서 수명90일45일160시간(6일 남짓)
인증 재사용30일7시간7시간
도전과제 완료 시한7일1시간1시간
주문 수명7일8시간8시간
CN / KE-KU / SKID포함제거제거
최대 이름 수1002525
식별자 타입DNSDNSDNS, IP

tlsserver의 인증 재사용 7시간에는 이유가 있습니다 — BR이 발급 8시간 전 이내의 CAA 재확인을 요구하므로, 재사용을 7시간으로 잡으면 재확인 자체를 안 해도 됩니다. 갱신량 걱정은 Let's Encrypt가 따로 답을 냈습니다 — 90일 인증서를 60일 차에 갱신하던 것이 45일 인증서를 30일 차에 갱신하는 것으로 바뀌면 갱신 요청은 두 배가 되지만, 갱신은 레이트 리밋에서 면제라 신규 도메인 발급 한도(계정당 하루 300건)에는 영향이 없습니다.

6일짜리 인증서와 IP 인증서 — 이미 일반 제공 중

일정의 끝(47일)보다 더 멀리 간 옵션도 이미 있습니다. Let's Encrypt의 shortlived 프로파일은 2026년 1월 15일부로 일반 제공입니다. 수명 160시간 — BR이 2026-03-15부터 "단기 인증서(Short-lived Subscriber Certificate)"로 인정하는 상한 7일(604,800초) 안에 들어갑니다. 단기 인증서로 분류되면 BR상 폐지 지원이 의무가 아니라 선택이 됩니다. 키가 유출돼도 6일이면 만료로 끝나니, 신뢰할 수 없는 폐지 인프라에 기대는 대신 수명으로 보호하는 겁니다. 다만 현재는 이 프로파일 인증서에도 CRL URL이 여전히 들어갑니다 — 빼는 논의는 boulder#7673에 열려 있습니다.

2025년 7월 첫 발급을 거쳐 함께 GA가 된 IP 주소 인증서는 반드시 shortlived여야 합니다 — IP는 도메인보다 소유가 더 자주 바뀐다는 이유로 Let's Encrypt가 정한 정책입니다. certbot 쪽 지원은 올해 3월에 정리됐습니다 — 프로파일 선택 플래그 --preferred-profile은 certbot 4.0부터, --ip-address 플래그는 5.3부터, webroot 모드의 IP 지원은 5.4부터입니다. 단 nginx·apache 설치 플러그인은 아직 IP 인증서를 지원하지 않아서 배포 훅으로 직접 연결해야 합니다.

Let's Encrypt 스스로 단기 프로파일에 대해 "이 프로파일은 모두를 위한 것이 아니다"라고 적고, 기본값으로 만들 계획이 없다고 못 박았다는 점은 그대로 옮겨둘 가치가 있습니다. 160시간짜리 인증서는 갱신 파이프라인이 나흘 정도만 죽어 있어도 만료로 이어집니다. 자동화를 완전히 신뢰하기 전에는 고르지 않는 게 맞습니다.

갱신 시점을 하드코딩하지 마라 — ACME ARI(RFC 9773)

"만료 30일 전 갱신" 같은 하드코딩은 90일 시대의 유물입니다. 수명이 90 → 64 → 45로 움직이는 동안 임계값을 계속 손보는 대신, CA가 갱신 시점을 알려주는 표준이 이미 있습니다 — 2025년 6월 발행된 RFC 9773, ACME Renewal Information(ARI)입니다. 2021년 9월 첫 드래프트부터 4년 만의 표준화이고, Let's Encrypt는 드래프트 시절인 2021년 말부터 서버(Boulder) 쪽을 지원해 왔습니다. 지금 프로덕션 디렉터리에 renewalInfo 엔드포인트가 실제로 떠 있는 것도 확인했습니다.

동작은 단순합니다. 클라이언트가 인증서의 AKI와 시리얼로 식별자를 만들어 물으면, 서버가 권장 갱신 창을 돌려줍니다.

GET {renewalInfo}/base64url(AKI keyIdentifier).base64url(Serial)

HTTP/1.1 200 OK
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end":   "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

클라이언트는 창 안에서 무작위 시점을 골라 갱신하고, Retry-After 간격으로 창이 바뀌었는지 다시 확인합니다. 갱신 주문에는 replaces 필드로 이전 인증서를 명시할 수 있는데, 이게 CA 정책에 따라 갱신 식별·레이트 리밋 처리에 쓰입니다. 만료된 인증서에 대해서는 더 묻지 않는 것(MUST NOT)까지 RFC가 정해 뒀습니다.

이 프로토콜의 진짜 가치는 평시가 아니라 사고 때 나옵니다. CA가 대량 폐지를 해야 하는 상황 — Let's Encrypt는 2022년 1월 TLS-ALPN-01 검증 오류로 약 200만 장을 폐지한 적이 있습니다 — 에서 CA는 갱신 창을 앞당겨 응답하고, ARI를 보는 클라이언트는 폐지가 집행되기 전에 교체를 끝냅니다. 24시간·5일짜리 폐지 시한 안에 사람이 개입하는 프로세스는 대부분의 사이트에 닿지 못합니다. Shopify의 사례가 교과서적입니다 — 수백만 도메인을 "만료 30일 전 + 0~72시간 지터"로 굴리다가, Ruby acme-client 젬에 ARI 지원을 직접 기여하고 갱신 타이밍 결정을 CA에 위임했습니다(효과 서술은 Shopify 자체 보고입니다 — 정량 수치는 공개돼 있지 않습니다).

클라이언트별 현황은 이렇습니다. 전부 원문 체인지로그·문서에서 확인한 것입니다.

  • certbot — 4.1.0(2025-06-10)부터 certbot renew가 ARI를 자동 확인합니다. Let's Encrypt 기준으로 대략 수명의 3분의 2 지점 갱신이 되고, 5.0.0부터는 Retry-After를 실행 간에 보존합니다.
  • lego — CLI가 명시적으로 끄지 않는 한 ARI를 확인하며, replaces 필드까지 구현돼 있습니다.
  • Caddy/CertMagic — README가 RFC 9773 전체 지원을 명시합니다.
  • cert-manager — 가장 최근에 합류했습니다. v1.21.0(2026-07-08)이 ACMEUseARI 피처 게이트 뒤에 ARI 지원을 넣었습니다. 2023년 5월에 열린 요청 이슈가 3년 만에 움직인 것인데, 아직 기본 활성이 아닙니다. 쿠버네티스에서 인증서를 굴린다면 — cert-manager 실전 편에서 다룬 그 스택입니다 — 업그레이드와 게이트 활성화를 따로 챙겨야 한다는 뜻입니다.

ARI가 없는 클라이언트에 남는 차선책은 Let's Encrypt의 권고대로 "수명의 3분의 2 지점 갱신"을 지키는 것입니다. 45일 인증서면 30일 차입니다. 고정 60일 주기 같은 설정은 45일 시대에 그냥 장애입니다.

아직 안 온 것 — DNS-PERSIST-01의 현재 위치

수명 단축의 마지막 퍼즐은 검증 자동화입니다. 재사용 기간이 무너지면 검증을 자주 해야 하는데, 지금의 DNS-01은 갱신마다 새 토큰을 TXT 레코드로 써야 해서 DNS API 자격증명이 발급 파이프라인 곳곳에 흘러 다니게 됩니다. 그래서 나온 것이 DNS-PERSIST-01입니다 — 한 번 심어두면 갱신마다 바꿀 필요가 없는, CA와 ACME 계정을 지목하는 상시 인가 레코드입니다.

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

policy=wildcard를 붙이면 와일드카드·서브도메인까지 커버하고, 상시 인가가 불편하면 persistUntil로 만료를 걸 수 있습니다. 제도 쪽 정비는 끝났습니다 — CA/B Forum 투표 SC-088v3가 2025년 10월 만장일치로 통과돼 현행 BR 3.2.2.4.22("DNS TXT Record with Persistent Value")로 들어갔고, IP 주소용 _ip-validation-persist 변형도 함께 실렸습니다.

그런데 실물은 아직입니다. 2월 공지의 목표는 "스테이징 1분기 말, 프로덕션 2분기"였지만, 지금 시점의 실제 상태는 이렇습니다 — 스테이징에는 드래프트 구현이 올라가 있고(4월 말 draft-01 반영으로 accounturi가 챌린지 객체 필수 필드가 됐습니다), 프로덕션은 열리지 않았습니다. Let's Encrypt 엔지니어가 6월 25일 커뮤니티 포럼에 남긴 답이 현재 상태를 정확히 요약합니다 — 드래프트 이슈 #64(레코드에 클라이언트 계산 정보를 넣을지)가 풀리기 전에는 배포하지 않겠다는 것입니다. 5월에는 "IETF 합의가 늦으면 3분기로 밀릴 수 있다"는 답도 있었습니다. 공식 챌린지 타입 문서에도 아직 등재되지 않았습니다. 요컨대 지금 DNS-PERSIST-01을 전제로 아키텍처를 짜면 안 되고, 스테이징 실험까지만 가능합니다.

설계상의 트레이드오프도 공지문이 스스로 짚습니다 — DNS 쓰기 자격증명을 파이프라인에서 치우는 대신, 상시 인가가 ACME 계정에 묶이므로 계정 키가 새로운 최중요 비밀이 됩니다. 계정 키 보관과 회전 체계 없이 쓰면 위험을 옮긴 것에 불과합니다.

그래서 무엇을 준비해야 하나

일정표를 운영 언어로 번역하면 이렇습니다.

  1. 인벤토리부터. 수동 갱신되는 인증서 — 연 1회 달력 알림, 분기별 티켓, 장비 콘솔에 파일 업로드 — 를 찾아내는 게 첫 일입니다. 200일 시대에는 연 2회 수작업으로 버틸 수 있지만, 100일이면 연 4회, 47일이면 대략 매달입니다. 수작업의 문제는 횟수가 아니라, 횟수가 늘수록 한 번의 누락 확률이 곱해진다는 데 있습니다.
  2. 클라이언트 버전과 ARI. certbot 4.1 미만, ARI 없는 자체 스크립트, 고정 주기 cron이 있다면 지금 올리세요. 갱신 시점 판단을 CA에 위임하는 것이 이 일정 전체에 대한 가장 값싼 보험입니다.
  3. 모니터링은 갱신 성공이 아니라 만료 임박을 봐야 합니다. 갱신 파이프라인이 조용히 죽는 경우가 시끄럽게 실패하는 경우보다 위험하고, 수명이 짧아질수록 "조용히 죽은 채 버틸 수 있는 기간"도 짧아집니다. 45일 인증서에서 2주짜리 휴가 시즌 장애는 만료 사고입니다.
  4. 검증 경로의 자동화. 2027-02-10부터 Let's Encrypt 기본 프로파일의 인증 재사용이 10일로 줄고, 2028년에는 7시간이 됩니다. 갱신만 자동이고 검증(특히 DNS-01의 TXT 갱신)이 반자동인 구성은 여기서 깨집니다. DNS-PERSIST-01이 프로덕션에 오기 전까지는 DNS 자격증명 관리를 감수하든, HTTP-01/TLS-ALPN-01로 옮기든 결정이 필요합니다.
  5. 단기 프로파일은 마지막에. 폐지 걱정을 지우는 6일 인증서는 매력적이지만, 그 전에 45일에서 무사고로 몇 분기를 보내는 게 순서입니다.

반대로, 이 일정이 강제하지 않는 것도 분명히 해 두겠습니다. BR의 적용 범위는 "인터넷에서 접근 가능한 서버 인증용" 공개 신뢰 인증서입니다. 사설 CA로 굴리는 내부 PKI, 폐쇄망 장비, mTLS용 내부 인증서는 이 일정과 무관하게 수명을 스스로 정합니다. 공개 신뢰가 꼭 필요하지 않은 내부 시스템이 47일 주기를 감당할 수 없다면, 자동화 대신 사설 PKI로 옮기는 것도 정답의 하나입니다 — 이 판단 자체는 무중단 갱신 플레이북에서 다룬 운영 원칙의 연장선입니다.

마치며

정리합니다. 날짜는 확정입니다 — 200일(이미 시행), 2027-03-15부터 100일, 2029-03-15부터 47일, 그리고 같은 날 검증 재사용 10일. Let's Encrypt는 거기에 자기 일정을 얹었습니다 — 2027-02-10에 기본 64일, 2028-02-16에 기본 45일. 도구도 대부분 와 있습니다 — ARI는 RFC가 됐고 주요 클라이언트에 들어갔으며, 6일짜리 인증서는 GA입니다. 아직 안 온 것은 DNS-PERSIST-01의 프로덕션 배포 하나이고, 그마저 제도와 스테이징은 끝나 있습니다.

그러니 남은 변수는 표준도 CA도 아니고 각자의 운영입니다. 47일 시대의 실패 모드는 "갱신을 잊음"이 아니라 "자동화가 조용히 죽어 있었음"입니다. 지금 할 일은 달력에 갱신 알림을 더 촘촘히 박는 게 아니라, 알림 없이도 돌아가는 파이프라인과 그 파이프라인이 죽었을 때 울리는 경보를 만드는 것입니다.

참고 자료

Discuss on Twitter • View on GitHub