SSL 인증서 유효기간 단축 - 1년에서 47일로, 무료 SSL 인증서 대응법

 

SSL 인증서 유효기간이 점점 짧아지고 있습니다. 그동안 약 1년(398일)이던 공개 TLS 인증서 최대 수명이 2026년 200일, 2027년 100일, 그리고 2029년에는 47일까지 단계적으로 줄어듭니다. 인증서를 수동으로 갱신해 온 분들에겐 부담이 커지는 변화인데요, 이 글에서는 단축 일정과 함께 무료 SSL 인증서(Let's Encrypt, Cloudflare, AWS CloudFront)로 대응하는 방법을 정리했습니다.

 

 

"또 인증서 만료됐다고 알림 왔네."
"이거 작년에 갱신한 거 아니었어요?"
"원래 1년짜리였는데, 듣기로는 앞으로 훨씬 더 짧아진다던데."

 

 

서버 운영을 해보신 분이라면 인증서 만료 알림이 얼마나 반갑지 않은 메일인지 아실 겁니다. 갱신 깜빡했다가 사이트에 빨간 경고창 뜨고, 사용자한테 "사이트 안 들어가져요" 문의 받고 나서야 부랴부랴 손대본 경험, 저만 있는 건 아닐 거예요. 그런데 이게 앞으로는 훨씬 더 자주 겪어야 할 일이 됐습니다.

1년에 한 번 갱신하던 걸 나중에는 1년에 여덟 번 가까이 해야 한다는 얘기입니다. 서버를 직접 운영하는 분, 개인 블로그나 사이드 프로젝트를 돌리는 분 모두에게 해당하는 변화라 차근차근 짚어보겠습니다.

📋 목차

1. SSL 인증서 수명, 왜 자꾸 줄어드나
2. SSL 인증서 유효기간 단축 일정 (398 → 200 → 100 → 47일)
3. 인증서 수명을 줄이는 진짜 이유 - 폐기 체계의 실패
4. 인증서 수동 갱신 시대의 종말
5. OCSP 종료와 인증서 폐기(revocation) 이야기
6. 무료 SSL 인증서로 해결하는 두 가지 방법
7. Let's Encrypt 자동 갱신 - ACME로 자동화하기
8. Cloudflare·CloudFront 무료 SSL - CDN에 맡기기
9. 개인 블로그·소규모 사이트의 SSL 인증서

1. SSL 인증서 수명, 왜 자꾸 줄어드나

SSL 인증서 수명을 결정하는 곳은 개별 인증기관(CA)이 아니라 CA/Browser Forum이라는 협의체입니다. CA들과 브라우저 제조사(Apple, Google, Mozilla, Microsoft)가 모여서 "공개적으로 신뢰받는 인증서는 이런 규칙을 지켜야 한다"는 기준선을 정하는 곳이에요.

수명 단축은 갑자기 튀어나온 얘기가 아닙니다. 2019년에 Google이 90일짜리 인증서를 제안했다가 한 번 부결됐고, 2023년에 다시 꺼냈습니다. 그러다 2024년 가을 Apple이 더 공격적인 안을 들고 나왔고, 2025년 4월 CA/Browser Forum이 이걸 정식으로 통과시켰습니다. Ballot SC-081v3라는 안건인데, 반대표가 단 한 표도 없었습니다.

방향 자체가 정해진 셈이라, "이거 안 지키면 어떻게 되나요?" 같은 질문은 의미가 없습니다. 기준을 안 지킨 인증서는 브라우저가 신뢰하지 않으니까요. 따라야 하는 흐름이라고 보시면 됩니다.

2. SSL 인증서 유효기간 단축 일정 (398 → 200 → 100 → 47일)

일정은 단계적입니다. 한 번에 47일로 떨어지는 게 아니라 몇 년에 걸쳐 내려갑니다. 인증서 유효기간이 줄어드는 시점을 정리하면 이렇습니다.

반응형

적용 시점	최대 수명	대략	도메인 검증 재사용
~2026년 3월 15일	398일	약 13개월	기존
2026년 3월 15일~	200일	약 6개월	200일
2027년 3월 15일~	100일	약 3개월	단축
2029년 3월 15일~	47일	약 6~7주	10일

지금이 2026년 6월이니 이미 200일 구간에 들어와 있습니다. 새로 발급받는 인증서는 최대 200일짜리예요. 그러니까 "예전엔 1년이었는데 왜 6개월밖에 안 나오지?" 싶으면 버그가 아니라 이 규칙 때문입니다.

 

 

📌 47일이라는 숫자, 왜 이렇게 어정쩡할까요?

깔끔하게 45일이나 50일이 아닌 데는 이유가 있습니다.

동그란 숫자면 사람이

"두 달에 한 번 수동으로 갱신하면 되겠네"라고 착각하기 쉬운데,

47일처럼 애매하게 만들어 두면 그게 불가능해집니다.

사실상 자동화하라는 압박인 셈이죠.

 

 

여기서 짚어둘 게 있습니다. 이 규칙은 공개적으로 신뢰받는 인증서에만 적용됩니다. 사내망에서 자체 운영하는 사설 CA는 해당하지 않아요. 인트라넷이나 내부 API용으로 사설 인증서 쓰시는 분들은 이 일정에 끌려갈 필요는 없습니다. 다만 외부 사용자가 브라우저로 접속하는 서비스라면 예외 없이 적용됩니다.

3. 인증서 수명을 줄이는 진짜 이유 - 폐기 체계의 실패

"왜 굳이 이렇게까지 짧게 만들까"를 이해하려면 인증서 폐기(revocation)가 어떻게 동작해 왔는지를 봐야 합니다.

인증서의 개인키가 유출됐다고 가정해 보겠습니다. 원래대로라면 "이 인증서는 더 이상 믿지 마세요"라고 알려야 합니다. 그게 폐기예요. 그런데 이 폐기 통보 체계가 오랫동안 제대로 작동하지 않았습니다. 브라우저가 폐기 여부를 확인하지 않거나, 확인해도 보안상 의미가 없는 방식으로 처리하는 경우가 많았거든요.

그래서 나온 발상이 "폐기가 안 믿음직하면, 애초에 인증서를 빨리 만료시키자"입니다. 1년짜리 인증서가 유출되면 최악의 경우 1년 가까이 위험이 노출되지만, 47일짜리라면 그 창이 한 달 반으로 쪼그라듭니다. 키가 털려도 금방 알아서 죽으니까요.

여기에 양자컴퓨터 대비 같은 장기 과제도 깔려 있습니다. 언젠가 특정 암호 알고리즘이 깨졌을 때, 인증서 수명이 길면 교체에 1년 넘게 걸립니다. 짧으면 몇 주 안에 생태계 전체가 새 알고리즘으로 갈아탈 수 있고요. 위기 상황에서 빠르게 움직일 수 있는 여지를 확보하는 셈입니다.

논리 자체는 탄탄합니다. 다만 그 비용을 운영자가 떠안는다는 게 문제죠.

4. 인증서 수동 갱신 시대의 종말

이 변화의 진짜 의미는 "갱신 주기가 짧아진다"가 아니라 "수동으로는 더 이상 감당이 안 된다"입니다.

인증서 100장을 관리한다고 해보겠습니다. 398일 시절엔 1년에 100번 갱신하면 됐어요. 47일이 되면 같은 100장이 1년에 800번 가까운 갱신 이벤트를 만들어냅니다. 사람이 캘린더에 만료일 적어두고 챙기는 방식으로는 빈틈이 안 생길 수가 없습니다.

저는 2016년 무렵부터 트러블슈팅 쪽 일을 많이 했는데, 인증서 만료로 서비스가 멈추는 사고는 생각보다 흔합니다. 그것도 꼭 금요일 저녁이나 연휴 직전에 터져요. 담당자가 퇴사하면서 갱신 캘린더가 같이 사라진다든가, "이건 누가 챙기지?" 하다가 아무도 안 챙긴 인증서가 조용히 죽는다든가. 1년에 한 번 겪던 이런 일을 앞으로는 훨씬 자주 만날 수 있다는 얘기입니다.

 

 

💡 갱신 주기가 짧을수록 장애 대응 여유도 줄어듭니다

90일짜리를 60일째 갱신하면 만일 실패해도 30일이라는 버퍼가 있습니다.

그런데 6일짜리를 2.5일마다 갱신하면 실패했을 때 남는 시간이 몇 시간 단위예요.

인증기관 쪽에 장애가 나면 그대로 서비스 만료로 직결될 수 있습니다.

짧은 수명은 보안엔 좋지만 외부 의존성에 더 민감해진다는 뜻이기도 합니다.

 

 

결론은 단순합니다. 자동 갱신을 안 해두면 언젠가 사고가 납니다. 그리고 그 "언젠가"가 점점 빨리 옵니다.

5. OCSP 종료와 인증서 폐기(revocation) 이야기

조금 더 깊이 들어가는 섹션이라 관심 있는 분만 보셔도 됩니다.

앞서 폐기 체계가 안 믿음직하다고 했는데, 그 폐기 확인 방식 중 하나가 OCSP(Online Certificate Status Protocol)였습니다. 브라우저가 인증서를 받을 때마다 CA 서버에 "이거 폐기됐어요?"라고 실시간으로 물어보는 방식이에요.

문제는 이게 프라이버시를 샌다는 점이었습니다. CA가 "누가 어떤 사이트를 방문하는지"를 실시간으로 알 수 있게 되거든요. 게다가 비용도 엄청났습니다. Let's Encrypt 한 곳만 해도 한때 초당 14만 건 가까운 OCSP 요청을 처리하고 있었습니다.

그래서 Let's Encrypt는 2025년 8월 OCSP 서비스를 완전히 종료했습니다. 이제 폐기 정보는 CRL(Certificate Revocation List)로만 제공합니다. 이게 의미하는 바는, 짧은 수명의 인증서가 보편화되면 "실시간 폐기 확인" 자체가 필요 없어진다는 겁니다. 어차피 며칠이면 만료되니 폐기를 따로 안 해도 위험이 알아서 사라지니까요. 폐기 체계를 고치는 대신 인증서 수명으로 문제를 우회한 셈입니다.

6. 무료 SSL 인증서로 해결하는 두 가지 방법

여기까지 보면 답은 명확합니다. 무료이면서 자동 갱신이 되는 방식으로 가는 거죠. 수명이 짧아질수록 인증서 가격보다 "자동화가 되느냐"가 훨씬 중요해지니까요. 그런데 여기서 흔히 헷갈리는 지점이 하나 있습니다. 무료 SSL이라고 다 같은 게 아니라는 점이에요.

 

 

💡 인증서를 "발급받아 설치"하는 것과, "프록시가 대신 처리"하는 건 다릅니다

Let's Encrypt나 ZeroSSL은 인증서를 발급해 주는 인증기관(CA)입니다.

제가 인증서를 받아서 제 서버에 직접 설치하는 구조예요.

반면 Cloudflare나 AWS CloudFront는 인증서를 발급하는 곳이라기보다

제 서버 앞에 끼어드는 CDN(콘텐츠 전송 네트워크) 겸 프록시입니다.

TLS를 엣지에서 대신 처리해 주는 거라,

"어디서 인증서를 받지?"라는 질문 자체가 성립하지 않습니다.

 

 

이 차이를 모르고 "Cloudflare도, CloudFront도 무료 인증서 주는 곳"이라고 뭉뚱그리면 나중에 헷갈립니다. 두 방식을 나눠서 정리하면 이렇습니다.

구분	A. CA에서 발급받아 설치	B. CDN·프록시가 대신 처리
대표 서비스	Let's Encrypt, ZeroSSL	Cloudflare, AWS CloudFront(+ACM)
정체	인증기관(CA)	CDN / 리버스 프록시
인증서 위치	내 서버에 직접 설치	엣지(CDN)에 존재
갱신 주체	내 ACME 클라이언트	Cloudflare / ACM이 자동 처리
통제 범위	종단 구간 전체	방문자↔엣지 구간
적합한 경우	서버 직접 운영	손 덜 가는 걸 원할 때 / AWS 환경

둘 중 뭐가 맞는지는 환경에 따라 다릅니다. 서버를 직접 만지고 종단 구간을 통제하고 싶으면 A, 그냥 신경 끄고 싶거나 이미 CDN을 끼고 있으면 B예요. 어느 쪽이든 공통점은 하나입니다. 사람이 갱신을 안 챙겨도 알아서 돌아가게 만든다는 것.

7. Let's Encrypt 자동 갱신 - ACME로 자동화하기

서버를 직접 운영한다면 무료 SSL 인증서의 사실상 표준은 Let's Encrypt입니다. 핵심은 ACME라는 프로토콜이에요. 발급·갱신·도메인 검증을 전부 자동으로 처리해주는 표준인데, certbot, acme.sh, Caddy, Traefik 같은 클라이언트가 이걸 구현하고 있습니다.

설정해두면 클라이언트가 만료 전에 알아서 갱신하고 서버에 적용까지 합니다. 사람이 할 일은 처음 한 번 설정하는 것뿐이에요. 수명이 200일이든 47일이든, 자동화만 제대로 걸려 있으면 운영 부담은 똑같습니다. 이게 짧은 수명 시대의 핵심입니다.

최근 Let's Encrypt 동향도 짚어둘 만합니다.

• 기본 수명을 90일에서 45일로 단계적으로 낮추겠다고 2025년 12월에 발표했습니다 (2028년경 목표)
• 2026년 1월부터는 6일짜리 단기 인증서와 IP 주소용 인증서가 정식 제공됩니다. 6일짜리는 자동화가 안 되어 있으면 사실상 못 씁니다
• 만료 알림 이메일은 2025년 6월에 종료됐습니다. "메일 오면 갱신해야지"라는 방식 자체가 이제 통하지 않는다는 신호예요

 

📌 자동화의 함정도 알아두세요

자동 갱신을 걸어뒀다고 끝이 아닙니다.

한 번도 실제로 갱신이 돌아본 적 없는 자동화는 안 하느니만 못합니다.

비프로덕션 환경에서 갱신·배포·서버 리로드까지 한 바퀴 돌려보고,

성공뿐 아니라 "조용한 실패"도 잡아내는 모니터링을 같이 걸어두는 게 좋습니다.

 

8. Cloudflare·CloudFront 무료 SSL - CDN에 맡기기

자동화 설정이 부담스럽거나 그냥 신경 끄고 싶다면 Cloudflare가 가장 편합니다. 저도 운영 중인 블로그들 도메인을 Cloudflare 무료 플랜에 연결해서 쓰는데, 인증서를 제가 직접 챙긴 기억이 거의 없습니다.

다만 앞에서 짚었듯 Cloudflare는 인증서를 발급해 주는 CA가 아니라 제 서버 앞에 끼어드는 프록시입니다. 도메인을 Cloudflare에 연결하면, 방문자의 브라우저는 제 서버가 아니라 Cloudflare에 먼저 접속합니다. 이 방문자↔Cloudflare 구간을 Cloudflare가 자기 인증서로 암호화해 주는 거예요. 이걸 Universal SSL이라고 부르고 무료 플랜에 기본 포함입니다. 발급도 갱신도 제가 손댈 게 없으니, 수명이 며칠로 줄든 제 입장에선 바뀌는 게 없습니다.

여기서 꼭 짚어야 할 함정이 있습니다. 방문자↔Cloudflare 구간이 암호화됐다고 해서, Cloudflare↔내 원서버 구간까지 암호화되는 건 아니라는 점입니다. 이 뒷구간을 어떻게 처리할지는 Cloudflare의 SSL 모드 설정에 달려 있어요.

• Flexible — 방문자↔Cloudflare만 암호화하고 원서버 구간은 평문(HTTP)입니다. 브라우저 주소창엔 자물쇠가 뜨지만 실제로는 절반만 암호화된 상태로, 가장 흔히 저지르는 실수예요
• Full — 양쪽 다 암호화하지만 원서버 인증서가 진짜인지는 검증하지 않습니다(자가서명 인증서도 통과)
• Full (Strict) — 양쪽 다 암호화하고 원서버 인증서까지 검증합니다. 가장 안전한 설정이고, 가능하면 이걸 써야 합니다

 

📌 자물쇠 아이콘이 곧 안전을 뜻하진 않습니다

Flexible 모드로 놓고 "자물쇠 떴으니 됐다"고 넘어가는 경우가 많은데,

이러면 Cloudflare와 원서버 사이는 그대로 노출됩니다.

원서버에도 인증서를 깔고

(Cloudflare가 무료로 발급해 주는 Origin Certificate를 쓰면 편합니다)

Full (Strict)로 맞춰두는 걸 권합니다.

 

 

정리하면, 트래픽이 Cloudflare를 거치는 게 싫거나 종단 구간 전체를 직접 통제해야 하는 환경이라면 Let's Encrypt 쪽이 맞습니다. 반대로 개인 블로그나 일반 웹사이트라면, SSL 모드만 제대로 잡아두면 가장 적은 노력으로 가장 확실하게 해결되는 방법입니다.

AWS를 쓰신다면 CloudFront도 똑같은 원리입니다. AWS Certificate Manager(ACM)에서 발급받은 공개 인증서는 CloudFront 같은 통합 서비스에 붙여 쓰면 무료이고, 갱신도 ACM이 알아서 해 줍니다. 다만 두 가지는 알아두셔야 해요. 하나, CloudFront에 붙일 인증서는 반드시 us-east-1(버지니아 북부) 리전에 있어야 합니다. CloudFront가 글로벌 서비스라 인증서 관리를 이 리전으로 일원화해 두었거든요. 둘, ACM이 발급한 인증서는 개인키를 내보낼 수 없어서 EC2에 직접 까는 용도로는 못 씁니다. 어디까지나 CloudFront·로드밸런서 같은 AWS 통합 서비스의 엣지에서 TLS를 종료하는 구조예요.

그런데 여기엔 Cloudflare와 결정적으로 갈리는 함정이 하나 있습니다. 무료인 건 ACM 인증서일 뿐, CloudFront라는 서비스 자체는 트래픽에 과금된다는 점입니다. CloudFront는 사용자에게 내보낸 데이터 전송량(GB당)과 요청 수(1만 건당)로 요금이 붙어요. 매달 일정량(조사 기준 데이터 전송 1TB·요청 1천만 건 수준)까지는 무료 한도가 있어서 트래픽 적은 사이트는 0원으로 굴러가지만, 방문자가 늘면 청구서가 따라옵니다. Cloudflare 무료 플랜이 대역폭 무제한이라 트래픽이 얼마가 됐든 0원인 것과는 성격이 다릅니다.

그래서 단순히 "SSL 공짜로 붙이고 싶다"가 목적이라면 개인 블로그·소규모 사이트엔 Cloudflare 쪽이 마음 편합니다. 반대로 이미 AWS 위에 인프라가 올라가 있고 S3·로드밸런서 같은 걸 같이 쓰는 환경이라면, 어차피 CloudFront를 끼게 되니 ACM으로 인증서까지 한 번에 묶는 게 자연스럽고요. 요금 체계는 2026년 들어 정액제 플랜이 추가되는 등 자주 바뀌니, 실제 도입 전엔 AWS 요금 페이지에서 최신 기준을 한 번 확인하시는 걸 권합니다.

9. 개인 블로그·소규모 사이트의 SSL 인증서

"나는 서버도 직접 안 만지는데?"라는 분들도 많을 겁니다. 결론부터 말하면 대부분 걱정 안 하셔도 됩니다.

티스토리, 네이버 블로그 같은 플랫폼은 인증서를 플랫폼이 알아서 관리합니다. 워드프레스를 호스팅 업체에 올린 경우도 요즘은 대부분 자동 SSL을 제공해요. 수명이 줄어드는 변화는 이런 환경에서는 사용자가 체감조차 못 하고 지나갑니다. 갱신은 플랫폼·호스팅 쪽 몫이니까요.

직접 챙겨야 하는 건 어디까지나 본인이 서버나 도메인을 직접 운영하는 경우입니다. VPS 빌려서 직접 웹서버 올렸다든가, 사이드 프로젝트를 클라우드에 직접 배포했다든가. 이런 경우라면 위에서 말한 자동화를 지금 미리 걸어두시는 걸 권합니다. 수명이 더 짧아지기 전에 습관을 들여두는 편이 편해요.

자주 묻는 질문(FAQ)

SSL 인증서 유효기간은 언제부터 47일이 되나요?

2029년 3월 15일부터 공개 TLS 인증서 최대 수명이 47일로 줄어듭니다. 그 전 단계로 2026년 3월부터 200일, 2027년 3월부터 100일이 순차 적용됩니다. 지금(2026년)은 200일 구간입니다.

인증서 수명이 짧아지면 꼭 해야 할 일은 무엇인가요?

인증서 발급·갱신을 자동화하는 것입니다. 갱신 주기가 짧아질수록 수동으로 만료일을 챙기는 방식은 사고로 이어지기 쉽습니다. ACME 기반 자동 갱신이나 CDN의 자동 SSL을 걸어두는 게 핵심입니다.

무료 SSL 인증서는 어디서 발급받나요?

서버를 직접 운영한다면 Let's Encrypt나 ZeroSSL에서 무료로 발급받을 수 있습니다. CDN을 쓴다면 Cloudflare의 Universal SSL, AWS 환경이라면 AWS Certificate Manager(ACM) 인증서를 CloudFront에 붙여 무료로 쓸 수 있습니다.

Let's Encrypt와 Cloudflare 중 무엇을 써야 하나요?

서버를 직접 통제하고 종단 구간 전체를 암호화하고 싶다면 Let's Encrypt가 적합합니다. 설정 부담 없이 가장 손쉽게 해결하고 싶다면 Cloudflare 무료 플랜이 편합니다. 단 Cloudflare는 원서버 구간(SSL 모드)을 Full Strict로 맞춰두는 게 안전합니다.

CloudFront로 무료 SSL을 쓰면 비용이 안 드나요?

ACM 인증서 자체는 무료지만 CloudFront 서비스는 데이터 전송량과 요청 수에 과금됩니다. 무료 한도가 있어 트래픽이 적으면 0원이지만, 방문자가 늘면 비용이 발생합니다. 대역폭이 무제한 무료인 Cloudflare와는 다른 점입니다.

마무리

SSL 인증서 수명 단축은 거스를 수 없는 흐름입니다. 398일에서 200일로, 다시 100일, 47일로 내려가는 일정이 이미 정해졌고 첫 단계는 진행 중입니다. 보안 논리는 분명하지만, 그 부담은 결국 운영하는 사람이 집니다.

다만 대응법도 어렵지 않습니다. 무료이고 자동 갱신되는 인증서로 옮겨두면, 수명이 며칠로 줄든 운영 부담은 거의 그대로입니다. 서버를 직접 운영하면 Let's Encrypt와 ACME 자동화를, 손이 덜 가는 걸 원하면 Cloudflare를, 플랫폼·호스팅 위에 있다면 그냥 신경 안 쓰셔도 됩니다.

핵심은 하나예요. 이제 인증서 갱신은 사람이 기억해서 하는 일이 아니라, 시스템이 알아서 하는 일이어야 한다는 것. 아직 수동으로 챙기고 계신다면, 다음 갱신이 오기 전에 자동화 한 번 걸어두시길 권합니다.

📚 함께 보면 좋은 글

방화벽 뜻과 유래, 컴퓨터 보안에 왜 '불(Fire) 막는 벽'이라는 이름이 붙었을까?

WAF(웹방화벽) 뜻 쉽게 설명해드림! 우리 회사 협업툴이 해킹당하지 않는 진짜 이유

TCP/UDP 포트 번호 모음: 매번 검색하기 귀찮아서 정리한 개발자·서버 관리자 필수 즐겨찾기표

Apache Nginx Tomcat 차이 완벽 정리 - 웹서버 30년 변천사로 이해하기