47일 TLS 인증서 시대, 갱신보다 배포 자동화가 먼저예요

47일 TLS 인증서 시대, 갱신보다 배포 자동화가 먼저예요

IT & AI 뉴스 썸네일

웹 서버 인증서를 1년에 한 번 갈아 끼우던 운영 방식은 곧 버티기 어려워져요. 인증서 최대 유효기간이 단계적으로 짧아지면 발급뿐 아니라 배포, 서비스 재적용, 만료 감시까지 자동화해야 해요. Todd Gardner의 NDC Toronto 2026 발표는 SSL에서 TLS 1.3과 단기 인증서로 이어진 변화를 운영자의 시선으로 설명해요. 1

핵심 요약

구분	달라진 점	운영팀이 확인할 것
인증서 수명	최대 유효기간이 2026년 200일, 2027년 100일, 2029년 47일로 줄어드는 일정이 소개됐어요	수동 갱신 작업량과 담당자를 계산해요
키 교환	TLS 1.3은 완전 순방향 비밀성을 기본 전제로 삼아요	오래된 TLS 버전과 RSA 키 교환 사용 여부를 점검해요
발급 방식	ACME가 도메인 검증과 인증서 발급·갱신을 자동화해요	DNS와 HTTP 검증 경로의 권한을 최소화해요
배포 과정	새 인증서를 받아도 각 서버와 장치에 적용하지 못하면 장애가 남아요	변환, 배포, 재시작, 롤백, 만료 감시를 함께 묶어요
다음 전환	포스트 양자 암호가 인증서와 키 교환 방식을 다시 바꿀 수 있어요	암호 알고리듬을 교체할 수 있는 배포 구조를 준비해요

1. 인증서 갱신이 연례행사에서 상시 작업으로 바뀌어요

발표에서 가장 실무적인 숫자는 47일이에요. 소개된 일정대로라면 공개 TLS 인증서의 최대 유효기간은 2026년 200일, 2027년 100일, 2029년 47일까지 짧아져요. 인증서 50개를 관리하는 조직은 2029년에 연간 약 500번의 갱신 주기를 맞게 돼요. 사람이 캘린더 알림을 보고 처리할 수 있는 규모가 아니에요. 2

유효기간을 줄이면 유출되거나 잘못 발급된 인증서가 악용될 수 있는 시간이 짧아져요. 도메인 소유권이 바뀐 뒤 이전 소유자가 오래된 인증서를 계속 보유하는 위험도 줄일 수 있어요. 반면 자동화가 빠진 환경에서는 만료 장애가 더 자주 생길 수 있어요. 보안 정책 변경이 곧 운영 방식 변경으로 이어지는 이유예요.

728x90

ACME는 도메인 제어권 확인과 인증서 발급·갱신을 자동화해요. HTTP 경로에 검증 파일을 두거나 DNS에 TXT 레코드를 추가하는 방식이 대표적이에요. Certbot이나 acme.sh를 설치하는 것만으로 모든 문제가 끝나지는 않아요. DNS API 자격 증명 범위, 실패 재시도, 발급 제한, 운영망 접근 권한도 같이 설계해야 해요.

발급 뒤에 남는 작업이 더 많아요

새 인증서를 받은 다음에는 대상 시스템이 요구하는 형식으로 바꿔야 할 수 있어요. Nginx와 Java KeyStore, 로드밸런서, 메일 서버가 서로 다른 형식과 적용 절차를 쓸 수 있어요. 여러 노드에 파일을 복사하고 서비스를 다시 불러온 뒤 실제 연결에서 새 인증서가 나오는지도 확인해야 해요.

따라서 자동화 범위는 인증서 검색, 발급, 형식 변환, 배포, 서비스 재적용, 외부 검증, 만료 감시까지 이어져야 해요. 단계별 소유자와 실패 알림도 필요해요. 갱신 명령이 성공했다는 로그만 보고 끝내면 일부 노드가 오래된 인증서를 계속 제공하는 상황을 놓칠 수 있어요.

완전 순방향 비밀성이 과거 통신을 지켜요

오래된 RSA 키 교환에서는 서버의 장기 개인 키가 인증과 세션 비밀 보호에 함께 관여했어요. 공격자가 암호화된 트래픽을 저장해 두고 나중에 개인 키를 확보하면 과거 통신까지 복호화할 여지가 있었어요.

완전 순방향 비밀성은 세션마다 일회성 Diffie-Hellman 키를 만들어요. 서버 인증서의 개인 키가 나중에 유출돼도 이미 끝난 세션의 키를 다시 계산하기 어려워져요. TLS 1.3은 이 방식을 기본 전제로 삼고 오래된 키 교환과 불필요한 암호 스위트를 걷어냈어요. 개인 키 유출 자체가 무해해지는 것은 아니에요. 공격자는 인증서가 유효한 동안 서버를 사칭할 수 있으므로 키 교체와 인증서 재발급은 여전히 필요해요. 1

브라우저가 인증서 신뢰 정책을 직접 밀어붙였어요

CA 감사와 업계 합의만으로는 오발급을 충분히 막지 못했어요. DigiNotar 침해와 Symantec의 대규모 오발급, SHA-1 충돌, Heartbleed는 기존 신뢰 체계의 빈틈을 드러냈어요. 인증서 폐기 목록과 OCSP도 속도, 가용성, 개인정보 문제 때문에 일관되게 작동하지 않았어요.

브라우저 업체들은 루트 저장소와 자체 정책을 이용해 기준을 강화했어요. Certificate Transparency 로그에 공개되지 않은 인증서를 신뢰하지 않거나, 일정 기간보다 긴 인증서를 거부하는 방식이에요. 웹 서비스 운영자는 CA가 발급해 줬다는 사실만 확인해서는 부족해요. 주요 브라우저의 루트 정책과 유효기간 제한도 함께 확인해야 해요. 2

왜 중요한가요

47일 인증서는 보안팀만의 일정 변경이 아니에요. 서비스가 인증서를 찾고 배포하는 경로, 비밀 정보 권한, 장애 감지 방식까지 시험해요. 웹 서버 한 대는 간단한 ACME 작업으로 처리할 수 있지만, 여러 리전과 로드밸런서, Java 애플리케이션, 사내 장비가 섞이면 인증서 인벤토리부터 필요해요. 1

먼저 외부에서 보이는 모든 인증서와 만료일, 발급자, 적용 대상을 목록으로 만들면 좋아요. 다음으로 갱신 후 실제 서비스가 새 인증서를 제공하는지 검사해요. 배포 실패 시 이전 인증서로 되돌리는 절차와 담당자 알림도 자동화해야 해요. 와일드카드 인증서에 쓰는 DNS 자격 증명은 필요한 영역만 수정할 수 있도록 권한을 좁혀야 해요.

이 구조는 포스트 양자 암호 전환에도 도움이 돼요. 앞으로 인증서 형식이나 키 교환 알고리듬이 바뀌더라도 배포 경로가 표준화돼 있으면 설정과 산출물을 교체하기 쉬워요. 수동으로 서버를 찾아다니는 환경이라면 알고리듬 전환 때 빠진 장비와 오래된 인증서가 동시에 쌓일 수 있어요.

참고 자료

1. Everything you learned about SSL is deprecated - Todd Gardner - NDC Toronto 2026 — NDC Conferences, YouTube
2. SSL에 대해 배운 모든 것이 더는 유효하지 않음 — GeekNews