Let's Encrypt, 2027년 2월부터 인증서 수명 64일로 단축

출처: Let's Encrypt 공식 블로그 (Sarah Gran)
원문: https://letsencrypt.org/2026/10/07/64-day-certs.html
작성자: 팔복소프트-김팔복

한눈에 보기

• 2027년 2월 10일부터 Let's Encrypt가 새로 발급하거나 갱신하는 인증서의 기본 유효기간이 90일에서 64일로 줄어듭니다.
• 2026년 10월 14일부터 staging 환경에서 먼저 64일 인증서를 발급하니, 운영 전환 전에 여기서 테스트할 수 있습니다.
• 이미 발급된 인증서는 폐기(revoke)하지 않으며, 마지막 90일 인증서는 2027년 5월 11일쯤 만료될 예정입니다.
• ARI(ACME Renewal Info)를 지원하는 클라이언트로 자동 갱신 중이라면 따로 손댈 것이 없습니다.
• 만료 며칠 전에 갱신하도록 날짜를 고정해 둔 스크립트는 수명의 약 ⅔ 시점에 갱신하도록 바꿔야 합니다.
• 도메인 인증(authorization) 재사용 기간도 30일에서 10일로 줄고, 2028년에는 7시간이 됩니다.
• 2028년 기본값 45일로 가는 중간 단계이며, rate limit, ACME 엔드포인트, 체인은 그대로입니다.

배경: 왜 계속 짧아지나

Let's Encrypt는 무료 TLS 인증서를 ACME 프로토콜로 자동 발급해 주는 비영리 인증기관(CA)입니다. 국내에서도 개인 서비스부터 스타트업 운영 서버, 사내 개발 서버까지 HTTPS를 붙일 때 가장 먼저 떠올리는 선택지입니다.

수명이 짧을수록 개인키 유출이나 잘못 발급된 인증서가 악용될 수 있는 기간도 짧아집니다. 폐기 목록(CRL, OCSP)은 브라우저마다 동작이 달라 믿기 어렵기 때문에, 업계는 "오래 살지 않는 인증서" 쪽으로 움직여 왔습니다. 이번 공지는 이미 발표된 45일 계획 사이에 64일이라는 중간 단계를 두고 날짜를 확정한 것입니다.

그림 1. 64일 인증서 전환 일정 (팔복소프트 작성)

무엇이 달라지나

기본 수명: 90일 → 64일

2027년 2월 10일 이후 발급·갱신되는 인증서는 따로 고르지 않는 한 모두 64일짜리입니다. 더 짧은 수명을 원하면 이전에 공지된 45일 또는 6일 프로필을 선택할 수 있습니다. 기존 90일 인증서는 남은 기간 동안 그대로 쓰이고, 자연스럽게 만료되면서 사라집니다.

그림 2. 선택할 수 있는 인증서 수명 비교 (팔복소프트 작성)

인증 재사용 기간: 30일 → 10일 → 7시간

도메인 소유 검증 결과를 다시 쓸 수 있는 기간이 30일에서 10일로, 2028년에는 7시간으로 줄어듭니다. Let's Encrypt는 2029년에 예정된 검증 재사용 기간 상한 축소에 맞추고, 검증 데이터가 7시간을 넘으면 CAA 레코드를 다시 확인하는 절차("CAA rechecking")를 없애려는 목적이라고 설명합니다. 클라이언트를 일부러 재사용에 의존하도록 만들지 않았다면 바꿀 것은 없습니다.

바뀌지 않는 것

내 서버는 괜찮을까: 점검 포인트

대응은 두 갈래입니다. ARI를 지원하는 ACME 클라이언트를 쓰거나, 하드코딩된 갱신 날짜를 "수명의 ⅔ 시점" 기준으로 바꾸는 것입니다. ARI는 CA가 클라이언트에게 갱신 시점을 알려주는 방식이라, 수명이 또 바뀌어도 설정을 고칠 필요가 없습니다.

하드코딩 위치를 모르겠다면 cron, 래퍼 스크립트, runbook에서 83, 80, 60 같은 숫자를 찾아보라고 권합니다. 90일 수명을 전제로 갱신 주기를 계산한 흔적입니다.

# 갱신 주기를 숫자로 박아둔 곳 찾기
grep -rnE '\b(83|80|60)\b' /etc/cron* /opt/scripts ~/runbooks 2>/dev/null

We recommend testing in staging before the change takes effect in production.
— Let's Encrypt

이참에 reload·배포 자동화와 갱신 실패 알림까지 갖추라는 권고도 있습니다.

팔복소프트 관점

• certbot 기본 설정만 쓰는 서버는 대체로 안전합니다. 문제는 "누가 예전에 짜 둔 스크립트"입니다. 국내 현장에서는 인증서 파일을 받아 로드밸런서, CDN, WAS(Tomcat keystore 변환 등)에 손으로 옮기는 반자동 구조가 흔합니다. 발급만 자동이고 배포가 수동이면, 수명이 짧아지는 만큼 사람 손이 더 갑니다.
• 진짜 위험은 갱신이 아니라 배포와 reload입니다. 갱신은 됐는데 Nginx를 reload하지 않아 옛 인증서가 그대로 만료되는 사고가 흔합니다. deploy hook으로 reload를 묶고, 실제 서비스 중인 인증서 만료일을 외부에서 감시하세요.
• Kubernetes의 cert-manager, Caddy, Traefik처럼 갱신을 플랫폼이 맡는 환경은 영향이 작습니다. 다만 쓰는 버전의 ARI 지원 여부는 문서에서 확인해 두세요. 업데이트가 끊긴 클라이언트나 오래된 래퍼 스크립트를 쓰고 있다면 지금이 교체 시점입니다.
• 인증 재사용 단축은 DNS 수동 검증을 쓰는 팀에 더 아픕니다. 와일드카드 인증서를 TXT 레코드를 손으로 넣어 받고 있다면 검증을 훨씬 자주 해야 합니다. DNS 제공자 API 연동 자동화로 넘어갈 이유가 생겼습니다.
• 이번 64일은 사실상 2028년 45일을 위한 리허설입니다. 지금 ⅔ 규칙이나 ARI로 바꿔 두면 다음 단계에서는 할 일이 없고, 지금 숫자만 64에 맞춰 고치면 같은 작업을 또 하게 됩니다.
• 상용 CA 인증서만 쓰는 곳은 당장 이 공지와 무관합니다. 다만 수명 단축은 업계 전반의 흐름이라, 담당자가 가끔 손으로 교체하는 운영 방식 자체를 점검해 볼 때입니다.

정리

기억할 것은 날짜 두 개입니다. 2026년 10월 14일 staging에서 먼저 테스트할 수 있고, 2027년 2월 10일부터 운영 인증서가 64일로 바뀝니다. 핵심은 숫자를 64에 맞추는 것이 아니라 수명이 얼마든 상관없는 구조로 바꾸는 것입니다. ARI 지원 클라이언트, ⅔ 시점 갱신, reload까지 묶은 자동화, 실패 알림을 갖췄는지 확인하세요.

• Let's Encrypt
• SSL/TLS 인증서
• ACME
• certbot
• 서버 운영