모두
모두콘텐츠
얼마 전 인증서는 정상 발급됐는데 브라우저에서 보안 경고가 뜬다는 연락을 받았다. 서버에 접속해 보니 새 인증서는 디스크에 있었지만 웹서버가 여전히 예전 파일을 읽고 있었다. SSL설치는 발급 버튼을 누르는 일보다 실제 접속 경로와 갱신 상태를 확인하는 일이 더 중요하다.
설치 전에 접속 경로부터 확인한다
먼저 방문자의 요청이 어디에서 암호화되는지 확인한다. 웹호스팅은 관리 화면에서 처리하는 경우가 많고, VPS는 Nginx나 Apache가 직접 인증서를 읽는다. 로드밸런서나 CDN을 쓰면 앞단에서 암호화가 끝날 수도 있다. 이때 원본 서버에 인증서를 설치해도 방문자에게 표시되는 인증서는 바뀌지 않는다.
인증서에 넣을 이름도 실제 접속 이름과 맞아야 한다. 대표 주소와 앞에 www가 붙는 주소를 모두 운영한다면 두 이름이 포함되는지 확인한다. 주소를 하나로 통일할 계획이라도 다른 주소에서 먼저 보안 경고가 나면 리디렉션까지 도달하지 못할 수 있다. DNS의 A·AAAA 레코드가 현재 서버를 가리키는지, 이전 서버나 사용하지 않는 IPv6 주소가 남아 있지 않은지도 이때 본다.
웹호스팅과 VPS는 설치 위치가 다르다
웹호스팅은 제공 기능을 먼저 확인한다
공유 웹호스팅이라면 관리 화면의 무료 인증서와 자동 갱신 기능부터 확인한다. 월 방문자 수가 적은 개인 블로그나 소규모 회사 사이트에 SSL설치만을 위해 상위 요금제나 별도 VPS가 필요한 경우는 드물다. 인증서 발급 비용보다 관리 화면에서 대상 주소를 제대로 선택했는지, 자동 갱신이 켜져 있는지가 더 중요하다.
발급이 실패하면 DNS가 다른 서버를 가리키거나 도메인 연결이 아직 끝나지 않은 경우가 흔하다. 호스팅 업체가 앞단 프록시를 운영한다면 인증서 적용 위치도 확인해야 한다. 관리 화면에 ‘발급 완료’라고 보여도 실제 방문 경로에 적용됐다는 뜻은 아니다.
VPS는 검증 방식과 웹서버 설정을 맞춘다
VPS에서 Nginx나 Apache를 직접 운영한다면 먼저 현재 가상 호스트 설정과 설정 파일을 백업한다. 일반적인 무료 인증서는 ACME 클라이언트로 발급과 갱신을 자동화할 수 있다. Let’s Encrypt의 HTTP-01 검증을 쓴다면 외부에서 80번 포트로 해당 서버에 접근할 수 있어야 한다. 방화벽, 보안 그룹, 프록시 설정 중 한 곳만 막혀도 발급이 실패한다.
와일드카드 인증서가 필요하거나 웹서버를 외부에 열 수 없다면 DNS-01 검증을 검토한다. 이 방식은 DNS에 검증용 레코드를 넣는다. 다만 갱신까지 자동화하려면 DNS 제공 업체의 API 지원과 자격 증명 관리가 필요하다. 사이트가 한두 개라면 와일드카드 인증서를 고집하기보다 필요한 이름만 발급하는 편이 운영이 단순하다.
인증서와 개인키 경로를 웹서버 설정에 연결한 뒤에는 설정 검사부터 실행하고 서비스를 다시 읽힌다. 개인키는 공개 디렉터리나 공유 저장소에 두지 않는다. 로드밸런서에서 암호화를 끝내는 구조라면 방문자 쪽 인증서와 로드밸런서에서 원본 서버로 가는 연결을 각각 확인한다.
설치 직후에는 실제 접속으로 확인한다
설정이 저장됐다는 메시지만 믿지 말고 외부에서 접속해 본다. 대표 주소와 별칭 주소를 각각 열어 인증서에 표시된 이름, 만료일, 발급 대상이 맞는지 확인한다. 서버가 여러 대라면 각 서버가 같은 인증서를 내보내는지도 봐야 한다. 한 대에만 새 파일을 넣으면 접속할 때마다 정상 화면과 경고 화면이 번갈아 나타날 수 있다.
- 일반 접속이 암호화된 접속으로 이동하는지 확인한다.
- 로그인과 결제 화면을 포함해 이미지·스크립트가 보안 경고 없이 불러와지는지 확인한다.
- 프록시 뒤에서 무한 리디렉션이 생기지 않는지 확인한다.
- 방문자에게 보이는 인증서가 방금 적용한 인증서인지 확인한다.
화면 일부가 깨진다면 인증서 자체보다 페이지 안의 이미지나 스크립트 요청을 먼저 의심한다. 암호화된 페이지에서 오래된 비암호화 주소를 불러오는 혼합 콘텐츠 문제일 수 있다. 반대로 접속 자체가 실패한다면 443번 포트, 웹서버 수신 설정, 앞단 장비의 인증서 연결 순서로 확인하는 편이 빠르다.
자동 갱신은 한 번 직접 검증한다
자동 갱신 설정은 설치 당일에 시험한다. Certbot을 쓴다면 갱신 모의 실행으로 검증 경로가 살아 있는지 확인하고, 갱신 후 웹서버가 새 인증서를 읽도록 설정됐는지도 살핀다. 발급할 때 임시로 80번 포트를 열었다가 바로 닫으면 다음 갱신에서 실패할 수 있다. DNS 검증을 썼다면 레코드나 API 권한을 지우지 않았는지 확인한다.
만료 알림은 실제로 읽는 연락처로 받는 게 좋다. 관리형 인증서도 조건이 맞아야 갱신된다. 예를 들어 AWS Certificate Manager의 DNS 검증 인증서는 필요한 DNS 레코드가 유지되고 인증서가 대상 서비스에 연결돼 있어야 자동 갱신 조건을 충족한다. 백업에는 웹서버 설정과 복구 절차를 포함하되 개인키를 보관한다면 접근 권한을 제한해야 한다.
내가 운영할 때는 SSL설치를 완료한 날보다 그다음 갱신일을 더 신경 쓴다. 작은 사이트라도 접속 경로와 갱신 시험만 기록해 두면, 몇 달 뒤 인증서 경고가 뜰 때 원인을 훨씬 빨리 좁힐 수 있다.
