요약

  • Let’s Encrypt는 2015년 11월 9일 인증서 유효기간을 최대 90일로 제한하고 60일째 갱신을 권했다. 탈취된 키나 잘못 발급된 인증서의 유효 시간을 줄이고 HTTPS 자동화를 촉진하려는 결정이었다.
  • 사흘 뒤 공개 베타 공지는 제한 베타에서 인증서 1만 1천 장 이상을 발급했다고 전하면서, 여러 플랫폼에서 클라이언트 경험을 안정적으로 다듬어야 한다고 밝혔다.

분석

인증서의 만료일은 파일 안에서는 조용한 값이지만 웹사이트에서는 운영 마감이 된다. notAfter는 서명된 인증서에 들어가는 필드다. RFC 5280은 유효기간을 notBefore부터 notAfter까지로 정의하며 양 끝 날짜를 포함한다. 마지막 날짜가 지나면 기존 인증서로는 그 시점의 유효성을 채울 수 없다. 서비스에는 교체 인증서를 배포해야 한다.

2015년 11월 9일, Internet Security Research Group의 전무이사 Josh Aas는 Let’s Encrypt가 왜 최대 90일로 제한했는지 설명했다. 이 상한에는 두 가지 목적이 있었다. 개인 키가 탈취되거나 인증서가 잘못 발급되면 그 인증서가 유효한 시간이 짧아진다. 또 갱신 간격을 줄여 자동화를 HTTPS를 쉽게 쓰기 위한 필수 요소로 만든다.

60일째 갱신하라는 권고가 절충의 모양을 보여준다. Let’s Encrypt는 마지막 날까지 기다리라고 하지 않았다. 90일 상한까지는 대략 한 달이 남아 관리자가 실패를 알아채고 수동으로 개입할 수 있었다. Aas는 서비스가 아직 새롭고 자동화도 많은 구독자에게 낯설다고 말했다. 소프트웨어가 맡을 일을 늘리면서도 문제가 생겼을 때 사람이 복구할 시간을 둔 셈이다.

시기는 11월 12일의 베타 공지에서 드러난다. Aas는 제한 베타가 9월 12일 시작됐고 당시까지 인증서 1만 1천 장 이상을 발급했다고 밝혔다. 공개 베타는 12월 3일 예정이었다. 같은 공지는 자동화를 전략의 핵심이라 부르면서도 다양한 플랫폼에서 클라이언트 경험을 매끄럽고 안정적으로 만드는 일이 남아 있다고 적었다. 발급은 베타 규모에 도달했지만 모든 환경에서 믿을 만하게 갱신하는 경험은 완성 중이었다.

Let’s Encrypt의 논리는 분명했다. 웹 전체의 인증서를 관리자가 하나씩 수동 갱신하게 만들 수는 없다. 발급과 갱신이 자동화되면 짧은 유효기간이 사이트 운영자의 일상 업무를 늘리지 않는다. 보안 목표와 운영 모델은 한 결정에 묶였다. 인증서의 시계가 빨리 돌수록 클라이언트가 그 시계를 따라가야 했다.

수동 갱신은 남아 있었지만 정상 운용의 중심은 소프트웨어였다. 갱신 클라이언트, 예약 작업, 플랫폼 호환성, 새 인증서를 실제 서비스에 반영하는 절차가 맞물려야 한다. 60일은 달력 위의 지시였고, 자동화는 그 지시를 많은 서버에서 반복해 지키는 방법이었다.

베타 공지의 수치는 11월 12일까지 발급된 인증서 수를 나타낸다. 성공하거나 실패한 갱신 횟수는 알려주지 않는다. 날짜별 갱신 성공 기록이 있다면 수동 대응 시간이 충분했는지 평가할 수 있지만, 두 공지에는 그런 수치가 없다.

출처