NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION 해결

문제

Chrome이 사이트를 NET::ERR_CERT_NAME_CONSTRAINT_VIOLATION로 거부하는데, 흔한 조언 — 만료 확인, 중간 인증서 설치, 루트 신뢰 — 은 아무것도 해결하지 못합니다. 그 어느 것도 원인이 아니기 때문입니다. 체인은 신뢰됩니다. 이름은 맞습니다. 인증서는 만료되지 않았습니다. 잘못된 건 더 구체적이고 더 흥미롭습니다: 체인 안의 한 인증기관이 어떤 이름을 서명해도 되는지 정확히 지정받았는데, 이 인증서가 그 목록 바깥의 이름을 위한 것입니다.

증상

• Chrome/Edge가 net::ERR_CERT_NAME_CONSTRAINT_VIOLATION를 냅니다 — 공개 사이트보다 사내·기업 사이트에서 자주 뜹니다.
• 인증서는 그 외엔 멀쩡해 보입니다: 유효 기간 정상, SAN에 호스트명 있음, 체인이 신뢰 루트까지 연결됨.
• 사설·기업 CA와 함께 자주(또는 새로) 나타나고, 때로는 Chrome 업데이트 직후에 뜹니다.
• 다른 도구 — 구버전 브라우저, openssl, 일부 비-Chromium 클라이언트 — 는 같은 인증서를 받아들일 수 있습니다. 제약을 덜 엄격하게 강제하기 때문입니다.

이 오류의 진짜 의미

CA 인증서는 그 CA — 그리고 트리에서 그 아래 모든 것 — 이 발급해도 되는 범위를 가두는 이름 제약(Name Constraints) 확장(RFC 5280 §4.2.1.10)을 담을 수 있습니다. 두 부분으로 나뉩니다: CA가 발급할 수 있는 이름 공간인 permittedSubtrees, 그리고 발급할 수 없는 excludedSubtrees. 최소한 하나는 있어야 하고, 배제는 언제나 허용을 이깁니다. RFC 5280은 준수 CA가 이 확장을 critical로 표시할 것을 요구하는데, 그게 핵심입니다: 이 확장을 이해하지 못하는 클라이언트는 울타리를 조용히 무시하는 게 아니라 인증서를 거부해야 합니다.

DNS 이름의 매칭 규칙은 왼쪽 레이블 추가입니다. example.com 제약은 example.com, www.example.com, a.b.example.com — 왼쪽에 레이블을 붙여 만들 수 있는 모든 것 — 을 허용합니다. notexample.com은 허용하지 않고, 다른 도메인으로 옆으로 뻗지도 않습니다. 그러니 CA가 corp.example.com으로 제약됐는데 누군가 example.net(또는 한 단계 위인 example.com)의 인증서를 발급하면, 그 leaf는 허용 서브트리 바깥이고 검증 클라이언트는 체인을 거부합니다.

그래서 진단이 처음엔 거꾸로 느껴집니다. 사람들이 집어드는 모든 점검 — 신뢰, 만료, 호스트명 일치 — 이 통과합니다. 실패는 한 단계 위에 있습니다: leaf의 유효성이 아니라 발급자의 권한이요. 제약된 CA는 그럴 만한 이유로 존재합니다. CA/Browser Forum의 Ballot 105(2013)는 “기술적으로 제약된 하위 CA(technically constrained subordinate CA)“를 정의했는데, 조직이 공개 루트 아래에서 전체 감사 없이 자체 발급 CA를 운영할 수 있게 하기 위해서였습니다 — 그 대가로 TLS 서버 EKU를 가진 그런 하위 CA는 dNSName, iPAddress, DirectoryName에 대한 이름 제약을 반드시 담아야 합니다. 사내 PKI가 제약하는 이유도 비슷합니다: 자기 CA가 소유하지 않은 도메인의 신뢰된 인증서를 절대 찍어낼 수 없게 보장하려는 거죠. 이 확장은 기능입니다. 이 오류는 발급되지 말았어야 할 인증서에 대해 그 기능이 제 일을 하고 있는 것입니다.

가장 흔한 원인 3가지

1. 제약된 사내 CA가 허용 도메인 바깥을 발급 - 기업 PKI에서 가장 흔한 경우입니다. 사내 발급 CA(또는 그 위 루트)가 예컨대 permittedSubtrees = corp.example.com으로 제약됐는데, 누군가 example.io 아래 호스트나 벌거벗은 example.com의 인증서를 요청한 거죠. 빌드도 되고 체인도 잘 서지만 울타리 바깥입니다. 수정은 허용 서브트리 안의 이름으로 인증서를 재발급하거나, 그 새 도메인이 정말 그들 소유라면 CA의 제약을 넓혀 CA를 재발급하는 것입니다.
2. Chrome 112+가 이제 가져온 루트의 제약을 강제 - 당신이 배포하는 기업 루트에서 브라우저 업데이트 후 깨졌다면 이게 이유입니다. Chrome은 112(2023년 4월)부터 사용자가 가져온·엔터프라이즈 신뢰 앵커의 이름 제약을 존중하기 시작했습니다. 그 전엔 중간 인증서의 제약만 강제했죠. 몇 년 전 안전장치로 제약해 둔 루트가 갑자기 강제되는 겁니다. 그 인증서들은 사실 한 번도 준수한 적이 없었고 — 허용 이름 안에서 재발급하거나 올바른 제약으로 루트를 다시 만드세요.
3. 허용 IP 서브트리 바깥의 IP 주소 SAN - 제약은 이름 형태별로 적용되므로, iPAddress SAN을 가진 인증서는 DNS 제약과 별개로 CA의 iPAddress 허용 서브트리와 대조됩니다. TLS용 기술 제약 하위 CA는 IP 제약도 담고, 허용 CIDR 바깥의 IP SAN — 또는 DNS 이름만 발급하려 했는데 IP SAN이 들어간 경우 — 은 위반을 냅니다. 수정은 문제의 IP SAN을 빼거나 그 IP 범위를 CA 제약에 포함시키는 것입니다.

DechoNet으로 진단하기

• SSL 진단은 당신 기기 바깥에서 전체 인증서 체인을 가져와 leaf의 SAN을 읽고 이름 제약을 담은 CA까지 거슬러 올라갈 수 있게 합니다. leaf의 이름들을 제약된 서브트리와 대조하는 것이 진단의 전부입니다.
• HTTP 진단은 서버가 살아 응답하는지 확인해, 인증서 정책 거부와 실제 연결·리다이렉트 문제를 갈라냅니다.

해결 체크리스트

• leaf만이 아니라 체인을 읽으세요. 인증서 체인을 가져와 어느 CA가 이름 제약 확장을 담고 있는지, 그 permittedSubtrees / excludedSubtrees가 무엇인지 식별하세요.
• leaf의 모든 이름 — 각 dNSName SAN과 iPAddress SAN — 을 그 서브트리와 대조하세요. 허용 바깥(또는 배제 안)에 떨어지는 구체적 이름을 찾으세요.
• 그 이름이 허용돼야 한다면 허용 서브트리 안의 이름으로 leaf를 재발급하고, 그 이름 공간 전체가 정당히 당신 것이면 CA의 제약을 넓혀 CA를 재발급하세요(그 아래 모든 인증서에 영향).
• 사내 루트에서 Chrome 업데이트 후 시작됐다면, 원래부터 있던 루트 제약을 Chrome 112+가 강제하는 것으로 다루세요 — 재발급 경로는 같고, 어떤 브라우저 플래그도 이걸 “고치지” 못합니다.
• SSL 진단을 다시 돌려 이제 모든 leaf 이름이 CA의 허용 서브트리 안에 있는지 확인하세요.

에스컬레이션 시점

• 인증서가 당신 조직이 정말 소유한 이름인데 CA 제약 바깥에 있다면, 사내 PKI를 운영하는 쪽에 넘기세요: CA의 이름 제약을 넓히고 CA를 재발급해야 하며, 이는 인증서 하나하나의 수정이 아니라 통제된 변경입니다.
• 이것이 공개 신뢰된 기술 제약 하위 CA가 허용 이름 바깥을 발급한 경우라면, CA 운영자에게 올리세요 — 그 하위 CA는 스스로 약속한 제약을 어긴 것이며, 그들 쪽 정책 문제입니다.
• 체인에서 이름 제약을 전혀 못 찾겠는데 Chrome이 여전히 위반을 보고하면, 전체 체인을 손에 쥐고 에스컬레이션하세요: 무언가가 당신이 예상하는 것과 다른 중간 인증서(교차 서명되거나 잘못 설정된 경로)를 제시하고 있고, 서빙되는 체인을 바로잡아야 합니다.