도메인이 늘어나기 시작하면 반드시 나오는 질문이다. “와일드카드 하나 사면 되는 거 아니에요?” 반은 맞고, 반은 와일드카드가 무엇을 못 덮는지 몰라서 나오는 말이다.

용어부터 정확히 하자. 요즘 인증서는 전부 SAN 인증서다. 브라우저가 Common Name 을 안 본 지 오래라(크롬 58, 2017년부터), 도메인은 모두 subjectAltName 확장에 들어간다. 실제 선택지는 이렇다:

• 단일 도메인 — SAN 에 example.com (+www.example.com)
• 멀티 도메인(SAN 여러 개) — SAN 에 서로 다른 도메인 나열. UCC 라고도 부른다
• 와일드카드 — SAN 에 *.example.com
• 혼합 — SAN 에 *.example.com 과 example.com 을 같이 (가장 흔한 실전 구성)

와일드카드가 덮는 범위 — 착각 세 가지

*.example.com 이 덮는 것: www, api, blog … 딱 한 단계.

착각 1 — apex 도 덮겠지. 안 덮는다. *.example.com 은 example.com 자체를 포함하지 않는다. 그래서 실전 와일드카드 인증서는 SAN 에 *.example.com 과 example.com 두 개를 넣는다. 발급 시 이걸 빼먹으면 루트 도메인 접속에서 ERR_CERT_COMMON_NAME_INVALID 가 난다.

착각 2 — 하위 단계도 덮겠지. 안 덮는다. a.b.example.com 은 *.example.com 범위 밖이다. 와일드카드는 정확히 한 레이블만 치환한다. *.b.example.com 을 따로 받아야 한다. 내부 환경에서 dev.api.example.com 같은 2단계 구조를 쓰기 시작하면 그때부터 어긋난다.

착각 3 — 다른 도메인도 어떻게 안 되나. example.io 는 당연히 안 된다. 브랜드 도메인이 여러 개면 멀티 도메인 SAN 이거나 인증서 분리다.

진짜 트레이드오프는 개인키다

기술 스펙보다 중요한 것: 와일드카드 인증서 하나 = 개인키 하나를 여러 서버가 공유하게 된다는 사실이다.

*.example.com 을 웹서버 5대, 로드밸런서, 메일 서버, 사내 도구에 배포했다고 하자. 그중 가장 허술한 서버 한 대가 뚫리면 개인키가 유출되고, 그 키로 example.com 의 모든 서브도메인을 사칭할 수 있다. 폐기하면? 그 인증서를 쓰던 모든 서버가 동시에 교체 대상이 된다. 편의의 대가가 폭발 반경이다.

반면 서비스별 단일/SAN 인증서는 키가 분리돼 있어 사고가 그 서비스에 갇힌다. 대신 관리할 인증서 수가 늘어난다 — 만료일도 각각이고, 갱신 실패 지점도 각각이다.

기준	와일드카드	도메인별 분리
신규 서브도메인	즉시 사용 가능	발급 필요
개인키 유출 시	전 서브도메인 영향	해당 서비스만
관리 대상 수	적음	많음 (자동화 필수)
발급 검증	DNS-01 강제	HTTP-01 가능
인증서 투명성(CT) 노출	서브도메인 이름 감춤	개별 이름 전부 공개

마지막 줄은 의외로 실무적이다. CT 로그는 공개라 internal-admin.example.com 같은 이름으로 개별 인증서를 받으면 그 존재가 전 세계에 공개된다 (진단 툴이 만료일을 찾는 원리이기도 하다). 내부 서브도메인 이름을 드러내기 싫으면 와일드카드가 답이다.

발급 방식 제약 — DNS-01

와일드카드는 Let’s Encrypt 기준 DNS-01 챌린지로만 발급된다. TXT 레코드를 자동으로 넣을 수 있어야 하므로:

• DNS 제공자 API 가 있어야 하고, 그 토큰을 갱신 시스템이 들고 있어야 한다
• 그 토큰이 만료되면 갱신이 조용히 죽는다 — 와일드카드 운영의 단골 장애
• DNS 제공자가 API 를 제공하지 않으면 사실상 운영 불가

HTTP-01 로 굴러가던 갱신 체계에 와일드카드를 섞으면 갱신 경로가 두 갈래가 된다. 장애 지점이 늘어난다는 뜻이다.

결정 기준

와일드카드가 맞는 경우

• 서브도메인이 동적으로 생긴다 (테넌트별 고객명.example.com 같은 SaaS 구조)
• 서브도메인 이름을 CT 에 노출하기 싫다
• 종단이 한 곳이다 — 로드밸런서·CDN 에서 TLS 를 끝내고 키가 그 한 곳에만 있다

도메인별 분리가 맞는 경우

• 서버들이 조직·보안 등급이 다른 곳에 흩어져 있다 (키 공유 반경이 곧 리스크)
• 자동 갱신이 이미 서비스별로 자리 잡았다
• 감사·규제 상 키 분리를 요구받는다

멀티 도메인 SAN 이 맞는 경우

• 서로 다른 도메인 소수(2~10개)를 같은 서버에서 서빙한다
• 단, 도메인 하나 추가·제거할 때마다 재발급이다. 구성이 자주 바뀌면 괴롭다

에이전시처럼 고객사 도메인 수십 개를 다루는 경우는 셋 다 아니다 — 고객사 도메인은 소유자가 달라 한 인증서에 묶을 수 없다. 도메인별 발급 + 자동 갱신 + 만료 감시 체계의 조합이 유일한 답이고, 관리 대상이 많아질수록 감시가 본체가 된다. 만료일 확인을 손으로 하고 있다면 1편의 스크립트부터, 그것도 번거로우면 진단 툴에 이메일을 남겨두면 된다.