NET::ERR_CERT_AUTHORITY_INVALID: 연결이 비공개로 설정되어 있지 않습니다 — 해결 방법

NET::ERR_CERT_AUTHORITY_INVALID란 무엇인가요?

NET::ERR_CERT_AUTHORITY_INVALID는 Chrome, Edge 또는 기타 Chromium 기반 브라우저가 웹사이트의 SSL 인증서에 서명한 인증 기관(CA)을 신뢰하지 않을 때 나타나는 브라우저 보안 오류입니다. 브라우저는 연결을 차단하고 "연결이 비공개로 설정되어 있지 않습니다" 경고를 표시하여 잠재적으로 사기성 웹사이트로부터 사용자를 보호합니다.

ERR_SSL_PROTOCOL_ERROR(TLS 핸드셰이크 자체가 실패했음을 의미)와 달리, ERR_CERT_AUTHORITY_INVALID는 핸드셰이크는 완료되었지만 인증서 검증 단계에서 실패했음을 의미합니다. 브라우저가 인증서를 받아 검사한 후 신뢰할 수 없다고 판단한 것입니다.

Chromium 내부 오류 코드는 net::ERR_CERT_AUTHORITY_INVALID(오류 코드 -202)입니다. 이 오류는 ERR_CERT_DATE_INVALID 및 ERR_SSL_VERSION_OR_CIPHER_MISMATCH와 같은 관련 오류가 포함된 인증서 오류군에 속합니다.

각 브라우저에서 ERR_CERT_AUTHORITY_INVALID가 표시되는 방식

브라우저마다 동일한 문제에 대해 다른 오류 메시지를 표시합니다. 무엇을 확인해야 하는지 알면 인증 기관 문제인지 다른 SSL 오류인지 진단하는 데 도움이 됩니다.

SSL 인증서 신뢰의 작동 방식 (신뢰 체인)

이 오류가 발생하는 이유를 이해하려면 브라우저가 SSL 인증서를 검증하는 방식을 알아야 합니다. 모든 인증서는 루트 인증 기관(CA)으로 이어지는 신뢰 체인의 일부입니다.

브라우저가 HTTPS를 통해 웹사이트에 연결하면, 서버는 SSL 인증서와 중간 인증서를 함께 전송합니다. 브라우저는 체인을 따라가며 확인합니다: 리프 인증서(웹사이트 인증서)가 중간 CA에 의해 서명되었는지, 그리고 중간 CA가 브라우저가 이미 신뢰하는 루트 CA에 의해 서명되었는지 확인합니다. 최신 브라우저와 운영 체제에는 DigiCert, Let's Encrypt(ISRG Root), Sectigo, GlobalSign 등의 기관에서 발급한 약 150개의 사전 설치된 루트 CA 인증서가 포함되어 있습니다.

이 체인의 어떤 링크라도 끊어지면(루트 CA가 없거나, 중간 인증서가 포함되지 않았거나, 서명 CA를 인식할 수 없는 경우) 브라우저는 ERR_CERT_AUTHORITY_INVALID를 표시합니다. 자세한 설명은 SSL 인증서 체인이란 가이드를 참조하세요.

• 루트 CA — 자체 서명, OS/브라우저 신뢰 저장소에 사전 설치 (약 150개의 신뢰된 루트)

• 중간 CA — 루트 CA가 서명, TLS 핸드셰이크 중 서버에서 전송해야 함

• 리프 인증서 — 웹사이트의 인증서, 중간 CA가 서명

• 검증 — 브라우저가 리프에서 루트까지 체인을 따라가며 모든 서명을 확인

NET::ERR_CERT_AUTHORITY_INVALID의 원인

이 오류에는 서버 측 원인(웹사이트의 문제)과 클라이언트 측 원인(사용자 기기의 문제) 모두 있습니다. 오류가 하나의 웹사이트에서만 나타나면 거의 확실히 서버 측 문제입니다. 여러 개 또는 모든 HTTPS 웹사이트에서 나타나면 사용자 측 문제입니다.

웹사이트 방문자를 위한 해결 방법 (클라이언트 측)

직접 관리하지 않는 웹사이트를 탐색하는 중 NET::ERR_CERT_AUTHORITY_INVALID가 표시되면 아래 해결 방법을 순서대로 시도하세요. 가장 빠른 확인부터 시작하세요 — 문제는 생각보다 단순한 경우가 많습니다.

해결법 1: 시스템 날짜 및 시간 확인

잘못된 시스템 시계는 인증서 오류의 가장 간과되는 원인 중 하나입니다. SSL 인증서에는 유효 기간(시작일과 만료일)이 있습니다. 기기가 실제로는 2026년인데 2020년이라고 인식하면, 2025년에 발급된 인증서가 "아직 유효하지 않음"으로 표시되어 브라우저가 거부합니다.

이 해결 방법은 10초밖에 걸리지 않으며 예상보다 자주 문제를 해결합니다 — 특히 BIOS 배터리 고장, 가상 머신 스냅샷 복원, 듀얼 부팅 시간 어긋남 이후에 효과적입니다.

# Windows — check and sync system time
w32tm /query /status
w32tm /resync

# macOS — enable automatic time sync
sudo sntp -sS time.apple.com

# Linux — sync with NTP
sudo timedatectl set-ntp true
timedatectl status

해결법 2: 시크릿/비공개 브라우징 모드 사용

시크릿 창에서 웹사이트를 열면 브라우저 캐시, 쿠키, 확장 프로그램 간섭을 한꺼번에 배제할 수 있습니다. 시크릿 모드에서 사이트가 정상적으로 로드되면, 문제는 캐시된 인증서 상태 또는 오작동하는 확장 프로그램이며 웹사이트 자체의 문제가 아닙니다.

시크릿 모드를 열려면: Chrome 또는 Edge에서 Ctrl+Shift+N, Firefox에서 Ctrl+Shift+P를 누르세요.

해결법 3: 브라우저 캐시 및 쿠키 삭제

브라우저는 후속 연결 속도를 높이기 위해 SSL 인증서 정보를 캐시합니다. 웹사이트가 최근에 인증서를 갱신하거나 교체한 경우, 서버에 유효한 인증서가 있음에도 브라우저가 여전히 이전(무효한) 인증서를 캐시에 보유하고 있어 ERR_CERT_AUTHORITY_INVALID 오류가 발생할 수 있습니다.

# Chrome: Clear cache via keyboard shortcut
# Windows/Linux: Ctrl+Shift+Delete
# macOS: Cmd+Shift+Delete
# Select "Cached images and files" and "Cookies" → Clear data

# Firefox: Clear cache
# Ctrl+Shift+Delete → select "Cache" and "Cookies" → Clear Now

해결법 4: SSL 상태 초기화 (Windows)

Windows는 브라우저 캐시와 별도로 OS 수준에서 별도의 SSL 인증서 캐시를 유지합니다. 이 캐시를 초기화하면 Windows가 인증서를 처음부터 다시 가져와 재검증합니다.

# Method 1: Via Internet Options
# Open Internet Options (inetcpl.cpl) → Content tab → "Clear SSL State" button

# Method 2: Via command line
# Open Command Prompt as Administrator:
certutil -URLcache * delete

해결법 5: 브라우저 확장 프로그램 비활성화

보안 확장 프로그램, VPN 확장, 광고 차단기, 개인 정보 보호 도구는 SSL 연결을 방해할 수 있습니다. 일부 확장 프로그램은 로컬 프록시로 작동하여 HTTPS 트래픽을 가로채고 인증서를 교체합니다 — 이것이 ERR_CERT_AUTHORITY_INVALID를 유발합니다.

테스트하려면 모든 확장 프로그램을 임시로 비활성화하세요: chrome://extensions/로 이동하여 각각을 끈 다음 웹사이트를 다시 로드합니다. 오류가 사라지면 확장 프로그램을 하나씩 다시 활성화하여 원인을 찾으세요.

해결법 6: OS 및 브라우저 업데이트

루트 CA 인증서는 OS 및 브라우저 업데이트를 통해 배포됩니다. 운영 체제가 오래된 경우 신뢰 저장소에 최신 루트 CA가 포함되지 않았을 수 있습니다. 예를 들어, ISRG Root X1 인증서(Let's Encrypt에서 사용)는 업데이트를 통해서만 이전 Android 및 Windows 버전에 추가되었습니다. Android 7.0 이하 기기에는 이 루트가 전혀 없을 수 있습니다.

Chrome과 Edge는 Windows와 macOS에서 OS 신뢰 저장소에 의존하는 반면, Firefox는 자체 저장소를 사용합니다. OS와 브라우저를 모두 최신 상태로 유지하면 최신 신뢰 루트 인증서를 확보할 수 있습니다.

해결법 7: 백신 프로그램 SSL/HTTPS 스캔 비활성화

Kaspersky, Avast, ESET, Bitdefender 같은 백신 소프트웨어에는 "HTTPS 스캔" 또는 "SSL 가로채기" 기능이 포함되어 있는 경우가 많습니다. 이 기능은 중간자(man-in-the-middle)로 작동합니다: 자체 인증서로 HTTPS 트래픽을 복호화하고, 검사한 다음 다시 암호화합니다. 백신 CA 인증서가 브라우저의 신뢰 저장소에 설치되어 있지 않으면 모든 HTTPS 사이트에서 ERR_CERT_AUTHORITY_INVALID가 표시됩니다.

테스트하려면: 백신 설정에서 HTTPS 스캔 기능을 일시적으로 비활성화합니다(백신 전체가 아닌 SSL/웹 스캔 구성 요소만). 오류가 사라지면 스캔을 비활성화 상태로 유지하거나 백신 루트 인증서를 브라우저에 다시 설치할 수 있습니다.

해결법 8: DNS 캐시 플러시

드문 경우지만, 오래된 DNS 캐시가 브라우저를 잘못된 IP 주소로 연결시킬 수 있습니다 — 다른(유효하지 않은) SSL 인증서를 제공하는 주소입니다. DNS를 플러시하면 기기가 도메인을 올바른 서버로 확인합니다. 전체 가이드는 DNS 캐시 플러시 방법을 참조하세요.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

# Chrome internal DNS cache
# Navigate to: chrome://net-internals/#dns → "Clear host cache"

해결법 9: 다른 네트워크 사용

회사 네트워크, 학교 Wi-Fi, 일부 공용 핫스팟은 HTTPS 연결을 가로채는 투명 프록시를 사용합니다. 이러한 프록시는 웹사이트의 SSL 인증서를 자체 인증서로 교체하여 ERR_CERT_AUTHORITY_INVALID를 유발합니다. 모바일 데이터나 다른 Wi-Fi 네트워크로 전환하면 네트워크가 문제인지 확인할 수 있습니다.

직장이나 학교 네트워크에서만 오류가 나타나면 네트워크 관리자에게 문의하세요 — 프록시의 루트 인증서를 기기에 설치하거나, 해당 도메인을 SSL 검사에서 제외해야 할 수 있습니다.

웹사이트 소유자를 위한 해결 방법 (서버 측)

방문자가 웹사이트에서 ERR_CERT_AUTHORITY_INVALID를 보고하고 있다면, 문제는 SSL 인증서 구성에 있습니다. 다음은 가장 흔한 것부터 순서대로 정리한 서버 측 해결 방법입니다.

해결법 1: 신뢰할 수 있는 CA의 인증서 설치

자체 서명 인증서는 웹사이트 소유자에게 ERR_CERT_AUTHORITY_INVALID의 1순위 원인입니다. OpenSSL 또는 유사한 도구로 자체 인증서를 생성한 경우, 브라우저는 이를 절대 신뢰하지 않습니다 — 서명 기관(본인)이 어떤 브라우저의 신뢰 저장소에도 없기 때문입니다.

해결 방법은 공개적으로 신뢰할 수 있는 인증 기관의 인증서를 설치하는 것입니다. Let's Encrypt는 모든 주요 브라우저가 신뢰하는 무료 자동화 인증서를 제공합니다. 상용 사이트의 경우 DigiCert, Sectigo, GlobalSign의 유료 인증서가 확장 검증(EV)과 더 긴 유효 기간을 제공합니다.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

해결법 2: 완전한 인증서 체인 설치

중간 인증서 누락은 서버 측에서 두 번째로 흔한 원인입니다. SSL 인증서가 완전히 유효하더라도 서버가 중간 CA 인증서를 함께 전송하지 않으면, 브라우저가 신뢰 체인을 검증할 수 없어 ERR_CERT_AUTHORITY_INVALID를 표시합니다.

DNS Robot의 SSL Checker를 사용하여 인증서 체인을 확인하세요. 정상적인 체인은 세 개의 인증서를 표시합니다: 루트 CA > 중간 CA > 귀하의 인증서. 중간 인증서가 누락된 경우 전체 체인을 전송하도록 서버를 구성해야 합니다.

# Check your certificate chain with OpenSSL
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E 's:|i:'

# Expected output (3 certificates in chain):
# s:CN = example.com          (your cert)
# i:CN = R11                   (intermediate - Let's Encrypt)
# s:CN = R11
# i:CN = ISRG Root X1          (root CA)

# Nginx — configure full chain
# ssl_certificate should point to the fullchain file, not just the cert:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache — configure full chain
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

해결법 3: 만료된 인증서 갱신

만료된 인증서는 모든 브라우저에서 즉시 거부됩니다. Chrome은 만료된 인증서의 중간 CA도 교체된 경우 ERR_CERT_DATE_INVALID 대신 ERR_CERT_AUTHORITY_INVALID를 표시할 수 있습니다. SSL Checker 또는 명령줄로 인증서 만료일을 확인하세요.

# Check certificate expiry date
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# Output:
# notBefore=Jan  1 00:00:00 2026 GMT
# notAfter=Apr  1 00:00:00 2026 GMT

# Force renewal with Certbot
sudo certbot renew --force-renewal

# Restart web server after renewal
sudo systemctl reload nginx    # Nginx
sudo systemctl reload apache2  # Apache

해결법 4: 인증서가 도메인과 일치하는지 확인

SSL 인증서는 CN(Common Name) 및 SAN(Subject Alternative Name) 필드에 나열된 특정 도메인 이름에 대해 발급됩니다. 웹사이트가 www.example.com으로 접속되지만 인증서가 example.com만 포함하거나, SAN에 포함되지 않은 하위 도메인으로 접속하면 Chrome이 ERR_CERT_AUTHORITY_INVALID를 표시할 수 있습니다.

와일드카드 인증서(*.example.com)는 모든 하위 도메인을 포함하지만, SAN에 명시적으로 나열되지 않은 한 루트 도메인은 포함하지 않습니다. 와일드카드 인증서를 생성할 때 항상 example.com과 *.example.com을 모두 포함하세요.

해결법 5: 서버 TLS 구성 확인

잘못된 TLS 설정은 유효한 인증서가 있어도 인증서 신뢰 문제를 일으킬 수 있습니다. 서버가 TLS 1.2와 TLS 1.3을 지원하는지 확인하세요 — TLS 1.0과 1.1 같은 이전 프로토콜은 2020년 이후 모든 주요 브라우저에서 지원이 중단되었습니다. 또한 서버가 올바른 순서로 인증서를 전송하는지 확인하세요(리프 먼저, 그다음 중간 인증서).

# Nginx recommended TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

# Test your TLS configuration
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

Localhost에서 ERR_CERT_AUTHORITY_INVALID 발생 시 (개발자용)

개발자는 로컬 HTTPS 서버를 실행할 때 이 오류를 자주 겪습니다. localhost 인증서는 항상 자체 서명이므로 Chrome이 기본적으로 차단합니다. 이를 처리하는 몇 가지 방법이 있습니다.

• mkcert — 가장 간단한 해결책. mkcert를 설치하고, mkcert -install을 실행하여 로컬 CA를 신뢰 저장소에 추가한 다음 인증서를 생성합니다: mkcert localhost 127.0.0.1 ::1. Chrome, Firefox, Edge에서 자동으로 신뢰됩니다

• Chrome 우회 — 오류 페이지에서 thisisunsafe를 입력합니다(입력 필드 없이 키보드로 직접 입력). 현재 세션에서만 경고를 우회합니다

• Chrome 플래그 — chrome://flags/#allow-insecure-localhost로 이동하여 활성화합니다. localhost에 대한 인증서 오류만 억제합니다

• Vite/Next.js/Webpack — 대부분의 개발 서버는 자체 서명 인증서를 생성하는 --https 플래그를 지원합니다. mkcert와 결합하여 신뢰할 수 있는 로컬 환경을 구축할 수 있습니다

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

관련 SSL 인증서 오류

NET::ERR_CERT_AUTHORITY_INVALID는 발생할 수 있는 여러 SSL 인증서 오류 중 하나에 불과합니다. 각 오류는 인증서 검증 과정에서 서로 다른 문제를 가리킵니다.