SECTIGO인증서 발급부터 서버 적용까지 하는 방법

얼마 전 서버를 이전한 뒤 사이트가 열리지 않는다는 연락을 받았다. 인증서는 새 서버에 올려뒀지만 개인키는 예전 서버에만 있었다. SECTIGO인증서를 구매하고도 이런 일은 생긴다. 발급보다 중요한 건 어떤 이름을 보호할지, 키를 어디서 만들지, 갱신할 때 누가 설치할지를 먼저 정하는 일이다.

구매 전에 필요한 인증서 범위부터 확인한다

사이트 한 개에 방문자가 많은 것과 인증서 종류는 별개다. 일반적인 웹사이트라면 도메인 소유권을 확인하는 DV 인증서로 암호화 연결을 구성할 수 있다. OV나 EV는 조직 확인 절차가 추가되는 상품이다. 트래픽이 많다는 이유만으로 OV나 EV가 필요한 것은 아니다. 반대로 조직 확인이 계약 조건이라면 DV 가격만 비교해서는 안 된다.

견적을 볼 때는 보호할 이름을 먼저 적는다. 대표 이름과 하위 이름이 둘 다 필요하면 신청 범위에 둘 다 들어가는지 확인해야 한다. 서버에서 자동으로 다른 이름으로 이동시키더라도, 이동 전 접속한 이름의 인증서 검사는 먼저 일어난다. 여러 이름을 한 장에 담을지, 각자 발급할지도 운영 방식에 따라 고르면 된다. 서버가 여러 대라면 설치 대상이 몇 대인지도 함께 세어야 한다.

와일드카드는 여러 하위 이름을 운영할 때 편할 수 있지만 무조건 저렴한 선택은 아니다. 한 장의 개인키를 여러 서버에 복사하면 갱신 작업은 단순해지는 대신 키가 노출됐을 때 영향을 받는 범위가 넓어진다. 서비스가 두세 개라면 인증서를 따로 발급하는 편이 관리하기 쉬운 경우도 많다.

CSR은 실제 설치할 서버의 키로 만든다

발급 신청에는 CSR이 들어간다. CSR은 인증서에 넣을 정보와 공개키를 담은 요청 파일이고, 짝이 되는 개인키는 서버에 남는다. 신청 화면에서 받은 인증서 파일만 보관해 두면 충분하다고 생각하기 쉬운데, 개인키를 잃으면 그 인증서를 새 서버에서 사용할 수 없다. 이때는 새 키와 CSR을 만들고 재발급 절차를 밟아야 한다.

호스팅 관리 화면에서 키와 CSR을 만들어 주는지, 직접 서버에서 생성해야 하는지부터 확인한다. 로드밸런서나 CDN에서 암호화 연결을 종료한다면 인증서를 설치할 위치도 웹서버가 아닐 수 있다. 개인키는 설치 권한이 있는 관리자만 접근하게 두고, 메신저나 공동 문서에 붙여 넣지 않는 편이 안전하다. 백업에는 키 파일의 위치, 접근 권한, 복구 담당자를 함께 기록해 둔다.

신청 이름과 CSR의 이름이 맞는지도 확인한다. 인증서에 포함될 이름을 누락한 채 발급받으면 나중에 서버 설정만 바꿔 해결할 수 없다. 특히 이전 작업 중 새 하위 서비스를 추가했다면 신청 전에 목록을 다시 보는 게 빠르다.

도메인 확인이 멈추면 접속 경로부터 본다

Sectigo의 도메인 확인에는 이메일, DNS 레코드, 파일을 이용하는 방식이 있다. 실제로 선택할 수 있는 방식은 상품과 신청 경로에 따라 확인해야 한다. DNS 방식이라면 발급 화면이 제시한 레코드 이름과 값을 그대로 넣고, 현재 권한 있는 DNS에 반영됐는지 본다. 관리 화면에 저장됐다는 표시만으로 확인이 끝난 것은 아니다.

파일 방식은 지정된 경로의 파일을 인증기관이 읽어야 한다. 이때 자주 막히는 곳은 강제 이동 규칙, CDN 캐시, 접근 제한, 서버별로 다른 문서 경로다. 앞단과 원본 서버가 서로 다른 파일을 내보내는 구성이라면 인증기관이 실제로 받는 응답을 기준으로 점검한다. 이메일 방식은 승인 메일을 받을 수 있는 주소와 담당자가 살아 있는지 먼저 확인한다.

DNS에 CAA 레코드를 설정해 발급 기관을 제한했다면 Sectigo 발급이 허용되는지도 살펴야 한다. 도메인 확인이 계속 실패할 때 CSR을 반복해서 만드는 것보다 DNS 권한, 레코드 값, 외부에서 보이는 응답을 차례로 확인하는 편이 시간을 덜 쓴다. Sectigo 안내에서도 발급 전 도메인 통제 확인을 필수 단계로 설명한다.

설치 후에는 인증서 파일보다 실제 응답을 검증한다

발급된 인증서와 중간 인증서를 서버가 요구하는 형식으로 설치하고 개인키를 연결한다. 설치 파일의 이름이 맞아 보여도 실제 서비스가 예전 인증서를 내보내는 경우가 있다. 가상 호스트 설정이 다른 파일을 가리키거나, 여러 서버 중 한 대만 교체됐거나, 설정을 다시 읽히지 않았을 때다.

• 브라우저에서 실제 접속 이름마다 인증서의 보호 대상과 만료일을 확인한다.
• 중간 인증서가 빠지지 않았는지, 인증서와 개인키가 서로 짝이 맞는지 확인한다.
• 로드밸런서와 원본 서버의 설치 위치를 구분하고, 서버가 여러 대면 각각 확인한다.
• 갱신 알림의 수신자와 설치 담당자, 갱신 후 확인 절차를 기록한다.

가격을 비교할 때도 구매 금액만 보면 판단이 흐려진다. 무료 인증서를 자동 발급하고 자동 갱신할 수 있는 환경이라면 유료 SECTIGO인증서가 꼭 필요하지 않을 수 있다. 반면 특정 인증기관, 조직 확인, 운영 지원이 요구되는 환경이라면 그 조건을 비용에 반영해야 한다. 어느 쪽이든 갱신을 놓치면 같은 장애가 난다. 나는 인증서를 고를 때 상품 이름보다 키 보관 위치와 갱신 담당자가 먼저 떠오른다.