모두
모두콘텐츠
얼마 전 서버 이전을 도왔는데, 사이트 파일과 데이터베이스는 옮겼어도 인증서 갱신 설정은 빠져 있었습니다. 이전 당일에는 멀쩡했고, 두 달 뒤 접속 경고가 떴죠. ssl 인증서 발급 자체보다 발급 조건을 확인하고 갱신이 계속되는지 점검하는 일이 더 중요합니다.
먼저 인증서를 어디에 설치할지 확인합니다
웹호스팅이라면 관리 화면에 무료 인증서와 자동 갱신 기능이 있는지 먼저 봅니다. 이 기능이 정상적으로 제공된다면 작은 블로그에 별도 유료 인증서를 살 이유는 거의 없습니다. 방문자가 많아진다고 인증서 등급을 올려야 하는 것도 아닙니다. 서버 사양은 트래픽과 동시접속으로 판단하고, 인증서는 접속 지점과 관리 방식으로 판단하는 편이 맞습니다.
VPS에서 직접 웹서버를 운영한다면 인증서 파일과 개인키를 어느 서버가 사용하는지 확인해야 합니다. 프록시나 CDN이 앞에 있으면 방문자와 프록시 사이, 프록시와 원본 서버 사이의 보안 접속을 각각 살펴야 합니다. 앞쪽 인증서만 정상이라고 원본 서버 설정까지 끝난 것은 아닙니다. 로드 밸런서에서 접속을 처리한다면 인증서를 웹서버가 아닌 로드 밸런서에 설치하는 구성도 있습니다.
발급 전에 인증서에 넣을 이름을 적어 둡니다. 기본 도메인과 별도 호스트 이름을 함께 쓴다면 필요한 이름이 모두 포함돼야 합니다. 와일드카드 인증서는 여러 하위 이름에 편리하지만 기본 도메인까지 자동으로 포함하지는 않습니다. 실제 접속에 쓰는 이름을 기준으로 신청해야 설치 후 이름 불일치 경고를 피할 수 있습니다.
발급 실패를 막는 사전 점검
가장 흔한 실패 원인은 DNS가 다른 서버를 가리키는 경우입니다. 서버를 이전했다면 주소 기록을 바꾼 뒤 외부에서 새 서버로 연결되는지 확인합니다. IPv4 기록만 고쳤는데 남아 있는 IPv6 기록이 옛 서버를 가리키는 일도 있습니다. 인증기관이 어느 주소로 검증 요청을 보낼지 운영자가 임의로 정할 수 없으니 둘 다 확인하는 게 안전합니다.
일반적인 웹 파일 검증은 외부에서 80번 포트로 들어와 지정된 파일을 읽는 방식입니다. 방화벽, 보안 그룹, 프록시 규칙이 이 요청을 막으면 발급이 실패합니다. 다른 포트로 웹서버를 띄워 놓고 80번 포트 검증도 되겠지 생각하면 안 됩니다. 여러 서버가 같은 이름으로 응답하는 구성이라면 검증 파일이 어느 서버에서도 보여야 합니다. 리디렉션을 여러 번 거치거나 로그인 화면으로 보내는 설정도 점검합니다.
80번 포트를 열 수 없거나 와일드카드 인증서가 필요하면 DNS TXT 기록으로 소유권을 확인하는 방식을 씁니다. 이때는 실제로 DNS를 관리하는 곳에서 기록을 추가할 권한이 필요합니다. 갱신까지 자동화하려면 DNS 업체가 자동 변경 기능을 제공하는지도 확인해야 합니다. 수동으로 기록을 넣어 발급한 뒤 갱신 시점에 같은 작업을 잊는 사고가 꽤 많습니다.
호스팅과 VPS에서 발급하는 순서
웹호스팅 관리 화면
관리 화면에서 대상 도메인을 연결하고 무료 인증서 신청 기능을 실행합니다. 발급이 끝나면 보안 접속으로 실제 페이지를 열어 경고가 없는지 확인합니다. 화면에 ‘발급 완료’가 떠도 사이트가 다른 인증서를 내보내는 경우가 있습니다. 도메인 연결 위치와 인증서 적용 대상이 같은지 봐야 합니다. 자동 갱신 상태와 실패 알림을 받을 연락처도 이때 확인합니다.
직접 운영하는 VPS
웹서버 설정과 DNS가 맞는 상태에서 Certbot 같은 ACME 클라이언트를 사용합니다. Nginx를 직접 운영하는 단일 서버라면 해당 웹서버용 기능으로 인증서를 발급하고 설정을 적용할 수 있습니다. 실행 전에는 웹서버 설정 검사로 오류가 없는지 확인하고, 현재 설정 파일을 백업합니다. 발급 도중 설정이 바뀌므로 접속이 적은 시간에 작업하는 편이 좋습니다.
설치 직후에는 인증서의 대상 이름, 유효기간, 실제로 제공되는 인증서를 확인합니다. 이어서 일반 접속을 보안 접속으로 보내고, 사이트 내부의 이미지나 스크립트가 안전하지 않은 방식으로 불러와지지 않는지도 봅니다. 인증서만 설치하고 이전 주소를 호출하는 요소를 그대로 두면 브라우저 경고가 남을 수 있습니다. 이 단계는 서버 로그와 브라우저 개발자 도구를 함께 보면 빠릅니다.
자동 갱신은 발급 당일에 시험합니다
Let’s Encrypt의 기본 인증서 수명은 현재 90일이지만 앞으로 더 짧아질 예정입니다. 만료일을 외워 두고 수동으로 재발급하는 방식은 운영 절차로 보기 어렵습니다. Certbot 설치 방식에 따라 갱신용 예약 작업이 이미 설정될 수 있으니, 중복 작업을 만들기 전에 현재 예약 상태부터 확인합니다.
Certbot을 쓴다면 발급 직후 certbot renew --dry-run으로 갱신 과정을 시험합니다. 성공 메시지만 볼 게 아니라 갱신 뒤 웹서버가 새 인증서를 읽도록 다시 불러오는 설정도 확인해야 합니다. DNS 검증을 쓴다면 자동 변경 권한이 남아 있는지, 웹 파일 검증을 쓴다면 80번 포트와 검증 경로가 계속 열려 있는지가 관건입니다. 방화벽이나 프록시 설정을 바꾼 날에는 갱신 시험을 다시 하는 편이 안전합니다.
만료 감시는 서버 안의 예약 작업과 별도로 두는 게 좋습니다. 서버가 멈추면 서버 안의 갱신 작업과 알림도 함께 멈출 수 있기 때문입니다. 인증서 파일과 개인키, 갱신 설정을 백업할 때는 개인키 접근 권한을 제한하고 복구 절차까지 확인합니다. 서버 이전 후에는 옛 서버의 예약 작업이 성공했는지가 아니라 새 서버가 실제로 갱신할 수 있는지를 시험해야 합니다.
인증서 비용을 먼저 비교하기보다 지금 쓰는 호스팅의 무료 발급 기능과 자동 갱신 상태를 확인하는 편이 실속 있습니다. 운영하면서 접속 경고를 막아 준 것은 비싼 상품보다 DNS 확인, 갱신 시험, 만료 감시 같은 작은 점검들이었습니다.
