← 블로그 목록
43 서버·보안

TLS 인증서 갱신 모니터링과 실패 대응 런북

TLS 인증서 만료를 날짜 알림만으로 기다리지 않고 갱신 작업, 외부 핸드셰이크 검증, 실패 시 교대 대응까지 하나의 런북으로 운영하는 방법입니다.

TLS 인증서 갱신 모니터링과 실패 대응 런북 대표 이미지

TLS 인증서 운영의 완료 기준은 자동 갱신 명령이 성공한 것이 아니라 사용자가 실제로 연결했을 때 새 인증서와 체인이 제공되는 상태입니다. 갱신 파일이 디스크에 있어도 웹 서버가 다시 읽지 않았거나, 로드밸런서의 한 노드만 교체됐거나, 중간 인증서가 빠지면 브라우저와 API 클라이언트는 계속 실패합니다. 따라서 만료일 알림, 갱신 작업 결과, 외부 핸드셰이크를 각각 독립된 신호로 수집해야 합니다.

이 런북은 공개 HTTPS 엔드포인트를 운영하고 인증서 발급자와 무관하게 적용할 수 있는 점검 순서를 제안합니다. 발급 자동화 도구의 구체적인 플러그인보다 도메인 목록, 만료 시각, 배포 대상, 검증 명령, 담당자와 에스컬레이션 시간을 한 문서에서 연결하는 데 초점을 둡니다. Certbot 문서는 자동 갱신을 구성한 뒤 실제로 갱신이 가능한지 dry-run으로 시험하는 방법을 안내하므로, 성공 알림만 믿지 말고 정기 시험을 일정에 넣습니다.

운영 원칙: 파일 생성, 프로세스 reload, 외부 핸드셰이크를 각각 성공으로 증명합니다.

무엇을 감시해야 만료를 놓치지 않는가

자산 목록에는 운영 도메인뿐 아니라 리다이렉트 도메인, API 서브도메인, 관리자 도메인, 외부 CDN과 로드밸런서의 종료 지점을 포함합니다. 각 항목에 인증서 만료 시각, SAN 목록, 발급 경로, 갱신 파일 위치, 실제 TLS를 종료하는 장비를 적습니다. 파일 경로만 적으면 장비가 여러 개인 환경에서 어느 지점이 오래된 인증서를 제공하는지 찾지 못합니다.

알림은 D-30, D-14, D-7처럼 여러 임계치를 두고, 같은 경고가 반복되지 않도록 자산 ID와 만료 시각을 키로 삼습니다. 갱신 작업 실패, 배포 후 외부 검증 실패, 만료 임박은 서로 다른 심각도입니다. 만료일이 멀어도 갱신 명령의 dry-run이 실패했다면 발급자 계정·DNS 검증·파일 권한을 즉시 조사해야 합니다.

만료 임계치 알림에서 갱신 dry-run과 외부 핸드셰이크 검증으로 이어지는 대응 흐름

갱신 전 준비: 대상과 증거를 잠그기

작업 시작 전 현재 외부 인증서의 지문, 만료 시각, SAN, 체인을 저장합니다. 이 값은 비밀키가 아니므로 티켓과 모니터링 이벤트에 기록할 수 있지만, 개인키 파일은 기록하거나 복사하지 않습니다. 최근 정상 핸드셰이크 결과도 함께 남겨 갱신 후 무엇이 달라졌는지 비교할 기준선을 만듭니다.

  1. 도메인별 TLS 종료 지점과 담당자를 확인하고 변경 창을 고정합니다.

  2. 발급 도구의 dry-run과 DNS·HTTP 검증 권한을 실행해 봅니다.

  3. 새 인증서의 SAN, 체인, 유효기간을 기존 기준선과 비교합니다.

  4. 모든 TLS 종료 노드에 배포하고 프로세스 reload 또는 교체를 수행합니다.

배포 명령의 종료 코드만으로 성공을 판단하지 않습니다. 각 종료 지점에 대해 외부에서 인증서 체인을 조회하고, 대표적인 최신 클라이언트와 내부 API 클라이언트로 TLS 핸드셰이크를 실행합니다. 캐시나 CDN이 개입하면 원본과 엣지에서 결과가 다를 수 있으므로 두 경로를 분리해 기록합니다.

예시: 다중 노드 API의 D-14 갱신

예시의 입력은 api.example.test가 두 개의 로드밸런서 노드와 하나의 CDN 엣지를 사용하고, 인증서 만료가 14일 남은 상황입니다. 결정은 먼저 발급 도구 dry-run을 통과시키고, 새 인증서를 두 원본 노드에 배포한 뒤 엣지와 외부 클라이언트에서 순서대로 검증하는 것입니다. 중간 산출물은 노드별 지문·SAN·핸드셰이크 결과표입니다. 예상 결과는 세 경로가 모두 같은 새 지문을 제공하고, 기존 지문을 제공하는 노드가 0개인 상태입니다.

인증서 배포 후 체인과 SAN, 핸드셰이크, 알림 해제를 기록하는 완료 체크리스트

한 노드가 이전 지문을 계속 제공하면 로드밸런서에서 해당 노드를 격리하고 reload 방식과 파일 심볼릭 링크를 확인합니다. CDN만 오래된 값을 주면 엣지 캐시의 인증서 배포 상태와 공급자 전파 지연을 확인하되, 원본 교체가 끝났다는 이유로 완료 처리하지 않습니다. 모든 경로의 결과가 일치할 때만 알림을 닫습니다.

실패 유형별 복구와 에스컬레이션

dry-run 실패는 발급 권한, DNS 레코드, HTTP 챌린지 경로, rate limit 순서로 확인합니다. 갱신 파일은 생겼지만 외부 검증이 실패하면 프로세스가 파일을 다시 읽었는지와 체인 설정을 확인합니다. 특정 클라이언트만 실패하면 서버가 제공하는 체인과 클라이언트의 신뢰 저장소 차이를 분리해 재현합니다. 원인을 모른 채 인증서를 반복 발급하면 제한에 걸릴 수 있습니다.

만료가 임박한데 자동 갱신이 복구되지 않으면 비상 변경으로 전환합니다. 준비된 백업 인증서가 실제 도메인과 일치하는지 확인하고, 변경 승인자와 발급자 지원 채널을 동시에 호출합니다. 개인키를 메신저로 전송하거나 검증되지 않은 우회 인증서를 설치하는 것은 대응 시간이 짧아도 선택하지 않습니다. 영향 범위와 다음 업데이트 시각을 상태 페이지나 내부 알림에 남깁니다.

완료 기록과 재발 방지

완료 조건은 갱신 작업의 성공, 모든 TLS 종료 지점의 새 지문, 체인 검증 성공, 대표 클라이언트 핸드셰이크 성공, 만료 알림 해제, 티켓에 증거 링크가 남은 상태입니다. 검증 시각과 실행 주체를 기록해야 나중에 모니터링이 정상으로 돌아온 시점을 설명할 수 있습니다. 단순히 인증서 파일의 수정 시각을 완료 증거로 사용하지 않습니다.

사후에는 자산 목록에 빠진 도메인이 없었는지, dry-run이 실제 장애를 얼마나 앞서 포착했는지, 노드 간 배포 차이가 왜 생겼는지 검토합니다. 다음 회전에서는 만료일 알림과 함께 외부 지문 비교와 체인 검증을 자동화하고, 실패 이벤트가 온콜 담당자에게 도달하는지 시험합니다. 이렇게 해야 인증서 갱신이 담당자의 달력 알림이 아니라 실패를 드러내는 운영 신호가 됩니다.