NET::ERR_CERT_NON_UNIQUE_NAME 원인

Problem

Chrome이 NET::ERR_CERT_NON_UNIQUE_NAME과 “연결이 비공개로 설정되어 있지 않습니다” 화면으로 페이지를 거부합니다. 인증서는 만료 안 됐을 수 있습니다. 이름도 완벽히 맞을 수 있습니다. 체인도 풀릴 수 있습니다. 여기선 그중 무엇도 상관없습니다 — 이 에러는 인증서가 호스트에 맞느냐가 아니라, 호스트 이름 자체가 어떤 공개 신뢰 인증서도 덮을 수 없는 종류라는 것에 관한 것이기 때문입니다.

Chrome 자체 에러 테이블은 딱 잘라 말합니다: 에러 코드 -210, “인증서에 지정된 호스트 이름이 유일하지 않다.” 유일하지 않은 이름이란 둘 이상의 네트워크가 정당하게 주장할 수 있는 이름입니다 — intranet이나 server.local 같은 내부 호스트명, 뒤에 공개 도메인이 없는 단일 레이블 이름, 또는 192.168.1.10이나 10.0.0.5 같은 사설·예약 IP 주소. 그 이름들은 인증 기관이 검증할 수 있는 어떤 방식으로도 당신 것이 아니라서, 규칙이 인증을 금지하고, Chrome이 그 규칙을 강제합니다.

Symptoms

• 에러가 더 흔한 ERR_CERT_COMMON_NAME_INVALID가 아니라 NET::ERR_CERT_NON_UNIQUE_NAME입니다 — 여기선 이름이 인증서와 정확히 맞아도 거부되므로 이 구분이 중요합니다.
• 짧은 이름(https://git, https://wiki)이나 사설 IP(https://192.168.x.x)로 접근하는 내부 도구에서 나타납니다.
• 인증서는 그 외엔 멀쩡해 보입니다 — 이름 일치, 미만료, 완전한 체인 — 그래서 헷갈립니다.
• 같은 인증서가 당신이 직접 설치한 CA로 체인될 땐 수용되고, 공개 루트로 체인될 땐 거부됩니다.
• 내부 서비스를 공개 인증서 뒤로 옮긴 뒤, 또는 기업 장비가 맨 내부 이름으로 만든 인증서를 달고 출고된 뒤 자주 뜹니다.

Why the Name Is the Problem

다른 모든 인증서 에러는 인증서의 속성에 관한 것입니다: 만료됐다, 체인이 끊겼다, 서명이 약하다, 이름이 안 맞는다. NET::ERR_CERT_NON_UNIQUE_NAME은 다릅니다. 인증서가 흠 하나 없어도 거부될 수 있습니다 — 잘못된 건, 공개 CA가 특별히 누구의 것도 아닌 이름을 보증했다는 사실이기 때문입니다.

CA/Browser Forum Baseline Requirements가 이걸 몇 년 전에 정리했습니다. 내부 서버 이름과 예약 IP 주소는 공개 신뢰 인증서에서 폐지됐습니다: CA는 2015년 11월에 발급을 중단했고, 남은 것은 2016년 10월 1일까지 폐기해야 했습니다. 이유는 보안 도구가 가장 신경 쓰는 바로 그것입니다. mail 같은 이름은 유일하지 않고 — 수많은 네트워크가 mail 호스트를 가집니다 — 그래서 CA는 mail 인증서를 요청한 쪽이 “진짜”인지 검증할 방법이 없습니다. 진짜가 없으니까요. 그 인증서를 발급하면, 자기가 지나는 모든 네트워크에서 mail을 사칭하는 공개 신뢰 자격증명을 뿌린 셈입니다. 유효한 자물쇠가 달린 중간자 공격 키트입니다.

그래서 해결책은 절대 공개 CA에게 금지된 일을 억지로 시키는 게 아닙니다. 이름을 유일하게 만들거나(당신이 소유한 도메인의 진짜 서브도메인), 당신이 통제하고 스스로 신뢰하는 기관(사설·내부 CA)에서 인증하는 것입니다. Chrome이 로컬 설치 루트의 유일하지 않은 이름을 수용하는 건 바로 당신이 그 이름에 책임을 졌기 때문이고, 공개 루트의 것을 거부하는 건 어떤 공개 기관도 그럴 권한이 없기 때문입니다.

Top Causes

1. HTTPS로 접근하는 짧은 내부 호스트명 - https://git, https://wiki, https://nas — 뒤에 공개 도메인이 없는 단일 레이블 이름. 인증서가 묶을 전역 유일 이름이 없어서, 그 위의 공개 인증서는 정책상 무효이고 Chrome이 NON_UNIQUE_NAME을 냅니다.

2. 사설 IP로 직접 HTTPS - https://192.168.1.20이나 https://10.0.0.5에 직접 접속. RFC 1918 주소는 예약돼 있고 지구상 모든 사설 네트워크가 공유하므로, 유일하지 않음의 정의 그 자체입니다. 공개 CA는 인증할 수 없습니다.

3. 2016년 컷오프 전에 내부 이름으로 만든 옛 인증서 - 레거시 장비, 기업 PKI 내보내기, 또는 맨 내부 이름의 공장 인증서를 달고 출고된 장비. 아직 설치돼 서빙 중일 수 있지만, 최신 Chrome은 그것이 덮는 유일하지 않은 이름을 이제 거부합니다.

4. 내부 엔드포인트에 잘못 발급·기대된 공개 인증서 - 누군가 내부 전용 서비스를 일반 공개 인증서로 보호하려고 내부 이름을 그 안에 넣었습니다. 발급이 아니라 이름이 막는 겁니다.

Diagnose with DechoNet

• SSL 진단은 호스트가 실제로 제시하는 인증서를 검사해 그것이 덮는 이름과 만드는 체인을 보여줍니다. 그게 빠른 갈림입니다: 인증서가 맨 내부 레이블이나 사설 IP를 담고 있다면, 유일하지 않은 이름이 문제임을 확인한 것이고, 해결은 공개 CA 재발급이 아니라 진짜 이름 또는 사설 CA입니다.
• DNS 진단은 이름이 무엇으로 해석되는지 확인합니다. 호스트명이 RFC 1918 사설 주소를 가리키면 예약 IP 사례이고, 도메인 없는 단일 레이블이면 내부 이름 사례입니다. 어느 쪽인지 알면 서비스 이름을 바꿀지 내부 CA를 세울지 결정됩니다.

Resolution Checklist

• 인증서의 이름을 확인하세요. SSL 진단으로 subject와 SAN 항목을 읽습니다. 맨 레이블(git), .local/내부 전용 이름, 또는 사설 IP가 Chrome이 거부하는 유일하지 않은 이름입니다.
• 대상 이름을 정하세요. 서비스가 진짜 전역 유일 이름을 가질 수 있다면 당신이 소유한 도메인의 서브도메인(예: git.internal.example.com)을 주세요 — 네트워크 안에서만 해석돼도 됩니다.
• 진짜 유일 이름이면 일반 인증서를 받으세요. 공개 CA는 당신이 통제하는 이름이면 사설로 해석돼도 발급합니다; 해석은 내부 DNS가 처리합니다.
• 내부 전용 이름이나 사설 IP면 내부 CA를 세우세요. 거기서 인증서를 발급하고 그 CA 루트를 모든 클라이언트 신뢰 저장소에 배포하세요. mkcert 같은 도구가 개발·소규모 내부 환경에서 정확히 이걸 자동화합니다.
• intranet, .local, 사설 IP에 공개 인증서를 사려 하지 마세요 — 어떤 공개 CA도 발급할 수 없고, 존재하는 건 정책 위반이라 계속 실패합니다.
• 경고를 그냥 클릭해 지나치지 마세요. NON_UNIQUE_NAME을 우회하는 건 공유되고 사칭 가능한 이름이 신뢰되는 걸 막는 검사를 끄는 겁니다. 대신 이름이나 발급자를 고치세요.

When to Escalate

• 이름이 당신이 관리하지 않는 매니지드 장비나 기업 PKI의 것이면, 그 소유자에게 에스컬레이션하세요 — 인증서나 CA를 그 계층에서 재발급해야 하고, 유일하지 않은 이름은 클라이언트 쪽에서 못 고칩니다.
• 내부 서비스를 신뢰 인증서로 사설 IP를 통해 정말 도달해야 한다면, 그건 일회성 인증서 구매가 아니라 내부 CA 프로젝트입니다. 장비마다 우회책을 쌓기 전에 신뢰 저장소 배포를 관리하는 쪽을 끌어들이세요.