openssl.cnf 예시와 SAN과 CN 이란?

[ req ]
default_bits = 2048
prompt       = no
default_md   = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C  = KR
ST = Seoul
O  = Mofl
CN = etcd-node

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
IP.1  = ??
IP.2  = ??
IP.3  = ??

 

SAN(Subject Alternative Name)는 X.509 인증서의 확장 필드 중 하나로, 인증서가 적용될 도메인 이름이나 IP 주소 등 식별자를 추가적으로 명시하기 위해 사용됩니다. 흔히 HTTPS 인증서에서 Common Name(CN) 외에 추가 도메인/IP를 포함해 브라우저 및 클라이언트가 인증서 검증 시 참조하도록 하는 용도로 많이 사용됩니다.

 

왜 SAN이 중요한가?

과거에는 인증서의 Common Name(CN) 필드를 서버 도메인으로 삼아, 클라이언트(브라우저 등)는 해당 도메인과 CN이 일치하는지를 주로 확인했습니다. 하지만 현재는 표준/권장사항으로 SAN 필드(Subject Alternative Name)에 명시된 값을 우선적으로 검증하도록 되어 있습니다.

• Browser / TLS 클라이언트 쪽에서:
  1. SAN 필드가 존재하면, SAN 필드 내 DNS, IP, 또는 다른 식별자(URI, email 등)를 확인
  2. SAN 필드에 접속하려는 호스트(DNS/IP)가 없으면 인증서 검증이 실패
  3. SAN이 없고 CN만 있을 때의 처리도 오래된 호환성으로 가능하긴 하지만, 최신 툴이나 브라우저는 SAN을 필수로 요구하거나 CN만 있는 인증서에 경고를 표시하기도 함

따라서 현재는 인증서를 발급할 때, CN 대신(또는 함께) 반드시 SAN 필드에 실제 사용될 도메인/IP를 모두 포함시키는 것이 일반적입니다.

 

SAN이 없는 경우 발생하는 문제

• “certificate is valid for XXX, not YYY” 라는 TLS 검증 에러
  예: x509: certificate is valid for example.com, not 192.168.0.10
  → 즉, 인증서에 DNS:example.com만 들어 있는데, 실제로는 192.168.0.10으로 접속하면 불일치
• 크롬/파이어폭스 경고: 일부 최신 브라우저나 클라이언트는 SAN이 없는 X.509 인증서를 불완전하다고 판단해 경고나 실패 처리하기도 합니다.

운영 환경에서의 모범 사례

1. SAN 필수: 운영 환경에선 모든 인증서에 SAN을 명시(도메인/IP 기반 접근).
2. 여러 도메인: 와일드카드(*.example.com)를 쓰거나, 여러 DNS를 나열해 하나의 인증서로 여러 호스트를 지원.
3. IP로 직접 접근하는 경우**: IP:x.x.x.x를 SAN에 포함(특히 사설 IP).
4. 만료/갱신 자동화: Let’s Encrypt 등 ACME 프로토콜 사용 시, 자동으로 SAN 지정과 갱신을 처리하기도 함.

 

 

Common Name은 X.509 인증서의 주체(Subject) 정보를 나타내는 필드 중 하나이다.

과거에는 도메인 이름을 CN에 기입하고, 브라우저나 클라이언트는 접속하려는 호스트와 인증서 CN 필드가 일치하는지 확인하여 인증서를 검증했다.

 

하지만 현재의 TLS 표준 및 구현에서는 SAN 필드를 우선적으로 확인하도록 검증하고 있다.

즉, CN에 도메인이 있더라도, SAN이 존재하면 CN 대신 SAN 필드를 사용하여 호스트와 인증서를 검증한다.

 

CN과 SAN의 관계

• CN: 인증서 주체 “이름” (과거: 호스트 이름으로 많이 쓰였음)
• SAN(Subject Alternative Name): 최신 표준에서 도메인, IP 등 실제로 인증서가 유효한 식별자를 기재.

만약 SAN 필드가 존재하면, 대부분의 TLS 클라이언트(브라우저)에서는 CN을 무시하고, 오직 SAN만 확인합니다.
SAN 필드가 전혀 없다면(매우 구형 방식), CN을 도메인 검증용으로 보기도 하지만, 최신 브라우저에서는 경고나 호환성 문제가 생길 수 있습니다.

 

운영 환경에서 어떻게 쓰나?

1. 권장 방식
   • SAN에 실제 서비스할 도메인(또는 IP)을 모두 넣기.
   • CN은 (필요하다면) 대표 이름으로 넣되, 실질적인 검증에는 SAN을 사용.
2. 와일드카드 인증서
   • CN에 *.example.com을 넣을 수 있지만, 사실상 SAN에 DNS:*.example.com을 적는 식으로 발급됩니다.
3. 여러 개의 도메인
   • CN에는 대표 도메인을 하나 넣거나, 회사명 등으로 활용
   • 나머지 도메인/서브도메인은 모두 SAN 목록에 기재.