모두
모두콘텐츠
얼마 전 작은 쇼핑몰의 접속 장애를 확인했는데, 서버 자원은 넉넉했다. 문제는 만료된 SSL 인증서였다. 갱신 작업은 성공했다는 기록이 있었지만 웹서버가 새 인증서를 읽지 않아 방문자에게 경고 화면이 떴다. 서버 사양을 올려도 해결되지 않는 종류의 장애다.
SSL이라는 말을 여전히 많이 쓰지만, 실제 웹 연결에는 TLS가 쓰인다. 인증서는 방문자가 접속한 서버의 신원을 확인하고 암호화 연결을 맺는 데 필요하다. 여기서 운영자가 챙길 일은 비싼 상품을 고르는 것보다 발급 범위, 갱신 경로, 적용 상태를 확인하는 것이다.
먼저 인증서가 필요한 범위를 적는다
블로그 한 개와 관리 화면 한 개를 운영한다면 각 접속 이름이 인증서에 포함되는지부터 확인한다. 같은 서버에 있어도 이름이 빠지면 브라우저는 인증서 오류를 낸다. 도메인 이전이나 관리 화면 분리 때 자주 생기는 실수다.
일반적인 개인 사이트와 소규모 쇼핑몰은 무료 인증서로도 암호화 연결을 운영할 수 있다. 유료 인증서를 산다고 서버 처리량이 늘거나 웹 애플리케이션의 취약점이 사라지는 것은 아니다. 조직 확인 절차나 계약상 요구가 있는지 먼저 보고, 없다면 무료 발급과 자동 갱신을 지원하는 호스팅 상품을 우선 비교한다.
하위 사이트가 몇 개 안 되면 필요한 이름을 인증서에 각각 넣는 편이 관리하기 쉽다. 수십 개의 하위 사이트가 수시로 생길 때는 와일드카드 인증서가 편할 수 있다. 다만 와일드카드는 DNS를 통한 소유 확인이 필요하고, 자동 갱신까지 하려면 DNS 제공 업체의 API 연동 상태도 점검해야 한다. 이름이 많다는 이유만으로 와일드카드를 선택하면 갱신 절차가 오히려 복잡해질 수 있다.
호스팅 종류보다 갱신 책임자를 확인한다
공유 웹호스팅에서는 관리 화면에서 인증서를 켜면 발급과 갱신을 업체가 처리하는 경우가 많다. 월 방문자 수가 적고 별도 서버 설정이 필요 없다면 이 구간에서 충분하다. VPS로 옮기면 설정 자유도는 커지지만 인증서 갱신 작업, 웹서버 재적용, 알림 설정까지 직접 맡아야 한다.
요금제를 비교할 때는 월 방문자 수만 보지 않는다. 예를 들어 하루 방문자 1천 명이라도 대부분이 시간대별로 흩어져 있으면 순간 동시 접속은 낮을 수 있다. 반대로 행사 시작 직후 1분에 수백 명이 몰리면 같은 월 방문자 수라도 서버에 걸리는 부하가 다르다. SSL 때문에 무조건 상위 요금제가 필요한 것은 아니다. 먼저 현재 동시 접속, 페이지 생성 시간, CPU와 메모리 사용량을 본다.
CDN이나 프록시를 앞에 둔 사이트는 구간을 하나 더 확인해야 한다. 방문자와 프록시 사이의 인증서가 정상이어도 프록시와 원본 서버 사이의 연결 설정이 틀리면 오류가 난다. 운영 화면에서 초록색 표시 하나를 보고 끝내지 말고, 원본 서버 인증서의 만료일과 이름도 따로 기록해 둔다.
발급보다 자동 갱신 시험이 중요하다
Let’s Encrypt의 기본 인증서는 현재 90일 유효 기간을 쓰지만, 발급 정책은 앞으로 더 짧은 기간으로 바뀔 예정이다. 그래서 ‘두 달마다 수동으로 교체’ 같은 일정에 기대면 위험하다. 발급 도구가 자동 실행되는지, 실패하면 누가 알림을 받는지, 갱신 뒤 웹서버가 새 파일을 읽는지까지 한 묶음으로 점검해야 한다.
웹서버에서 파일을 확인하는 방식으로 발급한다면 외부에서 80번 포트로 검증 요청이 들어올 수 있어야 한다. 방화벽, 잘못된 DNS 연결, 프록시 설정 때문에 검증이 실패하는 경우가 있다. 서버가 여러 대라면 검증 파일이 어느 서버로 요청돼도 보이도록 구성해야 한다. DNS 방식은 웹서버 포트를 열 필요가 없지만, DNS 변경 권한과 API 자격 정보 관리가 운영 과제가 된다.
- 자동 갱신을 시험 실행하고 성공 또는 실패 기록을 확인한다.
- 갱신 후 실제 방문자가 받는 인증서의 만료일과 접속 이름을 확인한다.
- 만료 30일 전부터 알림을 받도록 설정하고 담당자가 바뀌어도 알림이 유지되는지 확인한다.
- 인증서 파일과 개인키의 보관 위치, 서버 이전 시 복구 절차를 운영 문서에 남긴다.
개인키는 인증서와 다르게 외부에 공개하면 안 된다. 백업할 때도 접근 권한을 제한하고, 유출이 의심되면 새 키로 인증서를 다시 발급하는 편이 안전하다. 자동화 계정에 DNS 전체 수정 권한을 주기보다 필요한 범위만 허용할 수 있는지도 확인한다.
경고 화면이 뜨면 이 순서로 확인한다
장애가 났을 때 첫 단계는 브라우저가 보여 주는 오류 종류를 읽는 것이다. 만료 오류라면 발급 도구의 기록과 실제 서비스에 적용된 인증서가 같은지 본다. 이름 불일치라면 최근 추가한 접속 이름, DNS 변경, 프록시와 원본 서버의 설정을 확인한다. 서버 시간이 크게 틀어져도 유효 기간 판단에 영향을 줄 수 있다.
인증서가 정상인데 일부 화면에서만 경고가 난다면 페이지가 불러오는 이미지, 스크립트, 글꼴의 연결 방식을 살핀다. 암호화된 페이지에 암호화되지 않은 자원이 섞이면 브라우저가 일부 요청을 막을 수 있다. 로그인과 결제 화면부터 확인하고, 오래된 글의 이미지 경로도 점검한다.
전체 방문자를 보안 연결로 보내는 전환은 인증서 적용과 내부 자원 확인을 마친 뒤 진행한다. HSTS처럼 브라우저에 보안 연결만 사용하도록 기억시키는 설정은 특히 신중해야 한다. 설정 후 인증서 장애가 나면 방문자가 경고를 우회하기 어렵다. 처음에는 짧은 적용 기간으로 검증하고, 하위 사이트까지 모두 준비됐을 때 범위를 넓힌다.
SSL 운영비는 인증서 구매 금액보다 장애를 발견하고 고치는 데 드는 시간에서 더 크게 갈린다. 작은 사이트라면 무료 인증서와 기본 호스팅으로 시작해도 충분한 경우가 많다. 대신 갱신 시험, 만료 알림, 이전 시 점검 순서만큼은 비용을 줄일 항목으로 보지 않는다.
