SSL 인증서 갱신 방법을 서버별로 확인하는 순서

얼마 전 인증서가 만료됐다는 연락을 받고 서버에 들어갔는데, 새 인증서는 이미 발급돼 있었습니다. 문제는 웹서버가 여전히 예전 인증서를 내보내고 있다는 점이었죠. SSL 인증서 갱신 방법을 찾을 때 발급 명령만 보면 이런 장애를 놓치기 쉽습니다. 저는 누가 인증서를 관리하는지, 갱신이 되는지, 새 인증서가 실제 접속에 쓰이는지 순서대로 확인합니다.

먼저 인증서를 관리하는 곳부터 찾습니다

브라우저에서 인증서 만료일과 발급자를 확인하고, 서버 설정에서 인증서 파일 경로를 찾습니다. 같은 사이트라도 인증서가 설치된 곳은 다를 수 있습니다. 공유호스팅의 관리 화면일 수도 있고, VPS의 Nginx·Apache, 로드밸런서, CDN일 수도 있습니다. CDN에서 접속을 받는다면 방문자가 보는 인증서와 CDN이 원본 서버에 연결할 때 쓰는 인증서도 따로 확인해야 합니다.

서버에서 Certbot을 쓴다면 certbot certificates 명령으로 관리 중인 인증서 이름, 대상 호스트명, 만료일, 파일 경로를 볼 수 있습니다. 화면에 아무것도 나오지 않는다고 인증서가 없는 것은 아닙니다. 호스팅 업체가 발급했거나 다른 ACME 클라이언트를 쓸 수도 있으니 웹서버 설정의 인증서 경로와 운영 화면을 대조해야 합니다. 예전에 서버를 이전하면서 발급 도구만 새 서버에 설치하고 실제 서비스는 옛 서버의 인증서를 바라보는 경우도 있었습니다.

관리형 호스팅과 직접 운영 서버의 갱신 순서

공유호스팅이나 관리형 서비스라면 우선 자동 갱신 설정과 도메인 연결 상태를 확인합니다. 업체 화면에서 갱신 버튼을 눌렀더라도 적용 상태와 외부 접속에서 보이는 만료일이 같아야 끝난 겁니다. 유료 인증서는 결제 갱신과 서버 설치가 별개인 경우가 있습니다. 새 인증서, 개인키, 중간 인증서가 올바른 묶음인지 확인한 뒤 서비스에 적용해야 합니다.

VPS에서 Certbot으로 발급했다면 certbot renew --dry-run으로 다음 갱신이 통과하는지 먼저 시험합니다. 그다음 systemctl list-timers 또는 크론 설정에서 갱신 작업이 실제로 예약돼 있는지 봅니다. 설치 방식에 따라 예약 위치가 다르므로 작업이 중복 등록돼 있지 않은지도 확인합니다. certbot renew는 갱신 대상 시점이 된 인증서를 처리합니다. 실행 결과가 ‘갱신할 인증서 없음’이라면 실패라고 단정할 필요는 없습니다.

자동 갱신이 성공해도 웹서버가 새 파일을 읽어야 접속자에게 적용됩니다. Nginx는 nginx -t로 설정을 검사한 뒤 다시 읽히고, Apache도 설정 검사 후 다시 읽히게 합니다. 재시작이 필요한 구성인지, 갱신 성공 후에만 실행되는 배포 훅이 있는지도 살핍니다. Certbot의 시험 갱신이 성공했다는 사실만으로 서비스의 인증서 교체까지 검증된 것은 아닙니다.

갱신이 실패하면 인증 방식부터 확인합니다

Let’s Encrypt의 HTTP-01 인증은 외부에서 서버의 80번 포트로 접속해 검증 파일을 읽는 방식입니다. 도메인의 DNS가 다른 서버를 가리키거나, 방화벽이 80번 포트를 막거나, 프록시가 검증 요청을 엉뚱한 곳으로 보내면 실패합니다. 웹서버를 여러 대 운영한다면 검증 요청이 어느 서버로 들어와도 같은 파일을 제공할 수 있어야 합니다. 리다이렉트나 보안 규칙을 바꾼 직후라면 그 경로도 함께 봅니다.

와일드카드 인증서에 쓰는 DNS-01 인증은 지정된 TXT 레코드가 외부에서 조회돼야 합니다. DNS 관리 화면에 값을 넣었다는 것과 실제 조회가 되는 것은 다릅니다. 수동으로 TXT 레코드를 입력해 발급했다면 다음 갱신도 자동으로 된다고 가정하면 안 됩니다. DNS 업체의 API를 이용하는 자동화가 설정돼 있는지, 해당 API 권한이 살아 있는지 확인해야 합니다.

• 갱신 오류가 나면 먼저 실패한 호스트명과 인증 방식을 기록합니다.
• DNS 대상, 방화벽, 검증 경로 또는 TXT 레코드를 해당 방식에 맞춰 확인합니다.
• 설정을 고친 뒤 시험 갱신을 다시 실행하고, 성공 로그까지 봅니다.

만료가 임박했다고 새 인증서를 반복 발급하기보다 첫 실패 원인을 고치는 편이 빠릅니다. 발급 요청에는 제한이 있을 수 있고, 새 인증서를 여러 장 만들어도 서비스가 오래된 파일을 가리키면 장애는 그대로입니다.

갱신 뒤에는 외부에서 보이는 인증서를 확인합니다

마지막 확인은 서버의 파일 날짜가 아니라 실제 접속 결과로 합니다. 브라우저의 인증서 정보에서 만료일과 대상 호스트명을 보고, 대표 주소 외에 별도 서브도메인도 사용한다면 각각 확인합니다. 로드밸런서 뒤에 서버가 여러 대 있으면 한 대에만 새 인증서가 적용돼 간헐적으로 경고가 뜰 수 있습니다. 이 경우 요청을 여러 번 보내거나 각 장비의 인증서 배포 상태를 확인해야 합니다.

운영 중에는 만료 7일 전쯤 처음 경고를 받는 설정보다 여유 있게 알림을 두는 편이 낫습니다. Let’s Encrypt는 인증서 유효기간을 단계적으로 줄일 계획이어서, 90일마다 달력을 보고 수동 처리하는 방식은 갈수록 불안합니다. 자동 갱신 작업, 실패 알림, 실제 서비스 인증서의 만료일 감시를 함께 두면 비용을 더 쓰지 않고도 사고를 줄일 수 있습니다.

제가 운영할 때 가장 신경 쓰는 지점은 ‘갱신 성공’이라는 로그 다음입니다. 파일이 바뀌었는지, 웹서버가 읽었는지, 방문자에게 새 인증서가 전달되는지까지 확인해야 안심하고 다음 작업으로 넘어갈 수 있습니다.