모두
모두콘텐츠
얼마 전 인증서가 만료된 사이트를 확인했는데, 새 인증서 파일은 이미 서버에 있었습니다. 웹서버가 예전 파일을 계속 읽고 있었죠. 이런 일을 겪으면 ‘ssl인증서 갱신 몇일전’이라는 질문에 날짜 하나만 답하기 어렵습니다. 발급에 성공한 날과 방문자에게 새 인증서가 보이는 날은 다를 수 있습니다.
수동 갱신은 30일 전부터, 자동 갱신은 매일 확인한다
운영 기준으로 수동 갱신은 만료 30일 전부터 시작합니다. 발급기관의 고정 규칙이 아니라 문제를 고칠 시간을 확보하려는 기준입니다. 도메인 소유 확인이 실패하거나 담당자가 휴가 중이어도 한두 번 다시 시도할 여유가 있습니다. 14일 전까지 실제 교체를 끝내고, 7일 전에도 예전 인증서가 보이면 장애 위험으로 취급하는 편이 안전합니다.
자동 갱신을 쓰는 서버라면 30일 전 아침에 사람이 명령을 실행할 필요는 없습니다. 갱신 작업이 매일 실행되게 두고, 인증서와 클라이언트가 정한 시점에 발급하도록 맡깁니다. 렛츠인크립트는 ACME 클라이언트가 참고할 수 있는 권장 갱신 기간도 제공합니다. 그래서 ‘며칠 전에 실행할까’보다 ‘오늘 실패하면 누가 알 수 있나’를 먼저 확인해야 합니다.
2026년 11월 기준, CA/브라우저 포럼 규칙상 2026년 3월 15일 이후 발급된 공개 TLS 인증서의 최대 유효기간은 200일입니다. 다만 이것이 모든 인증서의 실제 유효기간이라는 뜻은 아닙니다. 렛츠인크립트의 기본 인증서는 현재 90일이며, 2027년 2월부터 기본 유효기간을 64일로 줄일 예정입니다. 예전에 받아 둔 ‘1년짜리’ 일정표를 계속 쓰면 갱신 시점을 놓치기 쉽습니다.
만료일보다 실제 서비스 인증서를 먼저 본다
호스팅 관리 화면에 적힌 만료일만 믿으면 엇갈릴 수 있습니다. 인증서가 놓인 곳이 웹서버인지, 로드밸런서인지, CDN인지부터 확인해야 합니다. 방문자는 가장 앞에서 암호화 연결을 맺는 장비의 인증서를 봅니다. 원본 서버 파일을 바꿔도 앞단 장비에 예전 인증서가 남아 있으면 경고가 계속 뜹니다.
확인할 값은 세 가지입니다. 방문자에게 보이는 인증서의 만료일, 인증서에 포함된 호스트 이름, 그리고 실제로 TLS를 종료하는 장비입니다. 대표 주소뿐 아니라 별도 서브도메인과 관리자 화면도 목록에 넣습니다. 인증서 파일의 날짜와 브라우저에서 보이는 날짜가 다르면 갱신 자체보다 배포 경로를 의심하는 게 빠릅니다.
예를 들어 인증서가 12월 1일 만료라면 11월 1일에 자동 갱신 작업과 검증 경로를 점검하고, 11월 17일까지 새 인증서가 외부에서 보이는지 확인합니다. 11월 24일에도 옛 인증서가 보이면 담당자에게 즉시 알리고 원인을 추적합니다. 날짜는 운영 예시입니다. 중요한 건 만료일까지 남은 시간을 ‘발급’, ‘설치’, ‘외부 확인’에 나눠 쓰는 것입니다.
자동 갱신에서 자주 막히는 지점
첫째는 도메인 소유 확인입니다. 렛츠인크립트의 HTTP 방식은 80번 포트로 들어오는 검증 요청을 처리해야 합니다. 방화벽을 바꿨거나 프록시 경로를 손봤다면 평소 사이트는 열리는데 갱신만 실패할 수 있습니다. 와일드카드 인증서에 쓰는 DNS 방식은 TXT 레코드 갱신과 전파를 확인해야 합니다. DNS 제공업체의 자동화 권한이 만료되거나 빠진 경우도 흔합니다.
둘째는 실행 주체입니다. 서버를 이전하면서 웹 파일과 데이터베이스는 옮겼지만 갱신 예약 작업은 빠뜨리는 일이 있습니다. Certbot을 쓴다면 예약 작업이 실제로 등록됐는지, 마지막 실행 결과가 무엇인지 확인합니다. 시험 갱신 명령으로 검증 경로를 점검할 수도 있습니다. 단, 시험이 성공했다고 실제 서비스에 새 인증서가 설치된 것은 아닙니다.
셋째는 적용 단계입니다. 발급된 인증서를 웹서버가 읽는 위치에 배포하고, 필요한 경우 설정을 다시 읽게 해야 합니다. Certbot의 배포 후 작업은 갱신이 성공했을 때 실행되도록 지정할 수 있습니다. 여러 대의 서버를 운영한다면 한 대만 새 인증서로 바뀌지 않았는지도 봐야 합니다. 접속할 때마다 경고가 나타났다 사라진다면 서버별 적용 상태가 다른 경우가 있습니다.
알림과 복구 절차는 짧게 만들어 둔다
저는 만료 14일 전에 담당자에게 알림이 가고, 7일 전부터는 매일 확인하도록 잡습니다. 3일 전인데 외부에서 새 인증서가 보이지 않으면 다른 운영 작업보다 먼저 처리합니다. 이 숫자는 발급기관이 정한 의무가 아니라 작은 사이트에서도 무리 없이 쓸 수 있는 운영 기준입니다. 자동 갱신이 정상이라면 이런 알림은 거의 오지 않아야 합니다.
알림은 서버 안의 파일 날짜만 보지 말고 외부 접속 결과를 기준으로 거는 편이 낫습니다. 발급 성공 기록이 남아도 배포 스크립트가 실패할 수 있기 때문입니다. 장애가 나면 만료일을 확인한 뒤 검증 실패인지, 발급 실패인지, 배포 실패인지 순서대로 좁힙니다. 새 인증서를 급히 여러 번 발급하기 전에 기존 파일과 웹서버 설정이 가리키는 위치부터 대조합니다.
백업에는 인증서 파일만이 아니라 갱신 설정, 검증 방식, 배포 절차도 포함해야 합니다. 다만 개인키는 접근 권한을 제한하고 복구할 때 필요한 사람만 다뤄야 합니다. 저가 호스팅이든 VPS든 이 부분에 큰 비용이 들지는 않습니다. 만료 30일 전부터 상태를 확인하고 실제 서비스 화면까지 검증하는 습관이, 비싼 요금제로 바꾸는 것보다 인증서 장애를 더 확실하게 줄입니다.
