SNI 사례 연구: 설정이 잘못된 국내 도메인 730곳

국내 기업 웹사이트 10,135곳을 점검한 결과, 730개 사이트가 *.cafe24.com, *.gabia.io 같은 도메인이나 동일 서버에 있는 다른 기업 명의로 발급된 인증서를 보여주고 있음을 확인했다.

공유 서버에서 이러한 현상이 발생하는 이유와 이것이 비즈니스에 악영향을 미치는 이유(방문자의 화면에 보이는 모습), 그리고 명령어 한 줄로 자사 사이트를 점검하는 방법을 정리했다.

방문자의 화면에 표시되는 내용

크롬(Chrome)은 연결이 비공개로 설정되어 있지 않습니다(NET::ERR_CERT_COMMON_NAME_INVALID)라는 전체 화면 경고를 띄워 방문자의 접근을 차단한다.

고급 옵션을 클릭하면 크롬은 불일치하는 대상의 이름을 보여준다. Chromium 소스 코드에 설명되어 있듯 "이 서버가 [자사 도메인]임을 증명하지 못했습니다. 서버의 보안 인증서가 [다른 도메인]에서 제공되었습니다."라는 문구가 표시된다.

파이어폭스(Firefox)는 SSL_ERROR_BAD_CERT_DOMAIN 오류 메시지와 함께 해당 인증서가 유효한 도메인 목록을 나열한다.

"이 사이트는 안전하지 않다"는 경고를 본 방문자는 큰 불안감을 느낀다. 방문자가 안심하고 자신의 정보를 입력하거나 제품을 구매할 가능성은 급격히 떨어진다.

엉뚱한 인증서가 표시되는 이유

공유 호스팅(Shared hosting) 환경에서는 단일 IP 주소에 여러 웹사이트가 함께 위치한다. TLS 핸드셰이크 과정에서 브라우저는 SNI(Server Name Indication)를 통해 접속하려는 대상 도메인을 지정하고, 서버는 이에 일치하는 인증서를 선택한다.

일치하는 인증서가 없을 때 RFC 6066 §3 규격은 서버가 "핸드셰이크를 중단하거나 […] 계속 진행할 수 있다"고 허용한다. 이번에 확인된 730대의 서버는 핸드셰이크를 '계속 진행'하도록 설정되어 있었다.

핸드셰이크를 계속 진행할 경우 Apache는 대체(Fallback) 방식을 사용한다. 즉 "일치하는 ServerName이나 ServerAlias가 없으면 목록의 첫 번째 vhost를 사용"한다. 마찬가지로 nginx 역시 별도 설정이 없다면 기본(default) 서버로 요청을 보내며, 이때 "첫 번째 서버가 기본 서버"가 된다.

그 결과, 서버가 인식하지 못하는 도메인을 요청한 방문자에게 해당 서버의 기본 사이트 인증서가 전송되는 것이다.

국내 도메인 조사 결과

2026년 9월 29일, Tranco 랭킹에 등재된 국내 도메인 10,135개(.co.kr 도메인 10,123개 포함)를 대상으로 분석을 진행했다.

HTTP 요청은 보내지 않은 채 SNI로 호스트네임만 전달하여 각 도메인 및 www. 서브도메인의 443번 포트로 TLS 핸드셰이크를 시도했다. 접속 시간이 초과된 경우에는 타임아웃 기준을 높여 2차 시도를 진행했다.

인증기관(CA)에서 발급한 인증서가 존재하지만, 해당 인증서에 포함된 이름 중 요청한 도메인을 커버하는 것이 없는 경우를 문제 도메인으로 분류했다.

• 730개 사이트가 이에 해당했다. 이는 전체 도메인의 7.2%, 인증서를 하나라도 반환한 8,151개 사이트 중 9.0%에 달하는 수치다.
• 730개 사이트 모두 브라우저 검증을 통과하지 못했으며, 이 중 21%는 인증서 유효기간마저 만료되어 있었다.
• 49%는 호스팅 플랫폼의 와일드카드 인증서를 노출했고, 51%는 동일 서버를 공유하는 다른 고객사의 인증서를 노출했다.

이번 조사는 표준 443번 포트만을 대상으로 수행했다. 과거 국내 호스팅 업체들이 유료 인증서를 대체 포트에 설치하던 관행이 있었으므로, 이들 사이트 중 일부는 443번 포트 외의 경로에 유효한 인증서를 유지하고 있을 수 있다.

와일드카드 인증서 발급 수 상위 호스팅 제공업체:

방문자에게 보이는 이름

호스팅 업체가 와일드카드 인증서를 반환할 경우 방문자는 방문할 의도가 없었던 호스팅 업체의 이름을 보게 된다.

반면 특정 사이트의 인증서가 반환될 경우 방문자는 서버를 함께 쓰는 무관한 타사의 이름을 보게 된다. 일례로 한 언론사의 인증서가 다른 20개 사이트에서 표시되는 사례가 확인되었다. 또 다른 사례에서는 2019년 8월에 만료된 웹 에이전시의 인증서가 여전히 12개 사이트에 표시되고 있었다.

자사 웹사이트 점검 방법

자사 웹사이트의 TLS 응답을 점검하려면 오픈소스 도구인 openssl을 활용할 수 있다. 아래 명령어에서 example.co.kr 부분을 점검할 도메인으로 변경하여 실행해 보자.

openssl s_client -connect example.co.kr:443 -servername example.co.kr </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

출력 결과에 해당 도메인이 포함되어 있다면 사이트에 문제가 없는 것이다. 그렇지 않다면 자세히 점검해 볼 필요가 있다.

도메인 문제 조치 방법:

• 호스팅 업체를 통해 전용 도메인 인증서를 발급받는다. NHN커머스의 고도몰 같은 이커머스 플랫폼은 도메인 설정 시 인증서를 자동으로 설치해 준다. 반면 카페24, 가비아, 닷홈, 블루웹 같은 공유 호스팅 서비스는 별도 신청과 비용 지불이 필요한 경우가 많다.
• 두 호스트네임을 모두 등록한다. 발급받는 인증서가 example.co.kr과 www.example.co.kr 두 주소를 모두 포함하는지 확인한다.
• 서버 단에서 처리되지 않은 호스트네임을 거부한다. 직접 서버를 운용하는 경우 nginx 1.19.4 이상 버전의 기본(default) 서버 블록에 ssl_reject_handshake를 설정하여 RFC 6066에서 정의한 핸드셰이크 '중단' 동작을 적용한다.

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

---

참고 자료

1. IETF — RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions, §3 Server Name Indication (2011년 1월)
2. Apache HTTP Server 2.4 — An In-Depth Discussion of Virtual Host Matching
3. nginx — How nginx processes a request
4. nginx — Module ngx_http_ssl_module: ssl_reject_handshake
5. Chromium Blog — Towards HTTPS by default (2023년 8월 16일)
6. Chromium — components/ssl_errors_strings.grdp
7. Google — HTTPS by default (2025년 10월 28일)
8. 카페24 — SSL 인증서 신청 FAQ
9. 닷홈 — SSL 가격
10. 뉴스핌 — NHN커머스 고도몰 무료 SSL 발표 (2026년 2월 6일)
11. Mozilla — certError.ftl