174. SAN (Subject Alternative Name)

⚠️ 이 문서는 하나의 신분증(인증서)에는 오직 하나의 도메인 이름(CN)만 적을 수 있었던 낡은 시대의 족쇄를 끊어내고, "나의 본캐는 네이버지만 부캐로 메일, 블로그, 지도 서버의 이름도 이 신분증 하나로 다 퉁쳐주시오!"라고 브라우저에게 외치는 다중 도메인 신분 증명 꼬리표, SAN을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: SAN(주체 대체 이름)은 X.509 v3 인증서의 확장 필드(Extension) 중 하나로, 하나의 인증서 안에 도메인 이름, IP 주소, 이메일 주소 등 수십 개의 다양한 '별명(Alternative Names)'들을 콤마로 엮어 추가로 밀어 넣을 수 있는 규격이다.

가치: 회사가 서브 도메인을 10개 파면 인증서를 10장 사서 10개의 서버에 일일이 세팅해야 하는 돈 낭비와 끔찍한 관리 지옥을 없애버린다. SAN 인증서(멀티 도메인 인증서) 딱 1장만 사면 하나의 웹 서버(로드 밸런서)에서 10개의 주소로 들어오는 손님을 모두 파란 자물쇠로 맞이할 수 있다.

융합: 현대 크롬(Chrome) 브라우저는 과거의 메인 이름표인 CN(Common Name)을 아예 무시(폐기)하고, 무조건 이 SAN 필드에 적힌 리스트만 보고 접속한 주소와 일치하는지 검사하는 보안 로직으로 완전히 융합/진화하여, 사실상 SAN이 인터넷 접속 주소 검증의 유일한 권력자가 되었다.

Ⅰ. 개요 및 '하나의 이름'이 만든 지옥 (Context & Necessity)

과거(X.509 v1, v2 시절)의 인증서에는 이름을 적는 칸이 딱 하나, **CN(Common Name)**밖에 없었다.

인증서의 CN = www.naver.com

그런데 회사가 커지면서 서브 서비스들이 폭발했다. mail.naver.com, blog.naver.com, pay.naver.com...

과거의 절망: 브라우저가 mail.naver.com 에 들어갔는데 서버가 내민 인증서의 CN이 www.naver.com 이면 브라우저는 "어? 내가 접속한 주소랑 신분증에 적힌 이름이 다르잖아! 이거 해커의 피싱 사이트다!" 하고 빨간 경고창(Name Mismatch Error)을 쾅 띄우고 접속을 찢어버린다.
관리자의 비명: 네이버는 도메인이 50개니까 CA에게 돈을 50번 내고 인증서를 50장 따로 사야 한다. 더 끔찍한 건 서버 설정 파일에 50개의 인증서 파일 경로를 일일이 다 달아줘야 한다는 것이다. (설정하다 날을 샌다).

"제발 인증서 하나에 뒷면 메모장 같은 거 덧대서, '이놈의 부캐(별명) 리스트 50개'를 한 방에 다 적어 넣게 해달라!" 이 현장의 절규를 반영해 탄생한 X.509 v3의 위대한 확장팩이 바로 **SAN (Subject Alternative Name)**이다.

📢 섹션 요약 비유: 옛날엔 "운전면허증, 학생증, 도서관 출입증"을 각각 지갑에 3장 따로 들고 다녀야 했습니다. SAN은 이 3장의 신분증을 하나로 합친 '만능 프리패스 카드'입니다. 카드 앞면엔 "본캐: 철수"라고 적혀있고, 뒷면(SAN)엔 "부캐: 1번 고등학교 학생, 2번 도서관 VIP, 3번 운전면허 1종"이라고 다 적혀 있어서, 어딜 가든 이 카드 한 장만 쓱 내밀면 통과되는 마법입니다.

Ⅱ. SAN의 위력과 실무 구조 (Multi-Domain Cert)

SAN을 넣는 것은 서버 관리자가 처음 청원서(CSR)를 만들 때 텍스트 한 줄만 추가하면 된다.

1. 다채로운 별명 지원 (DNS, IP, Email)

SAN은 도메인 주소만 욱여넣는 곳이 아니다.

DNS: www.naver.com (기본 도메인)
DNS: mail.naver.com (서브 도메인 1)
DNS: blog.naver.com (서브 도메인 2)
심지어 IP: 192.168.1.100 (IP 주소로 직접 접속할 때도 에러 안 나게 막아줌!)
이처럼 최대 100개 이상의 주소를 한 인증서 뱃속에 줄줄이 비엔나처럼 엮어 넣을 수 있다. (이걸 통상적으로 UCC(Unified Communications Certificate) 또는 멀티 도메인 인증서라고 부른다.)

2. 크롬(Chrome)의 사형 선고: "CN은 이제 죽었다"

과거 브라우저들은 1차로 CN을 보고 다르면 2차로 SAN을 보는 관대한 녀석들이었다.
하지만 보안상 모호함이 생기고 해커가 파고들 틈이 생기자, 시장의 폭군 구글 크롬(버전 58부터)이 선언했다. "앞으로 접속 주소 검사할 때 구닥다리 CN 칸은 아예 쳐다보지도 않는다. 무조건 확장 꼬리표인 'SAN(Subject Alternative Name)' 리스트에 주소가 적혀있어야만 통과시켜 주겠다!"
이 패치 한 방에 전 세계 수십만 개의 사내 시스템이 "이름 불일치 에러"를 뿜으며 터져나갔다. (사내 엔지니어들이 CSR 텍스트 파일 깎을 때 낡은 매뉴얼만 보고 SAN 옵션을 빼먹고 만들었기 때문).

┌───────────────────────────────────────────────────────────────────────────────┐
│           단일 인증서(CN) vs 다중 도메인 인증서(SAN)의 접속 에러 방어 시각화  │
├───────────────────────────────────────────────────────────────────────────────┤
│                                                                               │
│ 💣 [ 옛날 낡은 인증서 (CN만 있음) ]                                           │
│   인증서 내용: [ 주소(CN) = www.회사.com ]                                    │
│                                                                               │
│   - 브라우저가 www.회사.com 접속 ──▶ 통과! 🟢                                 │
│   - 브라우저가 pay.회사.com 접속 ──▶ 에러! 🔴 (주소 불일치 경고창 작렬!)      │
│                                                                               │
│ ────────────────────────────────────────────────────────────                  │
│                                                                               │
│ 🚀 [ 현대의 완벽한 SAN 인증서 (멀티 도메인) ]                                 │
│   인증서 내용: [ 주소(CN) = www.회사.com (크롬: 무시함) ]                     │
│              [ 별명(SAN) = DNS:www.회사.com,                                  │
│                           DNS:pay.회사.com,                                   │
│                           DNS:mail.회사.com, IP:10.0.0.1 ]                    │
│                                                                               │
│   - 브라우저가 www.회사.com 접속 ──▶ 통과! 🟢                                 │
│   - 브라우저가 pay.회사.com 접속 ──▶ 통과! 🟢 (어? SAN 리스트에 있네!)        │
│   - 브라우저가 10.0.0.1 (IP) 로 접속 ──▶ 통과! 🟢 (IP도 등록되어 있네!)       │
└───────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드 환경(AWS ALB, Nginx 등)에서 로드밸런서(L7) 하나 띄워놓고 뒷단에 10개의 서비스(쇼핑몰, 블로그, 게시판)를 라우팅할 때, এই SAN 인증서 딱 한 장만 프론트 게이트웨이에 끼워두면 모든 것이 끝난다. 인프라 운영의 복잡성(Complexity)을 획기적으로 깎아내린 '인프라 엔지니어들의 영원한 구원자'다.

📢 섹션 요약 비유: 주민등록증(CN)에는 집 주소가 '본가' 하나만 적혀 있어서, '기숙사'로 택배를 시키면 경비 아저씨가 "주소 불일치!"라며 물건을 버립니다. SAN은 주민등록증 뒷면에 "내 별장 주소, 기숙사 주소, 할머니 댁 주소 전부 다 내 집 맞음!"이라고 10개를 적어놓은 확장판입니다. 택배 아저씨가 뒷면의 리스트를 보고 의심 없이 물건을 다 배달해 줍니다.

Ⅲ. SAN vs 와일드카드 (*.naver.com)의 차이점

"야, 그냥 *.naver.com (와일드카드) 인증서 하나 뽑으면 다 되는 거 아냐? 귀찮게 SAN에 하나하나 왜 적어?" 얼핏 보면 와일드카드 인증서[175번 문서]가 완벽해 보이지만, 실무에서는 이 둘을 엄격하게 구분해서 쓴다.

구분	SAN 인증서 (멀티 도메인)	와일드카드 인증서 (*.domain.com)
원리	이름 10개를 콤마로 콕 집어 명시함. (`a.com`, `b.com`, `c.net`)	`*.naver.com` 하나로 미래의 모든 서브 도메인 퉁침.
타 도메인 통합	가능! (네이버, 라인, 구글 등 전혀 다른 도메인도 1장에 묶을 수 있음)	불가능! (오직 `.naver.com` 으로 끝나는 식구들만 가능)
보안성(해킹 파급력)	뚫려도 그 10개만 피해 봄.	하나 뚫리면 해커가 가짜 서브 도메인(피싱) 무한대로 생성 가능 (핵폭탄급 위험)

즉, 회사가 10개 브랜드의 서로 다른 도메인(abc.com, xyz.net)을 운영하는데 서버 1대로 처리하고 싶다면 와일드카드는 쓸 수 없고, 오직 이 SAN 인증서만이 유일한 해결책이 된다.

Ⅳ. 결론

"이름 하나에 묶여있던 식별의 한계를 부수고, 클라우드 라우팅의 유연함을 열어젖히다." SAN(Subject Alternative Name)은 단순한 인증서의 꼬리표 확장을 넘어, 1대의 물리적 서버(IP)가 수십 개의 가상 호스트 도메인을 떠받치는 현대 HTTP/1.1 및 클라우드 시대의 '이름표 다중화' 수요를 완벽하게 충족시킨 수학적 포용력이다. 브라우저는 더 이상 고지식하게 CN 하나만 쳐다보며 에러를 뿜지 않는다. 인증서의 뒷면에 빽빽하게 적힌 이 SAN의 별명 리스트들은, 오늘도 수십만 개의 API 엔드포인트와 마이크로서비스들이 하나의 철벽 우산(인증서) 아래에서 안전하게 파란 불을 켤 수 있도록 지탱해 주는 마법의 호적 등본이다.

📌 관련 개념 맵

소속 인프라: X.509 v3 Certificate Extensions (확장 필드)
대체되어 버려진 과거 기술: CN (Common Name - 이제 크롬 등 최신 브라우저에서는 호스트 검증 시 무시됨)
유사/보완 개념: Wildcard Certificate (와일드카드 인증서, *.example.com), SNI (Server Name Indication - TLS 확장)
발급 전 준비물: CSR (PKCS#10) 생성 시 -addext 나 [v3_req] 설정에 subjectAltName 속성을 반드시 추가해서 CA에 던져야 함.

👶 어린이를 위한 3줄 비유 설명

옛날 학생증 앞면(CN)에는 "철수"라는 진짜 이름 딱 한 개만 적을 수 있어서, 친구들이 저를 "별명 1: 똥개", "별명 2: 달리기왕"으로 부를 때 제가 맞는지 증명할 수가 없었어요.
그래서 학생증 뒷면(SAN)에다가 아예 제 모든 별명 10개를 쫙 적어놓고 교장 선생님 도장을 받았죠!
이제 인터넷 세상 어디를 가서 별명으로 접속해도, 브라우저가 학생증 뒷면(SAN 리스트)을 확인하고 "오! 다 같은 철수 맞네!" 하면서 에러 없이 한 번에 싹 통과시켜 준답니다!