NET::ERR_CERT_SYMANTEC_LEGACY: Chrome 해결

문제

Chrome이 연결이 비공개로 설정되어 있지 않습니다와 함께 NET::ERR_CERT_SYMANTEC_LEGACY 코드를 보여줍니다. 깔끔하게 넘어가는 우회 버튼도 없고, 새로고침해도 그대로입니다. 이건 만료 오류도, 이름 불일치도, 흔한 의미의 체인 문제도 아닙니다. 이 사이트의 인증서는 Symantec 인증기관 계층에서 발급됐고, Chrome은 그 계층 전체를 의도적으로 신뢰하지 않기로 했습니다. 브라우저는 당신의 인증서를 헷갈리는 게 아니라, 누가 서명했는지 정확히 알아보고 원칙적으로 거부하는 것입니다.

증상

• 전체 화면 경고에 NET::ERR_CERT_SYMANTEC_LEGACY가 표시됩니다 (Chrome·Edge).
• 인증서 날짜는 아직 유효합니다 — ERR_CERT_DATE_INVALID가 아닙니다.
• 발급 체인이 Symantec, Thawte, VeriSign, GeoTrust, RapidSSL로 거슬러 올라갑니다.
• Firefox나 Safari에서는 같은 사이트가 열리거나, 자체 불신 문구를 보여줄 수 있습니다.
• 캐시를 지우고 새로고침해도 오류가 남습니다 — 누가 발급했느냐의 속성이기 때문입니다.

이 오류의 진짜 의미

2017년 구글은 Symantec 인증기관 운영에 대한 긴 조사를 마무리하며, Symantec과 그 파트너들이 수년에 걸쳐 인증서를 잘못 발급해 왔다는 사실을 확인했습니다. 대응은 단호했습니다: Chrome은 Symantec PKI를 두 차례에 걸쳐 통째로 불신하겠다고 했습니다. 2016년 6월 1일 이전에 발급된 인증서는 2018년 4월 17일 안정판으로 나온 Chrome 66에서 신뢰를 잃었습니다. 남은 모든 Symantec 발급 인증서는 2018년 10월 16일 Chrome 70에서 신뢰를 잃었습니다.

Symantec의 인증서 사업은 2017년 말 DigiCert에 매각됐고, 그 전환 이후 DigiCert의 최신 인프라를 통해 발급된 인증서는 문제없습니다. NET::ERR_CERT_SYMANTEC_LEGACY가 콕 집어내는 건 여전히 옛 불신 Symantec 루트로 체인이 이어지는 인증서입니다. 2026년에 이걸 보고 있다면, 그 시절의 인증서가 어떻게든 아직 서비스 중이라는 뜻입니다 — 한 번도 교체 안 된 장수 인증서, 인증서가 박혀 나온 장비, 아무도 손대지 않은 내부 어플라이언스 같은 것들이죠.

핵심은 이겁니다: 같은 인증기관에서 갱신하거나 서버를 손봐서는 고칠 수 없습니다. 불신은 발급자를 겨냥하므로, 유일한 진짜 해결책은 Chrome이 아직 신뢰하는 CA에서 받은 인증서입니다.

가장 흔한 원인 3가지

1. 교체된 적 없는 Symantec 시절 장수 인증서 - 가장 흔한 경우입니다. 2018년 컷오프 이전에 발급돼 유효 기간이 몇 년짜리라 이제야 문제가 된 인증서, 또는 옛 체인을 계속 갱신해 온 자동화의 빈틈. 인증서는 진짜 Symantec 계열이고 Chrome은 보자마자 불신합니다.
2. Symantec인 줄 몰랐던 리셀러/브랜드 - Thawte, GeoTrust, RapidSSL 같은 브랜드가 Symantec 소속인 줄 모르고 구매한 경우. Chrome이 평가하는 건 판매점이 아니라 발급자 필드이고, 거기엔 Symantec이 보입니다.
3. 옛 인증서가 박힌 어플라이언스·로드밸런서·내부 서비스 - 네트워크 장비, 오래된 관리 인터페이스, 내부 도구가 Symantec 계열 인증서를 탑재하거나 그걸로 설정된 채 누구의 갱신 일정에도 오르지 못한 경우.

DechoNet으로 진단하기

• SSL 진단은 실제로 서빙 중인 인증서를 읽어 발급자와 전체 체인을 보여줍니다. 누가 서명했는지 보세요 — 체인에 Symantec, Thawte, VeriSign, GeoTrust, RapidSSL이 있으면 다른 게 아니라 불신이 원인임을 확인해 줍니다.
• HTTP 진단은 인증서 문제를 넘어선 뒤 엔드포인트가 응답하는지 확인합니다. TLS를 종단하는 모든 계층에 수정이 반영됐는지 검증할 때 유용합니다.

해결 체크리스트

• 디스크의 파일이 아니라 회선에서 발급자를 확인: echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -issuer -dates. 발급자에 Symantec, Thawte, VeriSign, GeoTrust, RapidSSL이 있으면 이게 불신입니다.
• 현재 신뢰받는 CA에서 재발급하세요. 이게 해결책입니다 — 같은 계열로 갱신하는 건 소용없습니다. Let’s Encrypt(무료), DigiCert, 또는 최신 공개 CA라면 Chrome이 신뢰하는 인증서를 발급합니다. 새 키와 CSR을 생성하세요.
• 새 인증서 와 전체 중간 체인을 함께 설치. 중간 인증서가 빠지면 Symantec 문제가 ERR_CERT_AUTHORITY_INVALID나 체인 오류로 바뀝니다 — 하나 고치고 다른 걸로 바꾸지 마세요.
• TLS를 종단하는 모든 계층을 리로드: 오리진 서버, 리버스 프록시, 로드밸런서, CDN 엣지. 한 계층만 옛 인증서가 남아도 일부 사용자에게 계속 불신 인증서가 나갑니다.
• SSL 진단을 다시 돌려 서빙되는 발급자가 최신 CA로 바뀌었는지 확인 — anycast나 CDN을 쓴다면 여러 지점에서.
• 자동 갱신을 설정해 교체본이 또 다른 잊힌 장수 인증서가 되지 않게 하세요.

에스컬레이션 시점

• 인증서가 직접 재발급할 수 없는 어플라이언스나 벤더 장비에 있다면, 펌웨어나 인증서 업데이트를 벤더에 요청하세요 — 출하 하드웨어에 박힌 불신 루트는 그들이 고칠 문제입니다.
• SSL 진단은 최신 발급자를 보여주는데 Chrome은 여전히 NET::ERR_CERT_SYMANTEC_LEGACY를 낸다면, 서빙되는 체인의 낡은 중간 인증서를 의심하세요: leaf는 재발급됐지만 번들이 아직 옛 Symantec 중간 인증서를 내보내는 경우입니다. 새 CA의 현행 중간 인증서로 체인을 다시 구성하세요.
• 회사 네트워크 뒤 기기에서만 오류가 뜬다면, TLS 검사 프록시가 옛 체인으로 재서명하고 있을 수 있습니다 — 이건 당신이 아니라 네트워크 운영자의 몫입니다.