2026년 3월부터 공개 TLS 인증서의 최대 유효기간이 단계적으로 단축되면서, 인증서 갱신은 더 이상 ‘가끔 하는 작업’이 아니라 상시 운영 업무가 됩니다.
이번 글에서는 DigiCert의 '47-Day TLS Certificates FAQ' 문서를 기반으로 유효기간 단축 로드맵(200일→100일→47일), 도메인 검증 재사용 기간(최대 10일) 변화, 그리고 자동화가 왜 필수인지 핵심 질문과 답변 형태로 정리했습니다. 아래 Q&A를 통해 우리 조직이 어떤 준비를 해야 하는지 빠르게 점검해보실 수 있습니다.
⏰47-Day TLS Certificates: FAQs
Q: 인증서 유효기간에 대한 새로운 규칙은 무엇인가요?
CA/B 포럼의 새로운 TLS 규칙에는 2026년 3월부터 적용되기 시작하는 3가지 주요 변경 사항이 있습니다:
일부 공개 인증서의 자동화에는 특수 도구나 전문성이 필요할 수 있지만, 대부분의 경우 작업은 비교적 단순합니다. 관련 문서도 충분히 제공되어 있고, 서비스는 (DigiCert가 제공하는 것처럼) 무료인 경우도 많습니다.
Q: 변경 일정은 어떻게 되나요?
공개 TLS 인증서의 최대 유효기간은 향후 몇 년에 걸쳐 다음과 같이 감소합니다:
도메인 및 IP 주소 검증 정보의 재사용 가능 최대 기간도 다음과 같이 감소합니다:
Q: 최대 인증서 유효기간(47일까지)과 최대 도메인 검증 재사용 기간(10일까지)의 차이는 무엇인가요?
인증서의 최대 유효기간은 인증서가 유효하다고 간주되는 최대 일수입니다. 인증서를 발급하려면, 인증기관(CA)은 신청자가 인증서에 포함된 도메인명 또는 IP 주소를 통제하고 있음을 검증해야 합니다. 현재 규칙처럼 1년에 한 번 인증서를 갱신하는 경우라면, 갱신 주문 시점에 매년 통제 여부를 다시 검증하게 됩니다. 그런데 갱신 전에 인증서를 교체해야 하는 경우(예: 개인키가 유출된 경우)는 어떻게 될까요? 이때 CA는 가장 최근 갱신 시 수행된 검증을 재사용할 수 있어, 다시 검증할 필요를 줄일 수 있습니다. 이는 도메인 검증 재사용 최대 기간이 아직 만료되지 않았기 때문입니다.
기본 요구사항(Baseline Requirements, 즉 CA/B 포럼의 인증서 발급 규칙)은 오래전부터 이 두 가지 시간 제한을 모두 규정해 왔지만, 일반적으로 두 값을 같은 일수로 설정해 왔습니다. 새 규칙의 최종 단계에서 “최대 인증서 유효기간은 (궁극적으로) 47일”이지만 “도메인 검증은 10일까지만 재사용 가능”하도록 바뀌는 이유는, 검증 정보가 빠르게 최신성을 잃는다고 보고 더 자주 검증이 수행되도록 하기 위함입니다. 이 변경은 또한 CA/B 포럼이 도메인 검증은 반드시 자동화되어야 한다고 믿고 있음을 분명히 보여줍니다. 이렇게 짧은 일정에서는 수동 검증이 큰 부담이 됩니다. 자동화가 되면, 짧은 일정은 전혀 문제가 되지 않습니다.
Q: 선택지는 무엇인가요?
합리적인 선택지는 하나뿐입니다. 인증서 수명주기 관리(CLM, Certificate Lifecycle Management)를 자동화하는 것입니다. CA/B 포럼과 업계(DigiCert 포함)는 인증서 유효기간이 단축될 것이며 수동 인증서 관리는 더 이상 현실적인 해법이 될 수 없다고 수년 전부터 고객에게 권고해 왔습니다.
도메인 검증(DV) 인증서의 대부분의 사용 사례는 ACME(Automated Certificate Management Environment)와 ARI(ACME Renewal Information) 표준을 활용해 비교적 쉽게 자동화할 수 있습니다. 이 기능은 DigiCert CertCentral에 추가 비용 없이 포함되어 있습니다. 더 복잡한 사례의 경우, DigiCert의 Trust Lifecycle Manager(TLM)가 다양한 엔터프라이즈 구성에 대해 매니지드 자동화 지원을 제공합니다.
일부 애플리케이션에는 내부 PKI(프라이빗 PKI라고도 함)도 또 다른 선택지가 될 수 있습니다. 많은 공개 신뢰 인증서는 공개 접근이 필요 없는 리소스를 보호하는 데 사용되며, 모범 사례에 따르면 이런 리소스는 인터넷에서 접근되지 않아야 합니다. 관리자가 이런 리소스에 공개 인증서를 쓰는 경우가 있는 이유는 가장 쉬운 방법이기 때문이지만, 올바른 접근은 내부 PKI를 사용하는 것입니다.
내부 PKI는 기업 내부의 프라이빗 리소스 간 통신을 위해, 기업 내부에서만 “유효”하거나 신뢰되는 인증서를 발급합니다. 따라서 인증서 유효기간과 다른 많은 파라미터에 대해 자체 규칙을 설정할 수 있습니다. 내부 PKI에 필요한 모든 소프트웨어를 직접 운영할 수도 있지만, 이는 복잡하고 오류 가능성이 큰 작업입니다. DigiCert는 엔터프라이즈, 클라우드, 제조(Manufacturing) 사용 사례를 위한 여러 내부 PKI 솔루션을 제공합니다.
도메인 검증에 대한 동일한 일정은 OV 및 EV 인증서에도 적용됩니다. 결국 OV/EV 인증서도 DV 인증서와 같은 일정(즉, 200/100/10일마다)으로 도메인 검증을 수행해야 합니다. 다만 그 인증서에 포함되는 다른 정보(예: 조직명과 주소)는 398일마다만 갱신하면 됩니다. 도메인 검증은 DV 인증서와 마찬가지로 자동화할 수 있고 자동화해야 하지만, 다른 정보는 완전 자동화가 불가능합니다.
Q: 변경이 적용되는 날짜부터 브라우저는 200/100/47일을 초과하는 유효기간의 인증서를 더 이상 받아들이지 않나요?
정확히는 그렇지 않습니다. 제한은 브라우저가 받아들일 수 있는 인증서 종류가 아니라, CA가 발급할 수 있는 인증서 종류에 적용됩니다. 브라우저는 “현재 날짜가 인증서의 유효기간 범위 내에 있는지”를 확인합니다.
규칙 변경이 적용되면, CA는 200/100/47일을 초과하는 유효기간의 TLS 인증서를 더 이상 발급할 수 없습니다. 하지만 규칙 변경 이전에 발급된 398일 유효기간 인증서는 만료될 때까지 계속 유효합니다. 200일 인증서가 100일로 바뀔 때도, 100일 인증서가 47일로 바뀔 때도 동일하게 적용됩니다.
Q: CA/B 포럼은 무엇인가요?
CA/Browser Forum(약칭 CA/B Forum 또는 CABF)은 DigiCert 같은 인증기관(표준에서는 certificate issuers, 인증서 발급자)과 인증서를 사용해 리소스를 인증하는 애플리케이션(대개 웹 브라우저로, 표준에서는 certificate consumers, 인증서 소비자)으로 구성된 업계 표준 기구입니다. 그 밖의 이해관계자도 회원으로 참여하지만, 투표권은 자격을 갖춘 인증서 발급자와 소비자에게만 제한됩니다.
TLS 인증서를 위한 최초의 TLS Baseline Requirements(BR)는 2012년에 발효되었습니다. 이 외에도 공개 코드 서명(public code signing) 및 S/MIME 인증서에 대한 표준을 다루는 작업 그룹이 있습니다.
Q: 이러한 표준 변경은 내부(프라이빗) PKI에도 영향을 미치나요?
아니요. Baseline Requirements는 공개 인증기관에만 구속력을 갖습니다.
내부 PKI는 네트워크 또는 클라우드 내부에서 운영됩니다. 내부 PKI에도 인증기관이 포함되지만, 인증서 만료일을 포함해 내부 인증기관이 강제하는 정책은 사용자가 설정합니다. 내부 PKI에서도 짧은 만료일을 선택하는 것이 최선일 수는 있지만, 필수는 아닙니다. 내부 PKI의 모든 소프트웨어를 직접 운영할 수도 있지만, 이는 복잡하고 오류 가능성이 큰 작업입니다. DigiCert는 엔터프라이즈, 클라우드, 제조 사용 사례를 위한 여러 내부 PKI 솔루션을 제공합니다.
Q: 인증서를 더 자주 교체해야 한다면 비용을 더 내야 하나요?
아니요. 최소한 DigiCert CertCentral에서는 그렇지 않습니다. 인증서는 연간 구독 형태로 결제합니다. 구독 기간 동안에는 필요한 만큼 자주 갱신하거나 교체해도 비용이 들지 않으며, 구독에는 ACME/ARI 자동화도 추가 비용 없이 포함됩니다. 이런 변화가 올 것을 예상했기 때문에 구독 모델로 전환한 것도 그 이유 중 하나입니다.
고객이 인증서 갱신을 자동화하면, 쉬워지고 굳이 하지 않을 이유가 없기 때문에 자발적으로 더 빠른 교체 주기로 옮기는 경우가 많습니다. 예를 들어 30일마다 바로 갱신하도록 전환하면, 2029년 변화에도 대비가 되어 있다는 확신을 가질 수 있습니다.
Q: 새 규칙은 중간 인증서와 루트 인증서에도 영향을 미치나요?
아니요. 이 규칙은 중간 CA가 발급하는 리프(leaf) 인증서에만 영향을 미칩니다.
CA/B 포럼이나 다른 표준 기구에는 루트 및 중간 인증서의 유효기간을 제한하는 규칙이 없지만, 일반적으로 합의된 모범 사례가 존재하며, 인증서를 소비하는 소프트웨어 벤더는 신뢰 루트 프로그램에 대해 자체 규칙을 두고 있고 그 내용은 크게 다를 수 있습니다.
Mozilla Root Store Policy는(7.4절) 키가 생성된 후 15년이 지나면 Mozilla가 루트 인증서를 신뢰 해제할 것이라고 말합니다. Chrome Root Program Policy 버전 1.6(2025년 2월 15일)의 유효기간 규칙은 더 복잡합니다. 명시적인 유효기간 상한은 없지만, “해당 키 자료가 15년보다 오래전에 생성된 루트 CA 인증서는 Chrome Root Store에서 지속적으로 제거될 것”이라고 되어 있습니다. 2014년 4월 16일 이전에 생성된 키를 포함하는 루트는 Root Program Policy에 정의된 고정 연간 일정에 따라 삭제됩니다. Microsoft Trusted Root Program은 “새로 발급된(Newly minted) 루트 CA는 제출일로부터 최소 8년, 최대 25년의 유효기간을 가져야 한다”고 말합니다. Microsoft와 다른 정책 간 규칙 차이는 Microsoft가 PKI에서 지원하는 애플리케이션의 범위가 다른 브라우저보다 훨씬 넓다는 점에서 비롯됩니다.
상식적인 모범 사례 중 하나는, 루트 CA 인증서가 그 아래로 체인되는 어떤 중간 CA 인증서보다 먼저 만료되지 않도록 하는 것입니다.
루트 및 중간 CA 인증서 수명주기를 잘못 관리하면 심각한 결과를 초래할 수 있습니다. 최근에도 ‘잊혀진 것으로 보이는’ Google 중간 CA 인증서가 만료되면서 많은 Google Chromecast 기기가 서비스를 이용하지 못한 사례가 있었습니다.
Q: 인증서 수명주기 관리는 어떻게 자동화하나요?
웹 서버와 공개 TLS 인증서처럼 일반적이고 비교적 단순한 사례의 경우, CertCentral 고객은 널리 지원되는 ACME(Automated Certificate Management Environment)와 ARI(ACME Renewal Information) 표준을 이용해 무료로 자동화할 수 있습니다.
물론 모든 인증서가 공개 TLS인 것은 아니며, 모든 기술이 ACME를 지원하는 것도 아닙니다. 그런 경우 DigiCert의 Trust Lifecycle Manager가 고급 자동화 기능과 통합을 제공합니다.
ACME 자동화는 단순히 체크박스 하나를 켜는 수준을 넘어섭니다. 인증서를 요청하는 장비 또는 애플리케이션(대개 웹 서버)에서 변경해야 할 사항이 있습니다. 하지만 대부분의 관리자는 절차가 복잡하지 않고 문서도 잘 갖춰져 있음을 확인할 수 있습니다.
Q: ACME와 ARI는 무엇인가요?
ACME는 Automated Certificate Management Environment이고, ARI는 ACME Renewal Information입니다.
ACME는 모든 주요 인증기관이 지원하는 표준으로, 인증서 클라이언트 소프트웨어(대개 웹 서버)가 CA에 인증서를 요청하고 클라이언트에 설치하는 방식입니다. (이 시나리오에서 클라이언트는 웹 서버입니다.) 클라이언트 소프트웨어도 ACME를 지원해야 합니다. 지원은 널리 퍼져 있지만 보편적이지는 않습니다. ACME 클라이언트 프로그램은 보통 Linux cron이나 Windows Scheduled Tasks를 이용해 일정에 따라 클라이언트 시스템에서 실행되지만, 더 큰 제품 안에 스케줄을 통합한 다른 솔루션도 있습니다.
ARI는 관련 표준으로, 서버가 스케줄을 제안해 클라이언트가 인증서 만료 전에 갱신해야 함을 알 수 있도록 합니다. 올바르게 구성하면 ARI는 인증서가 폐기(revoked)된 경우에도 클라이언트에게 갱신을 지시해 장애를 예방할 수 있습니다.
Q: 이 변화는 조직 검증(OV) 및 확장 검증(EV) 인증서에 어떤 영향을 미치나요?
TLS 인증서에 대한 새 규칙에 따라, 2026년 3월 15일부터 SII(Subject Identity Information) 검증은 825일에서 398일로, 398일 동안만 재사용할 수 있습니다. 즉, OV 및 EV 인증서에 대한 주요 영향은 “인증서에 포함되어 조직을 식별하는 정보”인 SII를 2년에 한 번이 아니라 매년 다시 검증해야 한다는 점입니다.
TLS Baseline Requirements에 따르면, 이를 위해 DigiCert 담당자와의 연례 전화 통화가 필요하므로 완전 자동화는 불가능합니다.
OV 및 EV 인증서도 도메인명을 보호하므로, OV 및 EV 인증서의 유효기간도 DV 인증서와 동일한 일정으로 변경됩니다. 2026년에는 200일, 2027년에는 100일, 2029년에는 47일로 줄어듭니다. 이러한 인증서의 관리 자동화 필요성은 DV 인증서 못지않게 큽니다.
Q: 왜 47일인가요?
47일은 임의의 숫자처럼 보일 수 있지만, 단순한 연쇄(cascade) 결과입니다:
이처럼 “여유를 더해 홀수 기간을 설정하는” 모델은 CA/B 포럼에서 오랫동안 표준 운영 방식이었습니다. 현재의 398일 제한은 최대 1년(366일) + 최대 1개월(31일) + 1일 여유(wiggle room)로 선택되었습니다.
Q: 이러한 변화는 양자 컴퓨팅으로 인한 암호 위협과 어떤 관련이 있나요?
직접적인 관련은 없습니다. 하지만 조직이 자동화된 인증서 관리 솔루션을 도입하도록 강제함으로써, 양자내성암호(PQC, Post-Quantum Cryptography)에 대한 준비 태세를 개선하는 효과를 가져올 것으로 예상합니다.
앞으로 PQC로의 전환에는 인프라(예: 인증기관)의 암호 시스템, 고객 환경(웹 서버 및 디지털 인증서를 사용하는 기타 애플리케이션), 그리고 소프트웨어 자체(웹 브라우저, 네트워크 장비 등)에 걸쳐 많은 변화가 수반될 것입니다. 이러한 변화를 최신 상태로 따라가려면, 조직은 운영 중단 없이 빠르게 소프트웨어 변경을 수행할 수 있어야 합니다. 자동화된 인증서 수명주기 관리는 그중 중요한 일부를 가능하게 합니다.
인증서는 PQC의 한 부분일 뿐이지만(다만 중요한 부분입니다), 여러분이 사용하는 다른 많은 소프트웨어·하드웨어 제품도 다양한 벤더에 의해 PQC를 지원하도록 업데이트되어야 합니다. 주목할 점은, 이러한 변화가 전면적으로 적용되는 2029년이 Gartner가 “조직이 양자 대비(quantum ready)를 갖춰야 한다”고 말하는 시점이기도 하다는 것입니다.
Q: 브라우저가 아닌 클라이언트(네트워크 장비 등)는 어떤 영향을 받나요?
공개 TLS 인증서 시장은 대체로 웹 서버에 설치되는 브라우저 대상 인증서를 압도적으로 지원하지만, 그 외의 경우도 있습니다. VPN 게이트웨이와 일부 IoT 기기가 좋은 예입니다.
이러한 장비들도 CLM(인증서 수명주기 관리) 주기를 더 촘촘하게 가져가야 합니다. 많은 장비가 ACME 또는 다른 자동화 프로토콜을 직접 지원하므로, 파라미터를 변경하는 것이 큰 작업이 아닐 수 있습니다. 반면 다른 경우에는 대체 자동화 메커니즘을 지원하거나 아예 지원이 없을 수도 있는데, 이때는 사용자가 자동화를 위해 프로그래밍을 해야 합니다.
이 장비들에서 새로운 일정을 수용하는 것이 흔한 문제로 등장할 것입니다. 영향을 받는 자산의 전체 인벤토리를 완전하게 만드는 것이 중요하며, DigiCert는 이 과정을 지원할 수 있습니다.
Q: 2026년 마감 이전에 인증서를 갱신하면 398일을 그대로 받을 수 있나요?
네, 2026년 3월 15일 이전에 갱신하여 다시 398일을 받는 것은 규칙상 가능합니다. 다만 이는 1회성 연장입니다. 다음에 인증서를 갱신할 때에는 최대 유효기간이 100일로 줄어들어 있을 것입니다. 대비를 위해 CertCentral 또는 Trust Lifecycle Manager를 사용한 자동화를 미리 구축해 두시기 바랍니다.
2026년 3월 15일 당일 또는 그 이후에 인증서를 재발급(리키, rekey)해야 한다면, DigiCert(또는 어떤 공개 CA든)는 그 시점에 적용되는 규칙을 따라야 하며, 그 경우 최대 200일짜리 인증서가 될 수밖에 없습니다. 인증서 관리를 자동화하기 가장 좋은 시점은 가능한 한 빠를 때입니다. 만료 또는 기타 원인으로 인한 장애 위험 없이 준비할 수 있도록, 최대한 빨리 자동화 체계를 마련하시기 바랍니다.
인증서 자동화는 “언젠가”가 아니라 “지금” 준비할수록 안전합니다. DigiCert Trust Lifecycle Manager(TLM)로 인증서 수명주기 관리를 체계화하고, 단축 일정(200→100→47일)에도 흔들림 없이 대응하세요.
▶ 디지서트(DigiCert) TLM 자세히보기
▶ FAQs: 47-Day TLS Certificates 원문보기
