유효기간은 왜, 어떻게 짧아지고 있나
공개 웹 인증서의 최대 유효기간은 CA/브라우저 포럼의 기본 요구사항(Baseline Requirements)이 정합니다. 위키백과 정리에 따르면 2012년 7월 60개월에서 출발해 2015년 4월 39개월, 2018년 3월 825일, 2020년 9월 398일로 줄었고, 2025년 4월 포럼이 통과시킨 안건(SC-081v3)으로 이후에도 단계적으로 줄어드는 일정이 잡혀 있습니다. 아래 일정은 위키백과와 업계 정리 자료가 일치하는 내용이며, 정확한 문구와 예외는 CA/브라우저 포럼의 공식 안건 문서에서 확인해야 합니다(기준 시점 2026년 10월).
| 적용 시작 | 최대 유효기간 | 비고 |
|---|---|---|
| 2018년 3월 1일 | 825일 | Baseline Requirements 개정 |
| 2020년 9월 1일 | 398일 | 약 1년 주기 |
| 2026년 3월 15일 | 200일 | SC-081v3 (시행 중) |
| 2027년 3월 15일 | 100일 | SC-081v3 (예정) |
| 2029년 3월 15일 | 47일 | SC-081v3 (예정) |
짧아지는 이유로 흔히 거론되는 것은 개인키 유출이나 정보 변경 시 잘못된 인증서가 살아 있는 기간을 줄이고, 폐지(revocation) 확인이 모든 환경에서 완벽하지 않은 점을 유효기간 자체로 보완한다는 것입니다. 1년에 한 번 손으로 갱신하던 방식은 100일, 47일 주기에서는 현실적이지 않으므로 자동 갱신(ACME 등)이 사실상 전제가 됩니다. 이 표는 공개적으로 신뢰되는 인증서에 해당하며, 내부망 전용 사설 CA의 인증서는 별도 정책을 따를 수 있습니다.
실제 사례 두 가지: 신뢰 체인이 흔들렸을 때
사례 1. 인증기관이 뚫린 날: DigiNotar (2011년)
네덜란드의 인증기관 DigiNotar는 2011년 7월 19일 자사 인프라에 대한 침입을 탐지했지만 당시 공개하지 않았습니다. 그보다 앞선 7월 10일에는 *.google.com 용 위조 인증서가 발급되어 있었고, 이 인증서는 이란에서 구글 서비스에 대한 중간자 공격에 쓰였습니다. 2011년 8월 말 이란 ISP에서 인증서 이상이 관측되며 문제가 드러났습니다. 위조 인증서는 Yahoo, Mozilla, WordPress, Tor 프로젝트용 등으로 늘어 최소 531건으로 집계되었습니다. 이후 Mozilla·Microsoft·Google·Opera가 DigiNotar 루트에 대한 신뢰를 거뒀고 애플도 2011년 9월 9일 맥OS에서 제거했습니다. 모회사 VASCO는 2011년 9월 20일 DigiNotar의 파산을 발표했습니다. 조사를 맡은 Fox-IT의 보고서는 법원 명령으로 2012년 10월 공개되었고 시스템이 "거의 전면적으로 침해"되었다고 서술합니다(이상 위키백과 정리 기준). 배울 점은 체인 방식에서는 신뢰받는 CA 한 곳이 뚫리면 그 CA가 서명할 수 있는 모든 도메인이 위협받는다는 구조적 약점이고, 브라우저가 문제 CA를 목록에서 빼는 조치가 마지막 방어선이라는 것입니다.
사례 2. 서버 메모리가 새어 나간 사건: Heartbleed (2014년, CVE-2014-0160)
2014년 4월 공개된 Heartbleed는 OpenSSL 1.0.1부터 1.0.1f까지 TLS 하트비트 확장에 있던 경계 검사 누락 취약점입니다(CVE-2014-0160). 조작된 하트비트 요청으로 서버 메모리를 요청당 최대 64KB씩 읽어 갈 수 있었고, 그 안에는 개인키, 세션 쿠키, 비밀번호 같은 정보가 있을 수 있었습니다. 구글의 닐 메타가 2014년 4월 1일 비공개로 보고했고 Codenomicon도 독립적으로 발견했으며, 수정판 OpenSSL 1.0.1g가 4월 7일 배포되었습니다(위키백과 정리 기준). 인증서 관점에서 중요한 대목은 복구 절차입니다. 패치만으로는 부족하고, 이미 유출됐을 수 있는 개인키는 새로 만들어 인증서를 재발급하고 옛 인증서를 폐지하라고 정리됩니다. 배울 점은 인증서가 정상이어도 서버 구현의 결함으로 키가 노출되면 암호화가 무력화될 수 있다는 점, 그리고 키가 새면 "인증서를 갈아야 한다"는 것입니다.
내 사이트·내 접속에서 직접 확인하기
- 자물쇠 → 인증서 보기: 발급 대상, 발급자, 유효기간 종료일, 체인 단계를 확인합니다. 개발자 도구의 보안 탭에서도 볼 수 있습니다.
- 만료일 관리: 유효기간이 짧아질수록 만료 장애 가능성이 커지므로, 자동 갱신이 실제로 도는지 주기적으로 점검합니다.
- 이름 일치 보기: 인증서의 이름(subjectAltName)과 접속 주소가 다르면 브라우저가 경고합니다. 경고를 무시하고 진행하는 습관은 중간자 공격에 취약합니다.
- 체인이 완전한지: 서버가 중간 인증서를 함께 내려주지 않으면 일부 환경에서만 오류가 나기도 합니다.
- 주소 철자 확인: 피싱을 가려내는 일은 자물쇠가 아니라 주소창의 도메인을 읽는 데 달려 있습니다.
흔한 오해와 정정
- 오해: 자물쇠가 있으면 믿을 수 있는 사이트다. 실제: 자물쇠는 통신 구간 암호화와 그 도메인에 대한 인증서 유효성을 뜻할 뿐, 운영자의 선의는 보증하지 않습니다.
- 오해: 유료 인증서가 무료보다 암호화가 더 강하다. 실제: 암호화 강도는 협상된 TLS 버전과 암호 스위트가 정하며, 유료·무료의 차이는 검증 등급과 부가 서비스에 있습니다.
- 오해: SSL과 TLS는 별개의 최신 기술이다. 실제: TLS는 SSL의 후속 표준이고 SSL 3.0은 2015년 RFC 7568로 사용 금지되었습니다. "SSL 인증서"는 이름만 남은 말입니다.
- 오해: 인증서는 한 번 받으면 계속 쓴다. 실제: 공개 인증서에는 최대 유효기간이 있고 계속 줄어드는 중입니다.
한계와 더 알아볼 점
인증서 체계는 "신뢰하는 CA 목록"에 의존하므로 CA 한 곳의 실수나 침해가 넓게 번질 수 있습니다. 폐지 확인(CRL 등)도 모든 환경에서 즉시 완벽하게 작동하지는 않아 유효기간 단축이 보완책으로 거론됩니다. EV 인증서의 주소창 강조 표시는 주요 브라우저에서 줄어 검증 등급이 사용자에게 보이는 정도도 달라졌습니다. 유효기간 단축 일정의 세부 조건과 향후 변경은 포럼의 공식 문서를 기준으로 확인하세요.
TLS 핸드셰이크 과정도 함께 알아보세요
인증서를 확인한 이후 실제로 암호화 통신이 시작되는 과정이 궁금하다면TLS 핸드셰이크로 알아보는 HTTPS 연결 원리를 확인해보세요.
자주 묻는 질문
인증서에도 유효기간이 있나요?
네, 모든 SSL/TLS 인증서에는 유효기간이 있습니다. 최근에는 보안을 위해 유효기간이 점점 짧아지는 추세이며, 만료 전에 갱신하지 않으면 브라우저가 경고를 표시합니다.
무료 인증서와 유료 인증서는 보안 수준이 다른가요?
암호화 자체의 강도는 대체로 동일합니다. 차이는 주로 검증 등급(DV·OV·EV)과 부가 서비스(고객 지원, 보증 등)에 있으며, 개인 블로그나 소규모 사이트라면 무료 DV 인증서만으로도 충분한 경우가 많습니다.
"인증서 오류" 경고가 뜨면 그냥 진행해도 되나요?
권장하지 않습니다. 만료, 이름 불일치, 신뢰할 수 없는 발급자 중 무엇이든 연결 상대를 확신할 수 없다는 뜻입니다. 특히 공용 와이파이에서 로그인이나 결제 정보를 입력하는 중이라면 중단하는 편이 안전합니다.
중간 인증서와 루트 인증서는 왜 나누어 두나요?
루트 CA의 개인키는 유출되면 파급이 크기 때문에 평소에는 격리해 두고, 일상적인 발급은 루트가 위임한 중간 CA가 맡는 구조가 일반적입니다. 중간 CA에 문제가 생겨도 루트 전체를 바꾸지 않고 그 중간 CA만 폐지할 수 있다는 장점이 있습니다.
도메인 하나에 인증서도 꼭 하나만 필요한가요?
그렇지 않습니다. subjectAltName 확장에 여러 도메인 이름을 담을 수 있고, 하위 도메인을 한꺼번에 덮는 와일드카드(*.example.com) 형태도 있습니다. 다만 와일드카드는 개인키가 유출되면 영향 범위가 넓다는 점을 고려해야 합니다.
이어서 읽어 보세요
- TLS 핸드셰이크 가이드: 인증서 확인 뒤 키가 합의되는 과정
- 무료 SSL 인증서 가이드: 자동 발급과 갱신의 실제
- DNSSEC 가이드: 도메인 응답을 보호하는 또 다른 신뢰 체인
- HTTP 프로토콜 발전사: HTTPS가 기본이 되기까지의 흐름