이 오류가 정확히 말하는 것

NET::ERR_CERT_COMMON_NAME_INVALID는 접속한 이름과 서버가 보낸 인증서의 이름이 맞지 않는다는 오류입니다. 이 오류만으로 인증서의 다른 부분이 정상이라고 판단할 수는 없습니다. 발급자·유효 기간·인증서 체인도 확인하세요. 한 인증서에 여러 문제가 함께 있을 수 있습니다.

오류 이름은 옛 흔적입니다. 예전 브라우저는 주소를 인증서의 Common Name(CN)과 비교했습니다. 크롬 58(2017년)부터는 SAN(Subject Alternative Name) 목록만 봅니다. RFC 2818이 2000년부터 권고해 온 방식입니다. 같은 문제를 파이어폭스는 SSL_ERROR_BAD_CERT_DOMAIN으로, 사파리는 “호스트 이름 불일치”로 보여 줍니다.

그래서 진단은 두 질문으로 끝납니다.

  1. 브라우저가 접속하는 이름이 정확히 무엇인가? (www.example.com과 example.com은 서로 다른 이름입니다.)
  2. 그 이름으로 접속했을 때 실제로 돌아오는 인증서에는 어떤 이름들이 들어 있나?

1단계: 서버가 실제로 보내는 SAN 목록 읽기

서버에 있는 인증서 파일이나 CDN 대시보드를 믿지 마세요. 실패하는 바로 그 이름으로, 실제 접속에서 오가는 인증서를 읽어야 합니다.

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

-servername이 중요합니다. 브라우저가 보내는 “어느 사이트를 원하는지” 힌트(SNI)를 함께 보냅니다. 이것이 없으면 많은 서버가 기본 인증서를 돌려주고, 엉뚱한 인증서를 붙잡고 진단하게 됩니다.

크롬에서는 주소창의 “주의 요함” → “인증서가 유효하지 않음” → 세부정보 → Subject Alternative Name에서 볼 수 있습니다.

SSL 점검은 어떤 호스트명이든 우리 네트워크 밖에서 SAN 목록과 발급자를 보여 줍니다.

SAN 목록과 주소창의 이름을 한 글자씩 비교하세요. 실제로는 거의 언제나 아래 경우 중 하나입니다.

흔한 원인

1. www와 루트 도메인이 둘 다 들어 있지 않음

인증서는 example.com만 담고 있는데 방문자가 www.example.com으로 들어오거나, 그 반대인 경우입니다. 인증서를 신청할 때 -d를 하나만 주면 이런 불일치가 생길 수 있습니다.

해결: 두 이름을 모두 넣어 재발급합니다. certbot이라면:

certbot --expand -d example.com -d www.example.com

둘 중 하나만 쓰고 싶어도 인증서에는 둘 다 넣고, 한쪽에서 다른 쪽으로 리다이렉트하세요. 리다이렉트는 TLS 연결이 성공한 뒤에야 일어나므로, 리다이렉트를 하는 쪽 이름에도 유효한 인증서가 필요합니다.

2. 와일드카드가 닿지 않는 이름

*.example.com은 www.example.com, shop.example.com을 커버합니다. example.com 자체와 dev.shop.example.com은 커버하지 않습니다. * 하나는 이름 한 단계만 대신합니다.

해결: 루트 도메인을 따로 넣으세요. Let’s Encrypt를 포함해 대부분의 CA는 example.com과 *.example.com을 한 인증서에 담아 줍니다. 더 깊은 이름은 *.shop.example.com이나 개별 호스트명을 추가합니다.

Cloudflare 사용자가 자주 겪습니다. 무료 Universal SSL 인증서는 example.com과 *.example.com만 커버하므로, 프록시로 켠 dev.shop.example.com 같은 레코드에서는 정확히 이 오류가 납니다. 그 단계를 포함하는 Advanced Certificate가 필요하거나, 그 레코드를 DNS 전용으로 바꿔 원 서버가 자기 인증서를 내게 해야 합니다.

3. 이름이 그 이름을 모르는 서버를 가리킴

DNS 레코드가 가리키는 서버에 이 이름으로 설정된 사이트가 없는 경우입니다. 서버는 기본 인증서로 응답합니다. 호스팅 회사 자체의 인증서, 알파벳순으로 첫 번째 가상 호스트의 인증서, 또는 임시 인증서입니다.

이런 때 자주 생깁니다.

  • DNS를 새 호스팅으로 바꿨는데 새 호스팅의 관리 화면에 도메인을 아직 추가하지 않았을 때
  • 공유 IP의 가상 호스트 설정에 example.com은 있지만 www.example.com은 없을 때
  • nginx에서 server_name이 맞는 블록이 없어 그 포트의 첫 번째 server 블록이 응답할 때

DNS 조회로 이름이 어디를 가리키는지 확인한 뒤, 1단계에서 본 발급 대상(subject)과 발급자를 보세요. 인증서가 다른 회사나 다른 고객의 사이트 것이라면 이 경우입니다.

해결: 그 서버의 사이트 설정에 호스트명을 추가하고(server_name, ServerAlias, 관리 화면의 ‘도메인 추가’), 그 이름으로 인증서를 발급받습니다.

4. SaaS로 CNAME을 걸었는데 서비스 쪽에 도메인을 등록하지 않음

docs.example.com을 yourname.github.io, something.herokuapp.com, Shopify, Vercel·Netlify 프로젝트로 CNAME해 둔 경우입니다. 서비스 쪽에 docs.example.com을 사용자 도메인으로 등록하지 않았기 때문에, 서비스의 엣지가 자기 도메인 인증서(*.github.io)로 응답합니다.

해결: 서비스 설정에서 사용자 도메인을 추가하고 인증서 발급을 기다립니다. 대부분 DNS 레코드가 먼저 있어야 하고, 발급까지 몇 분 걸립니다.

5. IP 주소나 내부 이름으로 접속

https://203.0.113.10이나 https://intranet으로 접속하면 example.com 인증서와는 당연히 맞지 않습니다. 공인 CA는 2015년 CA/브라우저 포럼 규칙에 따라 내부 이름이나 사설 IP 대역으로는 인증서를 아예 발급하지 않습니다.

해결: 실제 호스트명으로 접속하세요. 내부 서비스는 내가 가진 도메인 아래 이름(intranet.corp.example.com)을 쓰고, 그 이름의 공인 인증서나 기기들이 신뢰하는 내부 CA를 씁니다. 로컬 개발에는 mkcert가 localhost와 원하는 이름으로 로컬에서 신뢰되는 인증서를 만들어 줍니다.

6. 사용자의 네트워크에서 다른 무언가가 대신 응답

오류가 특정 와이파이, 특정 사무실, 특정 노트북에서만 나고 인증서 발급자가 처음 보는 회사라면, 원인은 사용자와 서버 사이에 있습니다.

  • 캡티브 포털(호텔·공항)은 로그인 전 첫 HTTPS 요청을 가로챕니다.
  • 회사의 TLS 검사 프록시는 트래픽을 자기 인증서로 다시 서명합니다. 회사 기기에는 그 루트가 설치돼 있지만 개인 기기에는 없습니다.
  • 백신의 ‘HTTPS 검사’도 한 기기 안에서 같은 일을 합니다.

이 경우 서버는 정상입니다. 사용자 네트워크를 거치지 않는 바깥에서 SSL 점검을 돌려 비교해 보세요.

7. 예전 DNS 응답이 어딘가에 남아 있음

사이트를 옮겼고 새 서버에는 올바른 인증서가 있습니다. 그런데 일부 사용자는 여전히 예전 서버로 가고, 예전 서버에는 이 이름의 인증서가 없습니다. TTL, 통신사 리졸버, 운영체제 캐시가 예전 IP를 몇 시간 동안 들고 있을 수 있습니다. 예전 TTL이 길었다면 더 오래갑니다.

전파 확인으로 공용 리졸버들이 아직 예전 주소를 내주는지 보세요. 모두 새 주소로 맞춰질 때까지는 예전 서버도 유효한 인증서로 응답하게 두세요.

고친 다음에

  • 사람들이 실제로 쓰는 모든 이름을 다시 확인하세요. 루트, www, 링크나 메일에 들어 있는 서브도메인까지, 이름마다 따로 확인해야 합니다.
  • 재발급했다면 서버가 예전 인증서가 아니라 새 인증서를 내보내는지 확인하세요. nginx나 Apache를 리로드하고, CDN에도 반영됐는지 봅니다.
  • 이 문제를 갱신 작업이 만들었다면 그 작업의 도메인 목록을 확인하세요. 자동 갱신은 처음 신청할 때의 이름을 그대로 다시 씁니다. 그래서 나중에 사이트에 추가한 이름은 인증서에 들어가지 못합니다.

비슷해 보이는 다른 오류

  • NET::ERR_CERT_DATE_INVALID: 이름은 맞지만 만료됐거나 아직 유효 기간 전입니다. 기기 시계가 틀린 경우도 많습니다.
  • NET::ERR_CERT_AUTHORITY_INVALID: 이름은 맞을 수 있지만 발급자를 신뢰할 수 없습니다. 자체 서명 인증서이거나 중간 인증서가 빠진 경우입니다.
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH: 인증서를 비교하기도 전에 TLS 핸드셰이크가 실패합니다. CDN에서는 그 이름의 인증서가 아예 없다는 뜻인 경우가 많습니다.

내 도메인에서 바로 확인

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