ERR_SSL_UNRECOGNIZED_NAME_ALERT: Fix the SNI Alert

문제

Chrome이 ERR_SSL_UNRECOGNIZED_NAME_ALERT를 띄우고 페이지 로딩을 거부합니다. 본능적으로 인증서를 탓하게 되는데, 그 본능이 틀렸습니다. 여기서 거부된 인증서는 없습니다 — 애초에 제시된 적이 없거든요. 이 오류는 어떤 인증서 검사보다도 먼저, TLS 핸드셰이크의 맨 첫 교환에서 발생하며, 서버가 당신의 호스트명을 받고 이렇게 답한 것입니다: 그 이름으로 설정된 게 아무것도 없다.

원리는 이렇습니다. 클라이언트가 TLS 연결을 열 때 ClientHello를 보내는데, 그 안에 당신이 요청한 호스트명 — www.example.com — 을 담은 Server Name Indication(SNI) 필드가 들어 있습니다. 보통 IP 주소 하나가 여러 사이트를 앞단에서 받으므로, 서버는 SNI로 어느 가상 호스트와 어느 인증서로 응답할지 고릅니다. 일치를 못 찾으면 RFC 6066 §3이 두 선택지를 줍니다: 조용히 기본값으로 진행하거나, 치명적 unrecognized_name(112) 경고를 보내 핸드셰이크를 중단하거나. 서버가 두 번째를 택하면 Chrome이 그 경고를 ERR_SSL_UNRECOGNIZED_NAME_ALERT로 번역합니다. 그러니 이 오류는 잘못된 인증서 문제가 아닙니다. 서버가 알아보지 못하는 이름의 문제입니다.

증상

• Chrome(및 Chromium 계열 브라우저)이 ERR_SSL_UNRECOGNIZED_NAME_ALERT를 표시합니다. Firefox는 같은 경고에 대해 SSL_ERROR_UNRECOGNIZED_NAME_ALERT를 보일 수 있습니다.
• 일부 방문자에겐 간헐적이고 일부에겐 완전히 막힙니다 — 클라이언트마다 다른 SNI를 보낸다는 강한 힌트입니다.
• 같은 IP의 다른 호스트명은 멀쩡히 열리고, 특정 이름 하나만 이 오류에 걸립니다.
• openssl s_client에 호스트명을 -servername으로 넘기되 틀린 이름을 주면 실패하며, 서버는 인증서 체인을 출력하는 단계까지 가지도 못합니다.

주요 원인 3가지

1. 서버에 그 호스트명의 가상 호스트가 없음 - DNS를 그 이름에 대한 설정이 전혀 없는 서버(또는 새 로드밸런서, 갓 만든 Cloudflare/CDN 오리진)로 돌린 경우입니다. 흔한 변형: 와일드카드나 apex는 되는데 www — 또는 방금 만든 서브도메인 — 를 추가한 적이 없는 것. 서버는 어떤 사이트에도 매핑 못 하는 SNI를 보고, 추측 대신 경고를 보냅니다.
2. 엄격한 기본 가상 호스트가 모르는 이름을 거부 - Apache에서 SSLStrictSNIVHostCheck on은 설정된 ServerName/ServerAlias와 일치하지 않는 SNI를 기본 vhost로 폴백하지 않고 거부하라는 지시입니다. 이 설정이 ‘없는 이름’을 하드한 unrecognized_name 경고로 바꿉니다. 이름은 해석되고 TCP 연결도 열리는데, 핸드셰이크가 원칙에 따라 죽습니다.
3. 클라이언트가 틀린 SNI를 보내거나 아예 안 보냄 - 덜 흔하지만 추적이 더 고약합니다. --resolve 없이 IP로 지정한 curl, 오래된 Java·Python TLS 스택, 모니터링 에이전트가 빈 SNI나 불일치 SNI를 보낼 수 있습니다. 서버는 지시받은 대로 — 모르는 이름을 거부 — 정확히 수행하고, ‘고장 난’ 쪽은 사이트가 아니라 클라이언트입니다. 그래서 이 오류가 사람 방문자는 다 멀쩡한데 가동 모니터만 때릴 수 있습니다.

DechoNet으로 진단

• SSL 점검을 실패하는 호스트명에 대해 돌리면, 서버가 그 이름에 대한 유효한 인증서를 제시하는지 알 수 있습니다. DechoNet이 정상 체인을 가져오면 서버는 그 이름을 알아보는 것이고 — 문제는 나쁜 SNI를 보내는 클라이언트입니다. 여기서도 핸드셰이크를 못 끝내면, 그 이름은 정말로 그 서버에 자리가 없는 것입니다.
• DNS 점검은 호스트명이 실제로 어디를 가리키는지 보여줍니다. 열에 아홉은 이 경고가, 서빙하도록 설정된 적 없는 IP로 이름을 겨눈 DNS로 거슬러 올라갑니다 — 오래된 A 레코드, 절반만 끝난 마이그레이션, 엉뚱한 오리진을 향한 CNAME.

해결 체크리스트

• 어느 쪽이 틀렸는지 확정하세요. 호스트명을 일반 브라우저에서 열고 외부 TLS 점검을 돌립니다. 모든 클라이언트가 실패 → 서버 쪽. 한 클라이언트만 실패 → 그 클라이언트의 SNI.
• 서버 쪽이면, 정확한 호스트명을 가상 호스트로 추가하고 인증서가 그 이름을 커버하는지(apex뿐 아니라 SAN 항목) 확인하세요. 설정을 리로드하고 재점검합니다.
• Apache라면 SSLStrictSNIVHostCheck를 의식적으로 결정하세요. on으로 두는 건 정당합니다 — 서빙하려는 모든 이름을 명시적으로 설정해야 한다는 뜻일 뿐입니다. off로 하면 기본 vhost가 모르는 이름에 답하게 되는데, 이는 오설정을 고치는 게 아니라 가리는 것입니다.
• 클라이언트 쪽이면, 올바른 SNI를 강제하세요: curl --resolve yourdomain.com:443:1.2.3.4 https://yourdomain.com, 또는 TLS 라이브러리에 서버 이름을 명시적으로 설정합니다. SNI를 못 보내는 오래된 스택은 업그레이드하세요.
• openssl s_client -connect HOST:443 -servername yourdomain.com으로 검증하세요. 깨끗한 핸드셰이크와 출력된 인증서 체인은 그 이름이 이제 인식된다는 뜻입니다.

에스컬레이션 시점

• SSL 점검이 그 이름에 대한 유효한 인증서를 가져오는데도 특정 클라이언트 하나가 여전히 경고에 걸리면, 논쟁 끝입니다: 그 클라이언트가 틀린 SNI를 보내는 것입니다. -servername 테스트를 증거로 그 클라이언트 담당자에게 넘기세요 — 웹훅 발신자, 서드파티 모니터, SDK.
• 가상 호스트와 인증서를 추가했는데도 경고가 지속되면, 당신 서버 앞단에서 자체 SNI 설정으로 TLS를 종료하는 프록시나 로드밸런서를 의심하세요. 이름은 실제로 핸드셰이크를 끝내는 홉에서 인식되어야 하고 — 그건 흔히 당신이 편집하던 그 박스가 아닙니다.
• 특정 네트워크나 지역에서만 오류가 나면, SNI를 재작성하거나 벗겨내는 가로채기 미들박스를 의심하세요. 그건 더 이상 서버 버그가 아니라 경로의 문제이고, 정상 네트워크와 문제 네트워크에서 와이어상의 SNI를 비교해 진단합니다.