품질·성능·보안 · 공식 문서
ssl 인증서 갱신 주기, 단축 일정과 자동 갱신 순서
공개 인증서의 최장 유효기간은 2026-03-15 발급분부터 200일이고, 2029-03-15 발급분부터 47일까지 줄어듭니다. 갱신은 고정 날짜가 아니라 수명의 약 3분의 2 지점에서 하도록 자동화하고, 갱신 뒤 서버 반영과 실패 알림까지 함께 걸어 둡니다.
1년에 한 번 하던 갱신은 잊기 쉽습니다. 그 1년 주기는 2026-03-15 발급분부터 끝났습니다.
CA/B 포럼은 공개 인증서의 최장 유효기간을 단계적으로 줄이기로 정했습니다. 갱신 횟수가 늘수록 갱신은 사람 손보다 자동화에 맡기는 편이 안전합니다.
발견 01
공개 인증서의 최장 유효기간은 3차례 줄어 2029-03-15 발급분부터 47일입니다
Eventual reduction of maximum validity period from 398 days to 47 days These reductions are proposed to occur starting in March 2026 and concluding in March 2029
최장 유효기간을 결국 398일에서 47일로 줄인다. 단축은 2026년 3월에 시작해 2029년 3월에 끝난다.
| 발급일 | 최장 유효기간(일) |
|---|---|
| 2026-03-15 전 발급 | |
| 2026-03-15부터 2027-03-15 전까지 발급 | |
| 2027-03-15부터 2029-03-15 전까지 발급 | |
| 2029-03-15부터 발급 |
| 발급일 | 공식 문서 원문 |
|---|---|
| 2026-03-15 전 발급 | Subscriber Certificates issued before 2026-03-15 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.2026-03-15 전에 발급한 인증서는 유효기간이 397일을 넘지 않는 것이 좋고, 398일을 넘으면 안 된다. |
| 2026-03-15부터 2027-03-15 전까지 발급 | Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days.2026-03-15부터 2027-03-15 전까지 발급한 인증서는 199일을 넘지 않는 것이 좋고, 200일을 넘으면 안 된다. |
| 2027-03-15부터 2029-03-15 전까지 발급 | Subscriber Certificates issued on or after 2027-03-15 and before 2029-03-15 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days.2027-03-15부터 2029-03-15 전까지 발급한 인증서는 99일을 넘지 않는 것이 좋고, 100일을 넘으면 안 된다. |
| 2029-03-15부터 발급 | Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.2029-03-15부터 발급한 인증서는 46일을 넘지 않는 것이 좋고, 47일을 넘으면 안 된다. |
이 일정은 인증서를 발급하는 기관(CA)이 따라야 하는 규칙입니다. 브라우저가 신뢰하는 공개 인증서라면 유료든 무료든 같은 상한을 받습니다.
기준은 발급일입니다. 이미 받은 인증서는 받은 날의 상한을 그대로 쓰고, 다음 갱신부터 그때의 상한이 적용됩니다.
발견 02
갱신 주기는 날짜를 정해 두는 방식이 아니라 수명의 약 3분의 2 지점에서 하는 방식입니다
Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime.
지금 인증서 수명의 약 3분의 2 지점에서 갱신하는 것이 허용되는 방식이다.
| 최장 유효기간(일) | 3분의 2 지점(일째) | 남은 기간(일) |
|---|---|---|
| 398 | 265 | 133 |
| 200 | 133 | 67 |
| 100 | 67 | 33 |
| 47 | 31 | 16 |
| 항목 | 공식 문서 원문 |
|---|---|
| 고정 일수의 한계 | For example, renewing at a hardcoded interval of 60 days will no longer be sufficient.예를 들어 60일 고정 간격으로 갱신하는 방식은 더 이상 충분하지 않다. |
| Certbot 갱신 기준 | As of Certbot 4.0.0, a certificate is considered ready for renewal when less than 1/3rd of its lifetime remains.Certbot 4.0.0부터는 수명이 3분의 1 미만 남았을 때 갱신 대상으로 본다. |
| 갱신 시점 안내(ARI) | To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI).ACME 클라이언트가 제때 갱신하도록 ACME Renewal Information(ARI)을 쓰기를 권한다. |
| 수동 갱신 | Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes.유효기간이 짧아지면 더 자주 해야 하므로 수동 갱신은 권하지 않는다. |
| 무료 CA 기본값 변경 | On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced).2027년 2월 10일부터 Let's Encrypt 기본 인증서는 64일짜리가 된다. 더 짧은 45일·6일을 고를 수도 있다. |
발견 03
자동 갱신은 갱신·서버 반영·실패 알림 세 부분, 7단계를 다 걸어야 끝납니다
We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren’t renewed when expected.
인증서가 기대한 때에 갱신되지 않으면 알림이 가도록 충분한 모니터링을 갖추기를 권한다.
| 단계 | 부분 | 할 일 | 공식 문서 원문 |
|---|---|---|---|
| 갱신 주체 확인 | 갱신 | 호스팅·CDN이 인증서를 자동으로 바꿔 주는지, 서버의 ACME 클라이언트가 갱신하는지 먼저 가립니다. | Most users of Let’s Encrypt who automatically issue certificates will not have to make any changes. However, you should verify that your automation is compatible with certificates that have shorter validity periods.자동으로 발급받는 사용자 대부분은 바꿀 것이 없다. 다만 자동화가 더 짧은 유효기간과 맞는지 확인해야 한다. |
| 예약 작업 확인 | 갱신 | 서버에서 갱신 명령이 crontab 이나 systemd 타이머에 걸려 있는지 봅니다. | Most Certbot installations come with automatic renewals preconfigured. To do so, look for the certbot renew command in either your system’s crontab (typically /etc/crontab or /etc/cron.*/*) or systemd timers (systemctl list-timers).Certbot 설치본 대부분은 자동 갱신이 미리 설정돼 있다. 시스템 crontab 이나 systemd 타이머에서 certbot renew 명령을 찾아 확인한다. |
| 수동 발급 확인 | 갱신 | 수동 방식으로 받은 인증서는 인증 훅 스크립트를 붙이거나 자동 방식으로 다시 받습니다. | Users of the Manual plugin should note that --manual certificates will not renew automatically, unless combined with authentication hook scripts.수동(--manual) 방식으로 받은 인증서는 인증 훅 스크립트를 붙이지 않으면 자동으로 갱신되지 않는다. |
| 고정 날짜 걷기 | 갱신 | 스크립트와 운영 문서에서 60·80·83 같은 고정 일수를 찾아 수명 비율(3분의 2) 또는 ARI 기준으로 바꿉니다. | For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you’re not sure.60일 고정 간격 갱신은 더 이상 충분하지 않다. 확실하지 않으면 예약 작업·래퍼 스크립트·운영 문서에서 83, 80, 60 같은 고정 숫자를 찾아본다. |
| 갱신 시험 | 갱신 | --dry-run 으로 실제 인증서를 저장하지 않고 갱신 과정을 시험합니다. | --dry-run Test "renew" or "certonly" without saving any certificates to disk--dry-run 은 인증서를 디스크에 저장하지 않고 renew 나 certonly 를 시험한다. |
| 서버 반영 | 반영 | 갱신이 성공한 뒤에만 웹 서버를 다시 읽게 하는 훅을 걸고, 여러 서버·CDN에 배포하는 단계도 자동으로 둡니다. | If you want your hook to run only after a successful renewal, use --deploy-hook in a command like this. This is also an opportunity to automate certificate management processes like reload and deployment and to add alerting for renewal failures.갱신이 성공한 뒤에만 훅을 돌리려면 --deploy-hook 을 쓴다. 다시 읽기와 배포 같은 인증서 관리 과정을 자동화하고 갱신 실패 알림을 더할 기회다. |
| 실패 알림 | 알림 | 만료 예정 인증서를 매일 검사해 기대한 때에 갱신되지 않으면 담당자에게 알림이 가게 합니다. | We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren’t renewed when expected.인증서가 기대한 때에 갱신되지 않으면 알림이 가도록 충분한 모니터링을 갖추기를 권한다. |
무료 인증 기관의 만료 안내 메일에 기대던 곳은 알림을 따로 세워야 합니다. Let's Encrypt 는 이 메일 발송을 끝냈습니다.
알림은 만료일을 직접 읽는 검사로 겁니다. 만료일 확인 명령은 「ssl 인증서 만료일 확인」 편에 자세히 적었습니다.
| 항목 | 공식 문서 원문 |
|---|---|
| 만료 안내 메일 | This service ended on June 4, 2025.이 서비스(만료 안내 메일)는 2025년 6월 4일에 끝났다. |
| 만료된 인증서와 구글 | Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.잘못된 TLS/SSL 인증서와 HTTPS에서 HTTP로 가는 리디렉션은 구글이 HTTP를 매우 강하게 고르게 만드므로 피한다. HSTS를 켜도 이 선호를 뒤집지 못한다. |
발견 04
같은 자동 갱신이라도 B2B·B2C·B2G 는 끊기기 쉬운 단계가 다릅니다
예시 ① 문의형 기업 사이트(B2B)
호스팅 업체가 인증서를 자동으로 바꿔 주는 경우입니다. 갱신 주체가 업체이므로, 계약서에 자동 갱신 포함 여부와 실패 때 연락 경로를 적어 둡니다.
직접 할 일은 실패 알림 하나입니다. 만료 30일 전 검사를 걸어 둡니다.
예시 ② 자사 쇼핑몰(B2C)
웹 서버 여러 대 앞에 CDN을 둔 경우입니다. 한 서버에서 갱신해도 다른 서버와 CDN에 배포가 빠지면 일부 방문자만 경고를 봅니다.
그래서 갱신 성공 뒤 배포까지 한 흐름으로 묶고, 호스트마다 만료일을 따로 검사합니다.
예시 ③ 공공기관 누리집(B2G)
연 단위 유지보수 계약에 「인증서 연 1회 갱신」이 적힌 경우입니다. 유효기간이 줄면 계약 기간 안에 갱신이 여러 번 필요합니다.
다음 계약의 과업 항목에는 횟수 대신 「자동 갱신 구성과 실패 알림」을 적습니다.
그럼 자동 갱신은 어떤 순서로 걸어 두나요?
- 갱신 주체 확인: 호스팅·CDN이 인증서를 자동으로 바꿔 주는지, 서버의 ACME 클라이언트가 갱신하는지 먼저 가립니다.
- 예약 작업 확인: 서버에서 갱신 명령이 crontab 이나 systemd 타이머에 걸려 있는지 봅니다.
- 수동 발급 확인: 수동 방식으로 받은 인증서는 인증 훅 스크립트를 붙이거나 자동 방식으로 다시 받습니다.
- 고정 날짜 걷기: 스크립트와 운영 문서에서 60·80·83 같은 고정 일수를 찾아 수명 비율(3분의 2) 또는 ARI 기준으로 바꿉니다.
- 갱신 시험: --dry-run 으로 실제 인증서를 저장하지 않고 갱신 과정을 시험합니다.
- 서버 반영: 갱신이 성공한 뒤에만 웹 서버를 다시 읽게 하는 훅을 걸고, 여러 서버·CDN에 배포하는 단계도 자동으로 둡니다.
- 실패 알림: 만료 예정 인증서를 매일 검사해 기대한 때에 갱신되지 않으면 담당자에게 알림이 가게 합니다.
조사 방법
- CA/Browser Forum 「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (Version 2.3.1)」 (문서 수정일 2026-10-04) · 최종 확인일 2026-10-25 · https://cabforum.org/working-groups/server/baseline-requirements/requirements/
- CA/Browser Forum 「Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods」 (문서 수정일 2025-04-11) · 최종 확인일 2026-10-25 · https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
- Let's Encrypt 「Decreasing Certificate Lifetimes to 45 Days」 (문서 수정일 2025-12-02) · 최종 확인일 2026-10-25 · https://letsencrypt.org/2025/12/02/from-90-to-45
- Let's Encrypt 「64-Day Certificate Lifetimes Coming Feb 2027」 (문서 수정일 2026-10-07) · 최종 확인일 2026-10-25 · https://letsencrypt.org/2026/10/07/64-day-certs
- Let's Encrypt 「Expiration Notification Service Has Ended」 (문서 수정일 2025-06-26) · 최종 확인일 2026-10-25 · https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
- Certbot (EFF) 「User Guide (Certbot 5.8.0)」 · 최종 확인일 2026-10-25 · https://eff-certbot.readthedocs.io/en/stable/using.html
- Google Search Central 「How to specify a canonical URL with rel="canonical" and other methods」 (문서 수정일 2026-07-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- 유효기간 일정 4줄은 TLS Baseline Requirements 6.3.2절의 MUST NOT 상한입니다. 3분의 2 지점 표는 그 상한으로 계산한 값입니다.
- 자동 갱신 7단계는 위 문서들이 갱신 자동화에 대해 적은 일을 순서대로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다. 예시의 30일 기준은 설명을 위한 값입니다.
- 원문은 영어입니다. 구글 문서는 영어판(hl=en)을 인용했고, CA/B 포럼·Let's Encrypt·Certbot 문서는 한국어판이 없어 용어는 업계 표기를 따랐습니다.