모두
모두콘텐츠
얼마 전 사이트 이전을 도왔는데, 새 서버에 웹 파일과 데이터베이스는 잘 옮겨 놓고도 접속이 막혔다. 새 서버가 해당 사이트 이름의 TLS인증서를 내보내지 않고 있었기 때문이다. 서버가 정상이고 방화벽도 열려 있는데 브라우저에는 보안 경고만 뜨는 상황이었다. 이런 일은 인증서 가격보다 발급 방식과 갱신 절차를 먼저 확인하면 대부분 피할 수 있다.
인증서는 접속자가 만나는 서버에 설치한다
TLS인증서는 브라우저가 접속한 서버의 신원을 확인하고 통신을 암호화하는 데 쓰인다. 운영할 때 먼저 볼 것은 인증서 파일의 위치다. 웹서버가 직접 접속을 받는다면 그 웹서버에, 로드밸런서나 CDN이 앞에서 암호화 연결을 처리한다면 그 장비나 서비스에 인증서가 있어야 한다. 원본 서버까지 암호화할 계획이라면 앞단과 원본 사이의 설정도 따로 확인해야 한다.
가령 VPS 한 대에서 사이트 하나를 운영한다면 웹서버의 자동 발급 기능으로 충분한 경우가 많다. 반대로 로드밸런서 뒤에 서버가 세 대 있다면 인증서를 세 대에 복사할지부터 고민할 일이 아니다. 외부 연결이 어디서 끝나는지 확인한 뒤 그 지점의 인증서와 원본 연결 방식을 정해야 한다. 이 순서를 거꾸로 잡으면 인증서는 설치했는데 방문자에게는 여전히 예전 인증서가 보인다.
인증서에 포함할 이름도 실제 접속 경로를 기준으로 적는다. 대표 주소만 등록하고 별도로 쓰는 관리 화면이나 다른 호스트 이름을 빠뜨리면 그 경로에서 경고가 난다. 와일드카드 인증서를 쓰더라도 기본 이름까지 자동으로 모두 포함되는 것은 아니므로 발급 목록을 확인해야 한다. 운영 중인 호스트 이름을 먼저 적어 두는 편이 안전하다.
무료 인증서로 충분한 구간을 계산한다
월 방문자가 1만 명인 사이트와 100만 명인 사이트가 인증서 가격을 달리 책정해야 하는 것은 아니다. 인증서 비용은 서버의 처리 용량을 사는 비용과 별개다. 일반적인 웹사이트에서 필요한 것이 도메인 통제 확인과 암호화 연결이라면 호스팅 업체의 무료 인증서나 Let’s Encrypt 자동 발급으로 충분한 경우가 많다. 유료 상품을 선택하기 전에 비용이 실제로 어떤 운영 요구를 해결하는지 확인한다.
호스팅 상품을 비교할 때는 인증서 제공 여부보다 설치와 갱신을 누가 맡는지가 더 중요하다. 월 몇 천 원짜리 공유 호스팅이라도 자동 갱신과 장애 알림이 잘 붙어 있으면 작은 사이트에는 편하다. VPS는 서버 설정을 직접 바꿀 수 있지만 갱신 작업, 방화벽, 웹서버 재적용까지 운영자가 책임져야 한다. 같은 무료 인증서라도 관리 비용은 다르다.
트래픽 때문에 상위 서버로 옮길지 판단할 때도 인증서부터 바꿀 필요는 없다. 예를 들어 하루 방문자 3천 명이라도 특정 시간에 동시 접속이 10명 안팎이고 정적 파일 비중이 높다면 작은 서버로 버틸 수 있다. 반면 동시 접속 200명이 로그인과 검색을 반복한다면 CPU, 메모리, 데이터베이스 응답 시간을 따져야 한다. 인증서 비용을 서버 사양 문제와 섞으면 견적만 커진다.
발급보다 갱신이 계속 되는지 확인한다
Let’s Encrypt의 기본 인증서 유효기간은 현재 90일이다. 그래서 한 번 발급받아 놓고 달력에만 적어 두는 방식은 오래가기 어렵다. 자동 갱신 작업이 예약돼 있는지, 갱신 뒤 웹서버가 새 인증서를 실제로 읽는지, 실패 알림이 운영자에게 오는지까지 한 묶음으로 본다. 파일의 만료일이 바뀌어도 서비스가 이전 파일을 내보내면 방문자는 그대로 경고를 본다.
발급 확인 방식에 따라 막히는 지점도 다르다. HTTP 방식은 외부에서 80번 포트의 확인 파일에 접근할 수 있어야 한다. 방화벽을 닫았거나 프록시가 확인 요청을 다른 서버로 보내면 실패할 수 있다. DNS 방식은 DNS에 확인 값을 넣으므로 와일드카드 인증서에 쓸 수 있지만, 자동화에 쓰는 DNS 접근 권한은 필요한 범위로 제한해야 한다. 서버가 여러 대라면 확인 요청이 어느 서버로 들어와도 처리되는지 점검한다.
- 갱신 작업의 최근 실행 기록과 오류 메시지를 확인한다.
- 실제 서비스가 내보내는 인증서의 만료일과 호스트 이름을 확인한다.
- 만료 전에 알림이 오도록 별도 감시를 둔다.
자동화는 설정 화면에서 ‘활성’이라고 보이는 것으로 끝나지 않는다. 갱신을 시험 실행하고, 설정을 다시 읽힌 뒤 외부 접속 기준으로 새 인증서가 보이는지 확인해야 한다. 특히 서버 이전 직후에는 예전 서버의 갱신 작업만 살아 있고 새 서버에는 아무 작업도 없는 경우가 있다.
이전과 장애 때는 확인 순서를 고정한다
사이트를 옮길 때는 새 서버에서 인증서 발급과 웹서버 설정을 먼저 마친 다음 접속 경로를 바꾼다. DNS 변경 전에도 새 서버가 올바른 인증서를 내보내는지 테스트할 수 있다. 접속 경로를 바꾼 뒤에는 대표 화면뿐 아니라 로그인, 관리자 화면, 이미지와 스크립트까지 확인한다. 페이지는 열려도 일부 파일을 암호화되지 않은 방식으로 불러오면 브라우저에서 차단하거나 경고를 표시할 수 있다.
장애가 나면 순서를 짧게 잡는 게 빠르다. 먼저 DNS가 의도한 서버를 가리키는지 보고, 다음으로 443번 포트에 접속되는지 확인한다. 연결이 된다면 실제로 제공되는 인증서의 만료일, 포함된 이름, 인증서 체인을 본다. 그다음 웹서버 설정과 갱신 기록을 확인한다. 인증서 오류인데 데이터베이스부터 재시작하면 원인만 흐려진다.
개인키는 인증서와 다르게 외부에 노출되면 안 되는 운영 자산이다. 이전 과정에서 메신저로 보내거나 여러 서버에 무심코 복사하지 말고, 접근 권한과 보관 위치를 기록해 둔다. 백업에는 인증서 파일만 담을지, 개인키와 복구 절차까지 포함할지 운영 구조에 맞게 정해야 한다. 저는 새 서버를 띄울 때 인증서가 발급되는지만 보지 않는다. 다음 갱신 시점에 누가, 어떤 작업으로, 실패를 어떻게 알아챌지까지 확인해야 이전이 끝났다고 본다.
