와일드카드 인증서와 SAN 인증서, 언제 무엇을 쓰나
이 글의 순서 4개 절
도메인이 늘기 시작하면 “와일드카드 하나 사면 되지 않나” 하는 얘기가 나온다. 반은 맞다. 나머지 반은 와일드카드가 무엇을 못 덮는지 몰라서 하는 말이다.
용어가 헷갈리기 쉬운데, 요즘 인증서는 전부 SAN 인증서다. 브라우저가 Common Name을 안 본 지 오래라(크롬 58, 2017년부터) 도메인은 모두 subjectAltName 확장에 들어간다. 실제로 고르는 건 SAN에 무엇을 넣느냐다.
- 단일 도메인: SAN에
example.com(+www.example.com) - 멀티 도메인(SAN 여러 개): SAN에 서로 다른 도메인을 나열한다. UCC라고도 부른다
- 와일드카드: SAN에
*.example.com - 혼합: SAN에
*.example.com과example.com을 같이 넣는다. 실제로는 이 구성이 가장 흔하다
와일드카드가 덮는 범위
*.example.com이 덮는 건 www, api, blog처럼 바로 아래 한 단계뿐이다.
apex는 안 덮는다. *.example.com에 example.com 자체는 들어가지 않는다. 그래서 와일드카드
인증서를 받을 때는 SAN에 *.example.com과 example.com을 같이 넣는다. 이걸 빼먹으면 루트
도메인으로 들어오는 접속에서 ERR_CERT_COMMON_NAME_INVALID가 난다.
두 단계 아래도 안 덮는다. 와일드카드는 레이블 하나만 대신하므로 a.b.example.com은
*.example.com 범위 밖이다. *.b.example.com을 따로 받아야 한다. 내부에서
dev.api.example.com 같은 2단계 구조를 쓰기 시작하면 여기서 어긋난다.
다른 도메인은 당연히 안 된다. 브랜드 도메인이 example.io처럼 여러 개라면 멀티 도메인 SAN으로
묶거나 인증서를 나눈다.
개인키를 나눠 쓴다는 것
범위보다 중요한 건 키다. 와일드카드 인증서 하나를 여러 서버에 깔면 개인키 하나를 그 서버들이 같이 쓰게 된다.
*.example.com을 웹서버 5대, 로드밸런서, 메일 서버, 사내 도구에 배포했다고 하자. 그중 가장
허술한 한 대만 뚫려도 개인키가 새고, 그 키로 example.com의 모든 서브도메인을 사칭할 수 있다.
인증서를 폐기하면 그걸 쓰던 서버를 전부 한꺼번에 바꿔야 한다.
서비스마다 인증서를 따로 받으면 키도 따로라서 사고가 그 서비스 안에서 끝난다. 대신 관리할 인증서가 늘어난다. 만료일도, 갱신이 실패할 수 있는 곳도 인증서마다 따로다.
| 기준 | 와일드카드 | 도메인별 분리 |
|---|---|---|
| 신규 서브도메인 | 즉시 사용 가능 | 발급 필요 |
| 개인키 유출 시 | 전 서브도메인 영향 | 해당 서비스만 |
| 관리 대상 수 | 적음 | 많음 (자동화 필수) |
| 발급 검증 | DNS-01 강제 | HTTP-01 가능 |
| 인증서 투명성(CT) 노출 | 서브도메인 이름 감춤 | 개별 이름 전부 공개 |
CT 줄은 의외로 실무에서 걸린다. CT 로그는 누구나 볼 수 있어서 internal-admin.example.com 같은
이름으로 인증서를 따로 받으면 그 이름이 전 세계에 공개된다. 진단 툴도 이 로그에서
만료일을 찾는다. 내부 서브도메인 이름을 드러내기 싫으면 와일드카드를 쓴다.
발급은 DNS-01로만
Let’s Encrypt에서 와일드카드는 DNS-01 챌린지로만 발급된다. TXT 레코드를 자동으로 넣을 수 있어야 하니 DNS 제공자가 API를 열어 줘야 하고, 갱신 시스템이 그 API 토큰을 들고 있어야 한다. API가 없는 DNS 제공자라면 사실상 운영이 안 된다. 토큰이 만료되면 갱신이 조용히 죽는다. 와일드카드를 운영하는 곳의 단골 장애다.
HTTP-01로 굴러가던 갱신에 와일드카드를 섞으면 갱신 경로가 두 갈래가 된다. 그만큼 장애가 날 곳이 늘어난다.
고르는 기준
와일드카드
- 서브도메인이 동적으로 생긴다. 테넌트마다
고객명.example.com을 주는 SaaS가 그렇다 - 서브도메인 이름을 CT에 드러내기 싫다
- TLS를 한 곳에서 끝낸다. 로드밸런서나 CDN에서 종료하고 키도 거기에만 있다
도메인별 분리
- 서버들이 조직이나 보안 등급이 다른 곳에 흩어져 있다. 키를 같이 쓰는 범위가 곧 위험 범위다
- 서비스별 자동 갱신이 이미 자리 잡았다
- 감사나 규제에서 키 분리를 요구한다
멀티 도메인 SAN
- 서로 다른 도메인 몇 개(2~10개)를 같은 서버에서 서빙한다
- 단, 도메인을 하나 넣거나 뺄 때마다 재발급이다. 구성이 자주 바뀌면 괴롭다
고객사 도메인이 수십 개라면
에이전시처럼 고객사 도메인을 수십 개 맡는 곳은 셋 다 아니다. 고객사 도메인도 도메인마다 확인을 통과하면 한 인증서에 묶을 수는 있다. 하지만 한 고객사의 해지나 도메인 변경이 다른 고객사 인증서까지 재발급하게 만들고, 각 고객사 도메인이 한 인증서에 모두 드러난다. 그래서 도메인별로 발급하고, 자동 갱신을 걸고, 만료를 감시하는 수밖에 없다. 관리할 도메인이 많을수록 일의 대부분은 감시가 된다.
만료일을 아직 손으로 확인하고 있다면 SSL 인증서 만료일 확인하는 법의 스크립트부터 돌린다. 그것도 번거로우면 진단 툴에 이메일을 남겨 두면 된다.