SNI와 Host의 차이: HTTPS 인증서 오류와 잘못 열린 사이트를 구분하는 법

도메인으로는 정상인데 IP 주소로 접속하면 인증서 오류가 나거나, 인증서는 통과했는데 기대와 다른 페이지가 열릴 수 있습니다. SNI와 Host를 구분하지 않으면 두 결과를 모두 도메인 설정 문제라고 묶기 쉽죠. 먼저 어떤 이름으로 TLS 연결을 시작했고, 어떤 호스트를 HTTP 요청에 담았는지 나누어 보세요.

SNI와 HTTP Host는 언제 전달되나요?

SNI는 TLS 연결을 시작하는 ClientHello에, Host는 이후 HTTP 요청에 담기는 이름입니다.

RFC 6066의 SNI 정의에 따르면 클라이언트는 ClientHello에 server_name 확장을 넣을 수 있습니다. 서버는 이 정보를 적절한 인증서 선택에 사용할 수 있습니다. 이름이 같은 값으로 보이더라도 HTTP 요청보다 앞선 단계에 쓰인다는 점이 핵심이죠.

Host는 HTTP 서버에 요청 대상 호스트를 전달하죠. 여기서는 Host를 직접 비교할 수 있도록 HTTP/1.1로 범위를 고정합니다. TLS 이름을 확인하는 작업과 HTTP 호스트를 확인하는 작업을 같은 칸에 적지 않는 편이 좋아요.

인증서 선택과 사이트 선택은 어떻게 다른가요?

인증서 선택은 TLS 단계의 문제이고, 사이트 선택은 HTTP 요청 처리 단계와 나누어 확인합니다.

NGINX의 가상 서버 선택 설명은 기본 서버 문맥에서 연결을 시작한 뒤, TLS 핸드셰이크의 SNI와 요청 줄, Host 처리 단계에서 서버 구성이 선택될 수 있다고 설명합니다. 이는 NGINX 구현의 설명이며 모든 웹 서버에 같은 설정 순서를 적용한다는 뜻은 아닙니다.

따라서 제시된 인증서와 반환된 페이지는 별도 관찰 항목이죠. 인증서 이름이 기대와 다르다는 결과와, HTTP 응답이 다른 사이트의 내용이라는 결과를 구분해야 하죠. 인증서가 정상이라고 페이지의 라우팅까지 정상으로 결론 내릴 수는 없습니다.

기존 CDN 도입할 때 꼭 알아야 할 SSL 인증서 설정 가이드는 인증서 적용과 연결 구간을 다룹니다. 이 글은 설치·갱신 절차를 반복하지 않고, 시험 요청에 어떤 이름을 넣었는지에 집중하죠.

IP로 접속하고 Host만 바꾸면 왜 진단이 달라지나요?

curl은 URL에서 SNI 이름을 가져오므로 Host만 바꾼 HTTPS 요청은 도메인 접속과 다릅니다.

curl의 이름 해석 설명은 HTTPS에서 Host 헤더만으로는 충분하지 않으며, 전송할 SNI 이름은 URL에서 가져온다고 설명합니다. URL에 IP를 적은 뒤 Host를 도메인으로 바꿔도, 그 도메인을 SNI로 보낸 요청으로 취급할 수는 없죠.

두 입력의 차이는 아래 명령으로 살펴볼 수 있죠. example.com과 192.168.0.1은 예시 값이며 실제 서비스나 시험 결과가 아닙니다. 직접 접속이 허용된 테스트 환경에서 본인 도메인과 서버 IP로 바꿔 읽으면 됩니다.

curl --http1.1 --noproxy "*" -H "Host: example.com" https://192.168.0.1/

이 명령은 HTTP Host를 example.com으로 지정하지만 URL은 여전히 IP 주소죠. 인증서 오류로 끝났다면 의도한 사이트의 HTTP 응답까지 확인한 시험으로 적지 않습니다. Host를 바꿨다는 사실이 TLS 단계의 확인을 대신하지는 않죠.

curl로 연결 IP와 도메인을 어떻게 나누어 확인하나요?

curl의 --resolve를 쓰면 URL의 도메인은 유지한 채 해당 이름과 포트의 연결 IP를 지정합니다.

curl 공식 문서는 --resolve가 지정한 이름의 주소를 curl의 DNS 캐시에 넣는 방식이라고 설명합니다. HTTPS에서는 URL의 이름을 SNI와 서버 인증서 검증에 사용하므로, 연결 주소만 바꾸는 시험을 구성할 수 있습니다. 시스템 전체의 DNS 설정을 바꾸는 설명은 아니에요.

curl --http1.1 --noproxy "*" --resolve example.com:443:192.168.0.1 https://example.com/

이 예시의 URL 이름은 example.com이고 연결 주소는 192.168.0.1입니다. Host를 덮어쓰는 옵션은 넣지 않았죠. --resolve의 이름·포트가 URL과 맞는지 먼저 확인하세요. 이름을 유지한다는 목적은 인증서 검증을 생략한다는 뜻이 아니죠.

curl 옵션 문서 기준으로 --http1.1은 HTTP/1.1을 사용하게 하고, --noproxy "*"는 프록시를 사용하지 않게 합니다. 여기서는 직접 연결 조건을 맞추기 위한 예시입니다. 프록시가 필수인 환경의 요청 경로까지 검증하는 명령은 아니므로, 그 환경의 결과와 섞어 비교하지 마세요.

점검 결과는 어떤 순서로 해석해야 하나요?

연결 주소와 URL 이름을 먼저 확인하고, 인증서 검증 결과와 HTTP 응답을 차례로 나누어 해석합니다.

아래 표는 원인을 확정하는 진단표가 아니라, 관찰한 결과를 나누는 운영 제안이죠. URL·연결 IP·Host가 무엇인지와 인증서 검증 결과를 먼저 기록합니다. 그 뒤 반환된 페이지가 기대한 대상인지 확인하는 순서죠.

예를 들어 인증서 검증이 통과했는데 페이지가 다르다면, 인증서를 다시 발급해야 한다고 바로 결론 내리지 마세요. 반대로 인증서 오류를 무시하고 페이지를 열었다고 HTTPS가 정상이라고 기록해서도 안 됩니다. 확인한 단계까지만 결과로 남기는 편이 좋아요.

한 IP의 결과만으로 모든 접속 경로가 정상인지 판단할 수는 없습니다. 시험한 주소와 이름의 조합, 실행 시각과 응답 내용을 함께 남기는 편이 좋죠. 이 글의 목적은 설정을 일괄 변경하는 것이 아니라, 서로 다른 입력으로 얻은 결과를 혼동하지 않도록 하는 데 있습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)