모두
모두콘텐츠
얼마 전 사이트 이전을 도왔는데, 새 서버에서는 화면이 잘 뜨는데 일부 방문자에게만 보안 경고가 나왔다. 서버 사양을 올릴 문제가 아니었다. 도메인은 새 서버를 가리키고 있었지만 인증서에는 방문자가 실제로 입력한 이름이 빠져 있었다. 도메인HTTPS 설정은 서버에 인증서 파일을 넣는 작업보다, 방문자가 접속하는 이름부터 갱신 절차까지 맞추는 작업에 가깝다.
접속할 도메인 이름부터 확정한다
먼저 방문자가 사용할 이름을 적어둔다. 대표 도메인 하나만 쓸지, 블로그나 쇼핑몰처럼 앞에 이름이 붙은 주소도 쓸지 결정해야 한다. 인증서는 이름을 기준으로 검사한다. 대표 도메인용 인증서가 다른 하위 도메인까지 자동으로 보호한다고 생각하면 이전 날에 경고를 만나기 쉽다.
DNS에서는 해당 이름이 어느 서버로 향하는지 확인한다. IPv4 주소를 쓰면 A 레코드, IPv6 주소를 쓰면 AAAA 레코드를 본다. 특히 IPv6를 열어둔 채 새 서버의 IPv4 주소만 바꾸는 일이 잦다. 그러면 방문자의 접속 환경에 따라 서로 다른 서버로 들어간다. 이전 전에는 기존 레코드와 새 레코드를 기록하고, 변경 후에는 외부 네트워크에서도 접속 결과를 확인하는 편이 안전하다.
DNS 변경 직후 모든 방문자가 동시에 새 서버로 오지는 않는다. 캐시와 TTL 때문에 일정 시간 구 서버와 신 서버에 요청이 나뉠 수 있다. 따라서 구 서버를 바로 내리기보다 두 서버 모두 정상 화면을 보여주는 기간을 잡는다. 로그인이나 주문이 있는 사이트라면 이 기간에 데이터가 양쪽으로 갈라지지 않도록 쓰기 경로도 따로 계획해야 한다.
인증서는 실제 접속 경로에 설치한다
인증서를 발급받을 때는 도메인 소유 확인 방식부터 정한다. 일반적인 웹 검증은 외부에서 서버에 접근할 수 있어야 한다. 방화벽, 프록시, 호스팅사의 보안 설정이 검증 요청을 막으면 발급이 실패한다. DNS 검증은 웹서버를 열지 않고도 진행할 수 있지만, DNS 설정을 바꿀 권한과 자동화 방법을 챙겨야 한다. 여러 하위 도메인을 한꺼번에 다루는 와일드카드 인증서도 보통 DNS 검증을 사용한다.
웹서버가 직접 TLS 연결을 받는지, 앞단의 로드밸런서나 프록시가 받는지도 확인한다. 방문자의 브라우저가 먼저 만나는 장비에 올바른 인증서가 있어야 한다. 앞단에서 암호화를 끝내고 내부 서버로 전달한다면, 내부 통신 범위와 프록시 설정을 함께 점검한다. 여기서 설정이 어긋나면 접속은 되는데 로그인 뒤에 계속 이동하거나 보안 쿠키가 전달되지 않는 증상이 생긴다.
무료 인증서로 충분한 사이트도 많다. 비용보다 중요한 것은 인증서가 필요한 모든 이름을 포함하는지, 자동 갱신이 실제로 돌아가는지다. 서버가 한 대인 작은 사이트에 인증서 상품부터 비싸게 권하는 경우를 보면 아쉽다. 정작 장애를 만드는 쪽은 발급 비용이 아니라 빠진 도메인 이름이나 멈춘 갱신 작업인 경우가 많았다.
전환은 접속 확인 뒤에 진행한다
새 인증서를 설치한 다음에는 대표 도메인과 사용하는 하위 도메인 각각으로 접속한다. 브라우저의 자물쇠 표시만 보지 말고 인증서의 이름, 만료일, 인증서 체인이 맞는지 확인한다. 모바일 데이터처럼 사무실과 다른 네트워크에서도 시험하면 DNS 캐시 때문에 놓친 문제를 찾기 쉽다.
그다음 일반 접속을 암호화 접속으로 보내는 이동 설정을 적용한다. 순서가 중요하다. 암호화 접속 자체가 실패하는 상태에서 이동부터 강제하면 방문자는 정상 화면으로 돌아갈 길이 없다. 이동이 여러 번 반복되지 않는지, 로그인과 관리자 화면이 정상인지도 확인한다. 웹서버 뒤에 프록시가 있다면 원래 요청이 암호화되어 있었다는 정보가 앱까지 정확히 전달되는지도 봐야 한다.
화면은 뜨는데 이미지나 스크립트가 차단된다면 혼합 콘텐츠를 의심한다. 페이지는 암호화 접속인데 내부 자원을 일반 접속으로 불러올 때 생긴다. 사이트 이전 후에는 테마 설정, 게시글 본문, 앱의 기본 주소 설정에 예전 경로가 남아 있기도 하다. 자원 경로를 고친 뒤 주요 페이지 몇 개를 직접 열어보는 것이 빠르다.
HSTS처럼 브라우저가 이후에도 암호화 접속을 강제하도록 하는 설정은 모든 하위 도메인의 준비 상태를 확인한 뒤 적용한다. 범위를 넓게 잡으면 인증서가 없는 오래된 서비스까지 접속이 막힐 수 있다. 처음에는 짧은 적용 기간으로 동작을 확인하는 편이 운영상 부담이 적다.
만료일보다 갱신 실패를 먼저 감시한다
자동 갱신을 설정했다면 실제 갱신 시험까지 해야 한다. 발급은 성공했어도 예약 작업이 실행되지 않거나, 갱신된 인증서를 웹서버가 다시 읽지 않아 예전 인증서가 계속 제공될 수 있다. 만료일 알림은 여유를 두고 받고, 갱신 작업의 실패 로그와 외부에서 보이는 인증서 만료일을 함께 확인한다.
서버 이전을 대비해 인증서 발급 방식, DNS 검증에 필요한 권한, 웹서버 설정 파일 위치를 운영 기록에 남긴다. 인증서 개인키와 DNS 관리 권한은 접근 대상을 제한하고 안전한 곳에 보관한다. 백업에는 웹서버 설정과 복구 절차도 포함해야 한다. 파일만 복원해 놓고 어떤 이름으로 인증서를 다시 발급해야 하는지 몰라 복구가 늦어지는 일을 여러 번 봤다.
장애가 나면 저는 DNS가 맞는 서버를 가리키는지, 그 서버가 올바른 인증서를 내보내는지, 이동 설정이 반복되는지 순서대로 본다. 이 세 단계만 분리해도 원인을 찾는 시간이 꽤 줄어든다. 작은 사이트라면 서버 사양을 올리기 전에 접속 경로와 갱신 작업부터 확인하는 쪽이 대개 더 실질적인 투자다.
