Chrome은 열리는데 Firefox는 SSL_ERROR_BAD_CERT_DOMAIN을 띄웁니다. 왜죠?

같은 결함을 다른 문구로 보고하는 것입니다 — Chrome은 이를 NET::ERR_CERT_COMMON_NAME_INVALID라고 부릅니다. 두 브라우저 모두 레거시 Common Name이 아니라 SAN 목록을 검사합니다. 한 브라우저만 접속된다면 대개 캐시된 인증서나 다른 SNI 가상호스트에 닿은 것이지, 규칙에 대한 진짜 이견이 아닙니다.

인증서 Common Name이 제 도메인과 정확히 같은데 왜 불일치인가요?

현대 브라우저가 Common Name을 더는 신뢰하지 않기 때문입니다. Firefox와 Chrome은 SAN 목록만 검증하며, Chrome은 58(2017)에서 Common Name 폴백을 제거했고 CA/Browser Forum은 2012년부터 SAN을 요구해 왔습니다. CN은 맞아도 SAN이 안 맞으면 실패합니다.

와일드카드 인증서가 있으면 다 커버되지 않나요?

아닙니다. `*.example.com`은 왼쪽 한 레이블만 커버합니다. `www.example.com`은 되지만 루트 `example.com`은 안 되고, `a.b.example.com`도 안 됩니다. 루트와 각 중첩 이름은 자체 SAN 항목이 필요합니다.

조회수: 20

SSL_ERROR_BAD_CERT_DOMAIN 해결

SSL_ERROR_BAD_CERT_DOMAIN는 인증서가 이 호스트명을 커버하지 않는다는 뜻. SAN 목록, www vs 루트, 와일드카드 범위를 점검. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

Firefox가 SSL_ERROR_BAD_CERT_DOMAIN으로 페이지를 차단합니다.

Symptoms

Firefox가 SSL_ERROR_BAD_CERT_DOMAIN을 언급하며 “주의: 잠재적인 보안 위험” 페이지를 표시합니다.
같은 서버에서 Chrome은 NET::ERR_CERT_COMMON_NAME_INVALID를 보여줍니다.
일부 호스트명만 실패합니다 — 흔히 www나 특정 서브도메인 — 반면 같은 사이트의 다른 이름은 정상 로드됩니다.

이 오류의 실제 의미

인증서는 진짜이고, 신뢰되며, 만료되지도 않았습니다. 단지 당신이 입력한 이름으로 발급되지 않았을 뿐입니다. Firefox는 인증서를 읽고, 주소창의 호스트명을 인증서가 보증하는 이름들과 대조한 뒤, 일치가 없으면 멈춥니다. 이것은 신뢰 검사가 아니라 이름 검사입니다 — 바로 이 점이 SEC_ERROR_UNKNOWN_ISSUER(브라우저가 신뢰하지 않는 체인)나 만료 오류(날짜가 틀림)와 구분되는 지점입니다. 여기서는 체인도 날짜도 멀쩡하고, 오직 이름만 어긋납니다.

중요한 이름들은 인증서의 Subject Alternative Name(SAN) 목록에 있습니다. Firefox는 그 외에는 아무것도 읽지 않습니다. 도메인을 담고 있는 것처럼 보이는 옛 Subject Common Name 필드는 무시됩니다. 이것은 Firefox만의 특성이 아닙니다. Chrome은 58(2017)에서 Common Name 폴백을 제거했고, CA/Browser Forum Baseline Requirements는 2012년부터 SAN을 요구해 왔습니다. 그래서 Common Name이 example.com이라도 SAN 목록에 방문한 정확한 호스트명이 빠져 있으면 현재의 모든 브라우저에서 실패합니다. 다만 브라우저마다 다른 문장으로 실패할 뿐입니다.

Top 3 Causes

호스트명이 SAN 목록에 없음 - 전형적 사례는 example.com은 커버하지만 www.example.com은 커버하지 않는(또는 그 반대) 인증서입니다. 각 이름은 별개의 SAN 항목이며, 하나를 발급한다고 다른 하나가 자동으로 포함되지 않습니다.
와일드카드 범위를 오해 - *.example.com은 단일 레이블 레벨만 커버합니다. 루트 example.com도, a.b.example.com도 커버하지 않습니다. 와일드카드를 만능으로 가정하는 것이 두 번째로 흔한 원인입니다.
요청이 엉뚱한 인증서에 도달 - DNS, 프록시, CDN 엣지, 기본 가상호스트가 연결을 종료하며 다른 테넌트의 인증서를 제시합니다. 생각한 서버에 닿지 않으니 원하는 이름은 자기 인증서를 받지 못합니다. 원시 IP로 접속해도 같은 일이 벌어집니다.

Diagnose with DechoNet

SSL Check로 인증서의 SAN 목록을 읽고, 실패하는 정확한 호스트명(루트, www, 서브도메인)이 실제로 나열돼 있는지 확인하세요.
DNS Lookup으로 이름이 의도한 서버로 해석되는지 확인하세요 — 엉뚱한 오리진·CDN·파킹 호스트가 잘못된 인증서를 서빙하고 있을 수 있습니다.
HTTP Check로 프록시나 리다이렉트가 개입할 때 요청이 실제로 어디서 종료되는지 확인하세요.

Resolution Checklist

SSL Check를 돌려 SAN 목록을 읽고, 실패하는 호스트명이 글자 그대로 들어 있는지 확인하세요.
빠져 있다면 서빙하는 모든 호스트명(루트 와 www, 그리고 서브도메인)을 SAN에 넣어 인증서를 재발급하세요.
와일드카드에 의존한다면 실패하는 이름이 와일드카드 한 레이블 아래인지 확인하세요 — 루트도 더 깊은 서브도메인도 아님.
DNS가 올바른 오리진을 가리키고, 프록시나 CDN 엣지가 다른 인증서를 제시하지 않는지 확인하세요.
SSL Check를 다시 돌려 호스트명이 이제 SAN 항목과 일치하는지 확인하세요.

When to Escalate

인증서는 발급됐고 올바른데 CDN이나 로드밸런서가 계속 엉뚱한 것을 서빙한다면, 해당 엣지 담당자에게 에스컬레이션하세요 — 이 불일치는 인증서 문제가 아니라 라우팅 문제입니다.
빠진 이름으로 재발급할 수 없다면(관리형 플랫폼, 서드파티 호스트) SAN 목록과 실패 호스트명을 플랫폼 담당자에게 전달하세요 — 수정은 그들의 몫입니다.