메인 웹사이트뿐 아니라 모든 엔드포인트에서 TLS 인증서 만료 모니터링하기

목표

만료된 인증서를 사용자를 통해 알게 되는 일이 없도록 합니다. 조직이 서비스하는 모든 인증서는 만료일이 파악되어 있어야 하고, 수동 갱신을 처리할 수 있을 만큼 충분히 이른 시점에 경고가 울려야 합니다.

전제 조건

TLS를 종료하는 호스트명과 포트의 목록(443뿐 아니라 SMTP, IMAP, LDAP, 데이터베이스 포트, 관리 패널, 로드밸런서 리스너, VPN 엔드포인트 포함), 일정에 따라 점검을 실행하는 모니터링 시스템, 각 인증서가 어떻게 발급되는지(ACME 클라이언트, 공급자 관리, 수동)에 대한 지식.

단계

1. 문서에 적힌 내용이 아니라 실제로 서비스되고 있는 것을 기준으로 목록을 만듭니다. 보유한 주소와 DNS 이름을 스캔해 TLS 리스너를 찾고, 호스트·포트·주체(subject)·발급자(issuer)를 기록합니다.
2. 각 엔드포인트에 대해 호스트 외부에서 점검하여 클라이언트가 보는 것과 같은 체인을 읽습니다. RFC 5280은 유효기간을 notBefore와 notAfter로 정의하며, 리프 인증서와 각 중간 인증서는 저마다 자신의 값을 가집니다.
3. 리프와 중간 인증서 각각에 대해 notAfter까지 남은 일수를 계산해 지표로 내보냅니다. 스크립트로 작성한다면, OpenSSL 매뉴얼은 openssl x509 -checkend <seconds>를 제공하며, 인증서가 그 초 이내에 만료되면 0이 아닌 값으로 종료합니다. 3.6 매뉴얼에는 -multi 옵션이 추가되어, 입력(예: 저장된 체인) 안의 어떤 인증서든 해당 기간 내에 만료되면 -checkend가 실패하도록 만들 수 있습니다. 3.5 매뉴얼에는 -multi가 없으므로, 이전 버전에서는 리프와 각 중간 인증서를 따로따로 확인해야 합니다.
4. 임계값은 발급 방식에 맞춰 정합니다. Let's Encrypt는 기본 인증서의 유효기간이 90일이며 60일마다 갱신할 것을 권장하고, 단기 인증서는 유효기간이 6일이며 3일마다 갱신한다고 밝히고 있습니다. 90일짜리의 경우 60일째 갱신하면 30일이 남으므로, 남은 기간 20일 시점에 경고가 울린다는 것은 자동 갱신이 이미 한 주기를 놓쳤는데도 사람이 처리할 시간은 아직 있다는 뜻입니다. 6일짜리 인증서는 임계값을 시간 단위로 잡아야 합니다.
5. 점검 자체가 실패한 경우(포트 닫힘, 핸드셰이크 오류)와, 인증서의 주체나 발급자가 예상과 다른 경우에도 경고를 울립니다.
6. 의도적으로 유효기간이 짧은 인증서를 점검하거나, 특정 엔드포인트 하나의 임계값을 현재 남은 일수보다 높게 올려 경고를 테스트합니다.
7. 각 엔드포인트마다 누가 어떤 방법으로 갱신하는지 기록해 둡니다. 경고에 대한 런북은 "갱신을 실행한 뒤 다시 점검한다"입니다.

기대 결과

모든 인증서의 남은 수명을 한눈에 볼 수 있는 뷰, 수동 갱신이 아직 여유 있을 때 울리는 경고, 그리고 어떤 엔드포인트의 인증서도 갑자기 놀라게 만들지 않는 상태를 얻습니다.

한계와 검증 근거

호스트 내부에서 점검하면 앞단 로드밸런서나 CDN이 제시하는 인증서를 놓칩니다. 클라이언트 인증서와 코드 서명 인증서도 같은 방식의 목록이 필요하지만 점검 방법은 다릅니다. 유효기간은 인용된 발급자의 공표 내용을 따른 것이며, 장애 통계에 대해서는 어떠한 주장도 하지 않습니다.