SSL/TLS 인증서 유효기간 단축 (유료 인증서, 무료 인증서 포함)

최근 고객사 인증서 갱신 요청을 처리하다 보면 기존처럼 유효기간이 1년 아니라 6개월짜리 인증서가 발급되는 경우가 많아졌습니다. 처음에는 단순 정책 변경인가 싶었는데, 확인해 보니 세계 주요 인증 기관(CA)들이 SSL/TLS 인증서 유효기간 자체를 점차 단축하는 방향으로 정책을 변경하고 있다고 합니다.

 

현재의 6개월 정책도 1차적으로 줄어든 기간, 장기적으로는 최종 최대 유효기간을 약 45~47일 수준까지 단축하는 방향이 논의되었으며, 이미 정책이 통과되어 시행 중입니다. 왜 이렇게까지 인증서 기간을 줄이게 되었는지 의아할 수 있는데, 보안 업계에서는 이미 몇 년 전부터 인증서 자동화와 단기 인증서 체계를 중심으로 방향이 바뀌고 있었습니다. 이번 글에서는 인증서 유효기간이 점점 짧아지는 이유와, 앞으로 서버 운영 환경에서 어떤 변화가 생기게 되는지 한번 정리해 보도록 하겠습니다.

---

① 인증서 유효기간은 누가 정하는 것인가?

먼저 오해의 소지가 있을 수 있는 부분이 있는데, 이번 인증서 유효기간 단축은 단순히 인증서 판매 업체가 임의로 기간을 줄인 것이 아닙니다. 이는 CA/B 포럼(Certification Authority/Browser Forum)이라는 국제 보안 협의체에서 결정되는 정책입니다.

 

CA/B 포럼은 전 세계 주요 인증 기관(CA)과 브라우저 제조사가 함께 참여하는 국제 보안 정책 협의체로 볼 수 있습니다. 대표적으로 아래와 같이 참여하여 인터넷 인증서 정책과 보안 기준을 논의합니다.

◇ 인증 기관 (CA) : DigiCert, GlobalSign, Sectigo 등

◇ 브라우저(Browser) 및 플랫폼 제조사 : 구글 크롬(Chrome), 마이크로소프트 엣지(Edge), 애플 사파리(Safari) 등

◇ CA/B 포럼 공식 사이트 : https://cabforum.org/

◇ CA/B 포럼 투표 안건 : SC081v3 (2025-04-11)

이번 유효기간 단축 역시 2025년 4월 "인증서 유효기간 및 검증 데이터 재사용 기간 단축" 안건(SC081v3)이 상정되면서 논의가 시작되었습니다. 물론 반대도 존재했지만, 주요 인증 기관(CA)과 브라우저 제조사, 대형 인증서 소비 기업들이 다수 찬성하면서 최종 통과되었습니다. 즉, 특정 업체 하나가 독단적으로 결정한 것이 아니라 인터넷 생태계 전체 차원에서 방향성이 정해진 것에 가깝습니다.

 

→ 사실상 CA/B 포럼의 결정은 국제 표준처럼 적용됩니다.

전 세계 웹사이트 운영자, 서버 관리자, 메일 서비스 운영 업체들은 결국 이 정책에 맞춰 인증서를 관리해야 하기 때문입니다. 인증서 유효기간, 도메인 검증 방식(DCV, HTTP/DNS TXT/메일 인증), 인증서 재발급 정책, RSA / ECC 암호화 기준, 루트 인증서 정책, CA 인증 요구 사항, 브라우저 신뢰 체계 등 이 모든 것을 CA/B 포럼이 보안 정책 방향을 결정한다고 해도 과언이 아닙니다.

 

예전 SHA-1 폐기나 TLS 보안 강화 정책 역시 이런 흐름 속에서 진행되었습니다. 최근에는 RSA CA Key 최소 길이를 기존 2048bit에서 4096bit 더 높은 수준으로 강화하려는 움직임도 지속적으로 논의되고 있습니다. 단순 인증서 판매 정책이 아니라 인터넷 브라우저 신뢰 체계 전체를 결정하는 상위 보안 그룹이라고 봐도 무방합니다.

---

② SSL/TLS 인증서 유효기간 단축 일정

기간	SSL 인증서 최대 유효기간 단축 일정
~ 2020 9월 이전	2~10년 이상 장기 인증서 발급
2020 9월 ~ 2026년 3월	1년 (최대 398일 = 365일 + 약 한달) 형태로 발급
2026년 3월 15일부터 발급 시 ※ 이미 시행 중	인증서 최대 유효기간이 약 6개월(200일)로 단축 ※ 인증서 판매 업체는 계약은 동일하게 1년으로 하되 발급을 2회로 나누어 재발급 ※ 200일 = 최대 6개월(184일) + 30일 월의 1/2(15일) + 1일 여유(wiggle room)
2027년 3월 15일부터 발급 시	인증서 최대 유효기간이 약 3개월(100일)로 단축 ※ 1년에 약 4회 재발급 ※ 100일 = 최대 3개월(92일) + 30일 월의 약 1/4(7일) + 1일 여유(wiggle room)
2029년 3월 15일부터 발급 시	인증서 최대 유효기간이 약 1개월(47일)로 단축 ※ 1년에 약 8회 재발급 ※ 47일 = 최대 1개월(31일) + 30일 월의 1/2(15일) + 1일 여유(wiggle room)

 

※ 참고1 (SecureSign) : https://www.sslcert.co.kr/supports/announceView/114

※ 참고2 (Cloudnetworks) : https://www.cloudnetworks.co.kr/pr/blog/?mod=document&uid=322

---

③ 인증서 유효기간을 줄이는 이유?

 

→ 가장 큰 이유는 역시 보안 강화 때문입니다.

SSL/TLS 인증서는 서버와 사용자 사이의 통신을 암호화하는 역할을 하지만, 만약 인증서가 유출되거나 잘못 발급될 경우 장기간 악용될 가능성이 존재합니다.

 

예를 들어 과거처럼 1~10년짜리 장기 인증서를 사용하면 문제가 발생했을 때 해당 인증서가 오랜 기간 유효한 상태로 유지될 수 있습니다. 반면 인증서 유효기간이 짧아지면 설령 인증서가 유출되더라도 비교적 빠르게 만료되기 때문에 위험 노출 기간 자체를 줄일 수 있습니다.

 

최근 국내 통신사 보안 사고 사례에서도 이러한 문제가 있었습니다. 특히 모 통신사의 펨토셀(Femtocell) 사건의 경우, 과거에 발급된 장기 인증서(5~10년), 공용 인증서 사용, 인증 검증 부실 문제가 동시에 겹치면서 피해 규모가 커졌다는 분석이 있습니다. 정부 조사 결과에 따르면 모든 펨토셀이 동일한 인증서를 사용하고 있었으며, 유효기간도 무료 10년에 달했다고 합니다. 또한 한 번이라도 접속 이력이 있으면 동일 망에서 장기간 인증이 가능했고, 유출/복제된 장비의 고유 정보 검증 역시 충분하지 않았던 것으로 알려졌습니다.

 

이후 조치로는 인증서 유효기간을 기존 10년에서 1개월 수준으로 대폭 단축하고, 펨토셀이 동일 망에 접속을 시도하더라도 동일 유선 IP 환경이 아니면 차단하도록 변경되었습니다. 또한 망 접속 시 형상 정보 및 장비 인증 절차를 강화하고, 기존 공동 인증서 방식이 아닌 장비별 개별 인증서를 발급하는 방향으로 조치하였습니다.

 

→ 또 다른 이유는 운영 정보 최신화와 암호화 정책 유연성 유지 목적도 있습니다.

인증서에는 도메인 정보, 조직 정보, 암호화 알고리즘 등의 데이터가 포함되는데, 시간이 지나면서 운영 환경과 보안 기준은 계속 변경됩니다. 특히 최근에는 다음과 같은 변화 속도가 매우 빨라지고 있습니다.

 

구형 암호화 알고리즘 제거, SHA-1 같은 취약 기술 폐기, 인증 절차 강화, 도메인 검증 정책 강화, ACME 기반 자동화 인증서 관리 확대를 말합니다. 즉, 인증서를 자주 재발급하도록 만들면 최신 보안 정책과 암호화 기준을 보다 빠르게 반영할 수 있다는 의미입니다.

---

④ 서버 운영의 변화와 대처 방법

사실 인증서 수명 주기가 짧아지면 서버 운영자 입장에서는 귀찮아지는 부분도 분명 존재합니다. 예전에는 한번 발급하면 최소 1년 이상은 크게 신경 쓰지 않아도 되었지만, 앞으로는 약 6개월(200일 수준) → 최종적으로 약 1개월(45~47일) 수준까지 줄어들어 관리 포인트가 크게 늘어날 수 있습니다.

 

특히 다음과 같은 환경에서는 부담이 더 커질 수 있습니다. 오래된 서버 환경, 수동 인증서 갱신 방식, 여러 도메인을 동시에 운영하는 경우, 고객사 서버를 대신 관리하는 환경, IIS / Apache / Nginx 등에 수동 등록하는 구조 등...

 

물론 관리 부담을 줄이려면 하나의 호스팅 서버에 자동화 도구를 적용하거나 클라우드 기반 인증서 서비스를 사용하는 것이 가장 편합니다. 하지만 현실적으로 모든 기업이나 개인 사용자가 동일한 환경을 사용하는 것은 아닙니다. 직접 서버를 구축하거나 특수 소프트웨어 환경을 운영하는 경우에는 여전히 수동 작업 비중이 상당히 높을 수밖에 없습니다.

 

그럼 앞으로 어떻게 대응해야 하고, 선택지는 무엇일까?

→ 사실상 선택지는 거의 없습니다. 앞으로는 편하게 운영하려면 ACME / ARI 기반 자동 갱신 시스템이나 Certbot같은 자동화 도구를 사용하는 방향으로 갈 수밖에 없습니다.

 

ACME란?

ACME는 Automated Certificate Management Environment의 약자로, 말 그대로 SSL/TLS 인증서를 자동으로 발급, 갱신, 설치하기 위한 표준 프로토콜입니다.

 

이전에 작성했던 SSL/TLS 인증서 관련 포스팅에서도 한번 언급한 적이 있었지만, 예전에는 인증서를 갱신하려면 다음과 같은 과정을 사람이 직접 처리해야 했습니다. CSR 생성 → 인증 기관(CA) 업로드 → 도메인 검증(DCV) → 인증서 다운로드 → 서버 수동 업로드 및 적용 → 웹 서비스 재시작으로 여러 단계를 거쳐야 했지만 ACME를 이용하면 서버 ↔ 클라이언트단에서 바로 처리할 수 있게 됩니다.

 

대표적으로 무료 인증서 서비스인 Let's Encrypt가 ACME 대중화를 크게 이끌었다고 볼 수 있습니다. 현재는 DigiCert, Sectigo 등 주요 인증 기관들도 대부분 ACME를 지원하고 있습니다.

ARI란?

ARI는 ACME Renewal Information의 약자로, 인증서를 언제 갱신하면 좋은지 인증 기관(CA)이 직접 클라이언트에게 알려주는 기능입니다. 쉽게 말해 대규모 자동 갱신 제어 시스템에 가깝습니다.

 

기존에는 클라이언트가 자체적으로 만료 30일 전 갱신 같은 정책을 기준으로 동작했습니다. 하지만 인증서 유효기간이 극단적으로 짧아지면 문제가 발생할 수 있습니다. 예를 들어 전 세계 수억 대 서버가 동시에 "만료 30일 전 오전 0시" 기준으로 갱신 요청을 보내게 되면, 인증 기관 서버에는 사실상 DDos 수준의 부하가 발생할 수 있습니다.

 

그래서 이제는 인증 기관(CA)이 직접 클라이언트에게 특정 시간대에 갱신하도록 유도하거나, 요청량이 많으면 조금 늦게 생산하도록 안내하는 등 서버 부하 상태에 따라 갱신 타이밍을 분산시키는 방식으로 정보를 제공하게 됩니다. 즉 ARI는 갱신 트래픽 분산, 대규모 인증서 폭주 방지, CA 서버 안정성 확보, 자동화 환경 최적화를 위한 기술이라고 볼 수 있습니다.

 

예전에 작성했던 Let's Encrypt(무료 인증서) 자동 갱신 관련 글에서도 이미 한번 언급한 적이 있었는데, 작성 시점이 5년 전이라 현재 기준에서는 다소 구식 정보가 된 부분도 있습니다. 기회가 된다면 최근 인증 정책과 ACME / ARI 환경 변화 기준으로 다시 한번 새롭게 정리해 볼 생각입니다.

 

---

◈ PS. Let's Encrypt 무료 인증서 근황

◇ 공식 홈페이지 : https://letsencrypt.org/

◇ 인증서 단축 예정 : https://letsencrypt.org/2025/12/02/from-90-to-45

 

현재 유효 기간은 동일하게 약 3개월(90일)이며, 2028년까지 유효 기간이 절반으로 단축되어 45일로 단축될 예정이라고 합니다. 동일하게 CA/B 포럼 기준선 요구사항에 따라가며, Let's Encrypt와 같은 모든 공개 신뢰받는 인증 기관들도 유사한 변화를 도입합니다.

 

좀 더 다양한 서비스 지원

◇ 6일 및 IP 주소 인증서 제공 : https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability

◇ DNS 기반 검증(DNS-PERSIST-01) 지원 : https://letsencrypt.org/2026/02/18/dns-persist-01

 

---

마치며

제 개인적인 생각은 보안 관점에서는 분명 긍정적인 방향이라고 볼 수 있습니다. 하지만 실제 서버를 운영하는 입장에서는 조금 다른 문제도 존재합니다. 특히 웹 서비스(HTTP/HTTPS)는 비교적 ACME 자동화 구성이 잘 되어 있는 편이지만, SMTP 기반 메일 서비스나 일부 특수 서비스들은 아직도 수동 작업 비중이 상당히 높습니다.

 

예를 들어 SMTP(SMTPTLS), SMTPS(465), IMAPS(995), POP3S(993), 관리자 콘솔, 내부 릴레이 서버등 여러 서비스가 각각 인증서를 참조하는 경우가 많고, 서비스별 재적용 방식도 전부 다릅니다. 더 큰 문제는 일부 서비스들은 인증서 교체 후 "무조건 재시작"이 필요하다는 점입니다.

 

인증서 갱신 주기가 짧아질수록, 서버 재시작 빈도 증가 → 운영자의 작업 피로도 증가 → 야간작업 증가 → 갱신 누락 가능성 증가 → 인증서 적용 실수 → 서비스 다운타임 증가 → 설정 파일 오타로 인한 장애, 같은 현실적인 운영 리스크도 같이 증가할 수 있습니다.

 

이번 인증서 유효기간 단축 정책은, 단순히 기간만 줄이는 것이 아니라 인증서 관리 자동화를 전제로 한 방향에 가깝다고 볼 수 있습니다. 그래서 단계적으로 2029년까지 점차 인증서 기간을 줄이는 방향으로 의견이 통과되었지만, 한편에서는 보안을 위해 인증서를 지나치게 자주 교체하다가 오히려 사람 손을 타는 작업이 늘어나 장애 위험이 커지는 것 아니냐는 우려의 목소리도 있습니다.

 

그럼에도 최근 사이버 범죄, 피싱/스팸 공격, 공급망 공격, 각종 크리티컬 보안 이슈가 매우 빠르게 증가하고 있는 IT 환경을 생각하면, 전체적인 보안 수준 강화를 위해서는 피할 수 없는 흐름으로 보이기도 합니다. 앞으로는 단순히 서버를 운영하는 수준을 넘어, 인증서 자동화와 모니터링까지 포함한 관리 체계를 얼마나 잘 구축하느냐가 더욱 중요해질 것 같습니다. 관리자 입장에서는 또 하나의 숙제가 늘어난 셈이네요.