관리형 인증서, 검증 방식과 적용 범위

적용 가능한 서비스 범위를 먼저 확인합니다

관리형 인증서의 장점은 갱신을 신경 쓰지 않는 것이지만, 쓸 수 있는 자리가 정해져 있습니다. 전송 서비스, 로드밸런서, 관리형 웹 플랫폼처럼 지정된 서비스에 붙일 수 있고, 직접 운영하는 서버에 파일로 내려받아 쓰는 용도로는 쓸 수 없는 경우가 있습니다. 그래서 1단계는 인증서를 붙일 지점을 모두 적는 일입니다. 2단계는 각 지점이 관리형 인증서를 지원하는지 확인하는 일입니다. 3단계는 지원하지 않는 지점만 다른 방법으로 처리하는 일입니다. 이 순서를 지키지 않고 발급부터 하면 붙일 수 없는 인증서를 만들게 됩니다.

DNS 검증을 쓰면 갱신이 자동으로 됩니다

검증 방식 선택이 자동 갱신 여부를 결정합니다. DNS 기록으로 검증하고 그 기록을 그대로 남겨 두면, 갱신 시점에 같은 방식으로 다시 검증되어 사람이 개입하지 않습니다. 반대로 메일 확인 방식을 쓰면 갱신마다 사람이 메일을 눌러야 하고, 담당자가 바뀌면 갱신이 멈춥니다. 그래서 DNS 검증을 기본으로 삼고, 검증 기록을 지우지 않는다는 주의 사항을 문서에 적습니다. 또 인증서를 요청한 리전과 사용할 서비스의 리전이 맞아야 하는 경우가 있으므로, 발급 전에 그 조건을 확인합니다. 리전이 다르면 목록에 보이지 않아 원인을 찾기 어렵습니다.

수동 관리 비용을 금액으로 환산합니다

학습용 가정으로 계산합니다. 가정값은 직접 관리하는 인증서가 8개이고 각각 연 4회 갱신하며 회당 20분이 든다고 두겠습니다. 연간 작업 시간은 8 곱하기 4 곱하기 20분으로 640분입니다. 내부 시간 비용을 시간당 30,000원으로 가정하면 320,000원입니다. 이것이 중간 계산값입니다. 최종 판단에는 누락 위험을 더합니다. 8개를 사람이 추적하면 하나를 놓칠 확률이 생기고, 만료 1회의 중단 손실은 위 금액을 넘길 수 있습니다. 관리형으로 옮기면 이 항목이 0에 가까워지지만, 적용할 수 없는 지점이 남으면 그 수만큼 비용이 남습니다.

내려받을 수 없는 제약이 남습니다

결론을 뒤집는 조건은 개인 열쇠의 반출입니다. 관리형 인증서는 개인 열쇠를 내려받을 수 없게 설계된 경우가 많습니다. 그러면 직접 운영하는 웹서버나 외부 장비에 그 인증서를 설치할 수 없습니다. 이 제약이 있는 지점은 처음부터 다른 방법을 씁니다. 두 번째 조건은 도메인 소유 확인 권한입니다. DNS를 다른 조직이 관리하면 검증 기록을 추가해 달라고 요청해야 하고, 그 요청이 늦으면 발급도 늦습니다. 그래서 적용 계획표에는 지점별로 지원 여부, 열쇠 반출 필요 여부, DNS 관리 주체 세 열을 적고 세 조건을 모두 만족하는 지점만 관리형으로 옮깁니다.

웹호스팅 실행 전 점검표

• 인증서를 붙일 지점을 모두 적고 지원 여부를 확인했다
• DNS 검증을 쓰고 검증 기록을 남겨 두었다
• 발급 리전과 사용 서비스의 리전 조건을 확인했다
• 열쇠 반출이 필요한 지점을 따로 분류했다