NET::ERR_CERT_COMMON_NAME_INVALID

이 오류의 의미와 확인 방법

• Chrome 또는 Edge에 NET::ERR_CERT_COMMON_NAME_INVALID와 함께 “연결이 비공개로 설정되어 있지 않습니다”가 표시됩니다.
• 인증서 세부 정보에 다른 호스트 이름의 Common Name 또는 Subject Alternative Name이 표시됩니다.
• 기본 도메인은 정상적으로 작동하지만 특정 서브도메인에서 오류가 발생합니다.
• 서브도메인을 추가하거나, DNS를 변경하거나, 호스팅을 이전하거나, CDN 또는 로드 밸런서를 활성화한 후 오류가 시작됩니다.
• 공유 서버 또는 CDN이 기본 인증서, 플레이스홀더 인증서 또는 관련 없는 인증서를 제공합니다.
• 일부 사용자 또는 네트워크에서만 오류가 발생하고 다른 곳에서는 발생하지 않습니다. 이는 IPv4, IPv6, DNS 또는 엣지 라우팅 경로가 서로 다르다는 신호일 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 인증서에 요청한 호스트 이름이 포함되어 있지 않습니다. 오류가 발생하는 호스트 이름이 인증서의 SAN 목록에서 누락되었을 수 있습니다. 와일드카드는 일부 서브도메인을 포함할 수 있지만, 해당 범위가 요청한 이름과 일치해야 합니다.
2. 서버가 기본 인증서를 제공하고 있습니다. 공유 호스팅에서 인증서가 도메인에 할당되지 않았거나 SNI 및 HTTPS 가상 호스트 선택이 잘못되었을 수 있습니다.
3. CDN 또는 로드 밸런서에 잘못된 엣지 인증서가 설정되어 있습니다. 해당 호스트 이름이 서비스에 구성되지 않았거나 요청이 기본 리스너 또는 엣지 구성으로 전달될 수 있습니다.
4. DNS가 잘못된 엔드포인트를 가리킵니다. 잘못된 A, AAAA 또는 CNAME 레코드는 다른 사이트의 인증서를 제공하는 서버로 요청을 보낼 수 있습니다. 잘못된 AAAA 레코드는 IPv4가 정상적으로 작동하더라도 IPv6 사용자에게 영향을 줄 수 있습니다.
5. 마이그레이션 또는 도메인 변경 후 서비스 구성이 동기화되지 않았습니다. DNS, CDN, 오리진 서버 및 인증서가 서로 다른 호스트 이름이나 엔드포인트로 구성되어 있을 수 있습니다.

해결 방법

1. 정확한 호스트 이름과 인증서 불일치 확인

주소 표시줄의 전체 호스트 이름을 확인하세요. 모든 서브도메인을 포함해야 합니다. 브라우저의 인증서 세부 정보를 열고 Common Name과 Subject Alternative Names (SANs)을 검사하세요. 요청한 호스트 이름은 SAN 목록에 표시되거나 적용 가능한 와일드카드 패턴과 일치해야 합니다.

명령줄에서 확인하려면 테스트할 호스트 이름으로 변수를 설정하세요.

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

-servername 옵션은 SNI를 통해 호스트 이름을 전송합니다. 이는 공유 HTTPS 인프라에서 중요합니다. 구성을 변경하기 전에 진단 명령을 실행하세요.

2. 인증서에 호스트 이름 추가

인증서가 기본 도메인은 포함하지만 오류가 발생하는 서브도메인은 포함하지 않는다면, 필요한 호스트 이름을 SAN으로 포함하도록 인증서를 재발급하거나 교체하세요. 와일드카드 인증서는 여러 1단계 서브도메인을 포함할 수 있지만, 기본 도메인과 더 깊은 서브도메인이 별도로 보장되는지 확인해야 합니다.

Certbot을 사용하는 경우 먼저 해당 도메인의 인증서를 요청하고 배포할 권한이 있는지, webroot가 올바른지, 검증 방법이 서버에 적합한지 확인하세요. 인증서 발급 요청에 필요한 모든 이름을 포함하세요.

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

이 명령은 인증서를 발급하지만 그 자체로 인증서를 설치하거나 활성화하지는 않습니다. 서버에 적합한 발급 방법과 webroot를 사용한 다음, HTTPS를 종료하는 엔드포인트에 인증서를 설치하고 올바른 호스트 이름에 할당하세요.

3. 공유 호스팅 및 오리진 서버 구성 확인

호스팅 제어판에서 인증서가 설치되어 있고 정확한 도메인 또는 서브도메인에 할당되어 있는지 확인하세요. 공유 서버를 사용하는 경우 제공업체에 SNI 기반 인증서 선택과 HTTPS 가상 호스트 구성을 확인해 달라고 요청하세요.

인증서 파일, 권한 및 구성이 올바른지 확인한 후에만 웹 서버를 다시 로드하거나 재시작하세요. 다시 로드하거나 재시작하면 서비스가 중단될 수 있으므로 제공업체의 변경 절차를 따르고 적용에 필요한 권한을 확보하세요.

4. CDN 및 로드 밸런서의 인증서 범위 확인

정확한 호스트 이름이 CDN 또는 로드 밸런서에 구성되어 있고 엣지 인증서에 포함되어 있는지 확인하세요. 해당 호스트 이름이 의도한 오리진으로 라우팅되는지도 확인해야 합니다.

CDN이 HTTPS를 종료하는 경우 오리진 인증서만으로는 브라우저의 불일치 오류가 해결되지 않습니다. 공개 엣지 엔드포인트가 제공하는 인증서가 호스트 이름을 포함해야 합니다. CDN이 HTTPS를 통과시키는 경우에는 오리진의 인증서를 검사하세요.

5. IPv4 및 IPv6용 DNS 확인

호스트 이름의 A, AAAA 및 CNAME 레코드를 호스팅 또는 CDN 제공업체가 제공한 엔드포인트나 대상과 비교하세요. 오류가 발생하는 네트워크가 IPv4 또는 IPv6 중 어떤 것을 사용하는지, 두 경로가 모두 의도한 서비스에 연결되는지 확인하세요.

의도한 엔드포인트와 적절한 DNS 변경 절차를 확인한 후에만 오래되었거나 의도하지 않은 레코드를 수정하세요. 캐시된 DNS 응답은 TTL이 만료될 때까지 유지될 수 있으므로 문제가 발생한 네트워크에서 결과를 확인하세요.

6. 동일한 HTTPS 호스트 이름 재테스트

인증서 할당, 라우팅 또는 DNS를 변경한 후 오류가 발생한 정확한 URL을 테스트하세요. 반환된 인증서를 다시 검사하여 SAN 목록, 발급자 및 유효 기간을 확인하세요. 호스팅, CDN 또는 서버 환경뿐 아니라 문제가 발생한 네트워크에서도 테스트하여 전파 또는 리졸버 차이와 현재 구성 오류를 구분하세요.

예방 및 해결 확인 방법

• 서브도메인을 추가하거나, DNS를 변경하거나, 호스팅을 이전하거나, CDN을 추가할 때마다 인증서 범위를 포함해 확인하세요.
• 실제 서비스에서 사용하는 기본 도메인, 1단계 서브도메인 및 더 깊은 이름을 확인한 후 SAN 범위 또는 적절한 범위의 와일드카드를 사용하세요.
• DNS 레코드, CDN 호스트 이름, 로드 밸런서 리스너, 오리진 가상 호스트 및 인증서 할당을 일치된 상태로 유지하세요.
• DNS를 변경한 후 A 및 AAAA 경로를 모두 테스트하세요.
• 브라우저 경고가 표시되지 않는 것에만 의존하지 말고 공개 엔드포인트가 제공하는 인증서를 검사하세요.
• HTTPS를 종료하는 서비스를 기록하여 올바른 계층에서 인증서를 변경하도록 하세요.
• 필요한 모든 호스트 이름을 포함하는 인증서 갱신 및 배포 절차를 유지하세요.

자주 묻는 질문