ssl 인증서 갱신할 때 장애 없이 교체하는 방법

얼마 전 인증서 갱신 작업은 성공했다는데 방문자에게는 만료 경고가 뜨는 서버를 봤습니다. 새 파일은 서버에 있었지만 웹서버가 예전 인증서를 계속 내보내고 있었습니다. 운영할 때는 갱신 명령의 성공보다 방문자에게 실제로 어떤 인증서가 전달되는지가 더 중요합니다.

먼저 인증서가 설치된 위치를 찾는다

같은 사이트라도 인증서가 걸린 위치는 다를 수 있습니다. 웹서버에서 직접 암호화 연결을 처리할 수도 있고, 로드 밸런서나 CDN에서 먼저 처리할 수도 있습니다. 이 구간을 확인하지 않고 서버 파일만 바꾸면 작업 화면에서는 성공으로 보여도 방문자 화면은 그대로입니다.

서버에 접속할 수 있다면 웹서버 설정에서 인증서와 개인키 파일 경로를 확인합니다. 관리형 호스팅이라면 제어판의 인증서 메뉴를 보고, CDN을 쓴다면 방문자에게 제공하는 인증서와 CDN이 원본 서버에 연결할 때 쓰는 인증서를 각각 확인해야 합니다. 두 인증서의 만료일이 다를 수 있습니다.

여러 서버가 트래픽을 나눠 받는 구성도 주의할 지점입니다. 서버 두 대 중 한 대만 교체하면 접속할 때마다 정상 화면과 경고 화면이 번갈아 나타날 수 있습니다. 갱신 대상은 ‘서버 한 대’가 아니라 실제 요청을 받는 모든 지점이라고 생각하는 편이 안전합니다.

갱신 전에 이름과 검증 경로를 확인한다

인증서 만료일까지 여유가 있어도 자동 갱신이 실패하는 경우가 있습니다. 흔한 원인은 도메인이 다른 서버를 가리키거나, 검증 요청이 보안 장비에 막히거나, DNS 변경 권한이 만료된 경우입니다. 그래서 저는 만료 30일 전부터 상태를 확인하고, 14일 안으로 들어오면 실패 원인을 바로 처리하는 운영 기준을 둡니다. 이 날짜는 인증기관의 규칙이 아니라 장애를 피하기 위한 제 기준입니다.

• 인증서에 들어 있는 이름이 현재 서비스에 쓰는 이름과 일치하는지 확인합니다. 대표 주소뿐 아니라 함께 쓰는 이름도 빠짐없이 봅니다.
• 도메인의 연결 대상이 갱신을 수행할 서버 또는 서비스와 맞는지 확인합니다. 이전 작업 뒤 오래된 주소가 남아 있는 경우가 있습니다.
• 웹을 통한 소유권 검증이라면 외부 요청이 검증 파일에 도달하는지, DNS 검증이라면 필요한 레코드를 만들 권한과 반영 시간을 확보했는지 봅니다.
• 와일드카드 인증서를 자동 발급한다면 DNS 검증과 그 권한을 가진 계정의 상태를 먼저 확인합니다.

특히 보안 규칙을 바꾼 직후라면 검증 요청이 막히지 않았는지 살펴야 합니다. 갱신 프로그램을 여러 번 실행하는 것보다 요청이 어느 단계에서 끊기는지 찾는 편이 빠릅니다.

발급과 적용을 나눠서 진행한다

갱신 작업은 새 인증서를 발급받는 단계와 서비스에 적용하는 단계로 나뉩니다. 자동 갱신 도구가 새 파일을 받아도 웹서버가 그 파일을 읽도록 설정되지 않았다면 서비스에는 변화가 없습니다. 먼저 발급 결과에서 만료일과 포함된 이름을 확인하고, 웹서버 설정이 실제 새 파일 경로를 가리키는지 봅니다.

그다음 설정 검사로 문법 오류를 확인하고 웹서버를 다시 읽게 합니다. 운영 중인 서버라면 가능한 경우 연결을 끊는 재시작보다 설정 재적용을 택합니다. 다만 프로그램마다 동작이 다르므로 적용 명령의 성공 여부와 실행 중인 프로세스 상태를 함께 확인해야 합니다. 개인키 파일 권한도 이때 봅니다. 웹서버가 읽을 수 없으면 새 인증서가 있어도 시작에 실패할 수 있습니다.

적용 후에는 서버 내부의 파일 날짜로 끝내지 않습니다. 외부에서 실제 서비스 이름으로 접속해 제공되는 인증서의 만료일, 이름, 인증서 체인을 확인합니다. CDN이나 로드 밸런서가 앞에 있다면 각 구간을 따로 확인합니다. 서버가 여러 대면 한 대씩 확인하고, 캐시나 연결 유지 때문에 예전 결과가 보일 수 있으니 새 연결에서도 다시 검사합니다.

수동 업로드 방식이라면 이전 인증서와 개인키를 당장 지우지 않는 편이 좋습니다. 접근 권한을 제한해 보관하고, 되돌릴 절차와 담당자를 기록해 둡니다. 인증서 파일만 복사하고 그에 맞는 개인키를 빠뜨리는 실수는 생각보다 흔합니다.

자동 갱신은 실패 알림까지 연결한다

자동화가 있어도 갱신 작업의 실행 기록을 봐야 합니다. 예약 실행이 꺼졌거나 서버 이전 뒤 이전 경로를 참조할 수 있습니다. 테스트 실행이 가능한 환경이라면 검증과 적용 절차를 미리 점검하고, 실제 갱신 뒤에는 외부에서 보이는 만료일이 바뀌었는지 확인하는 감시를 붙입니다. ‘작업 성공’ 알림 하나만으로는 적용 누락을 잡기 어렵습니다.

만료가 임박했는데 실패했다면 순서를 좁혀 봅니다. 먼저 도메인의 연결 대상과 검증 요청 도달 여부를 확인하고, 다음으로 발급 도구의 오류 기록과 계정 권한을 봅니다. 발급은 됐는데 경고가 계속된다면 웹서버 설정, 인증서 체인, 앞단 장비의 인증서 순서로 확인합니다. 급하다고 인증서 검증을 끄면 방문자의 경고만 다른 위험으로 바뀝니다.

작은 사이트라면 비싼 관리형 요금제보다 갱신 상태를 알려 주는 알림 하나와 적용 확인 절차가 더 큰 효과를 낼 때가 많습니다. 인증서 작업은 새 파일을 받는 순간이 아니라, 방문자가 정상 인증서를 받는 것을 확인했을 때 끝납니다.