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

NET::ERR_CERT_AUTHORITY_INVALID란 무엇인가요?

NET::ERR_CERT_AUTHORITY_INVALID는 웹사이트 인증서를 발급한 기관을 브라우저가 신뢰하지 않는다는 뜻입니다. Chrome은 "연결이 비공개로 설정되어 있지 않습니다"라고 표시하고, 고급을 누르면 "이 서버가 example.com임을 입증할 수 없으며" 보안 인증서를 신뢰할 수 없다고 설명한 뒤 "서버를 잘못 설정했거나 불법 사용자가 연결을 가로채고 있기 때문일 수 있습니다"라고 덧붙입니다. Chromium은 이 오류를 -202번으로 분류합니다(net_error_list.h).

연결은 이루어졌고 서버도 인증서를 보냈지만, 브라우저가 그 인증서를 자신이 신뢰하는 인증 기관(CA)과 연결 짓지 못한 것입니다. Chromium 소스의 설명은 세 가지 경우를 듭니다. 공격자가 인증서를 바꿔치기했거나, 사이트가 브라우저가 모르는 CA를 쓰거나, 인증서가 자체 서명된 경우입니다.

인증서에 문제가 여러 개 있으면 Chrome은 가장 심각한 것 하나만 보여 주며, 신뢰할 수 없는 발급자는 이름 불일치나 만료보다 우선합니다. 그래서 자체 서명 인증서가 만료까지 되었다면 ERR_CERT_DATE_INVALID가 아니라 이 코드가 표시됩니다.

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

브라우저마다 표현이 다릅니다. 다음 문구를 찾아보세요.

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

모든 인증서는 브라우저가 이미 신뢰하는 루트 인증 기관에서 끝나는 신뢰 체인의 일부입니다.

접속하면 서버는 자신의 인증서와 함께 하나 이상의 중간 인증서를 보냅니다. 브라우저는 사이트 인증서가 중간 인증서로 서명되었는지, 중간 인증서가 자신의 목록에 있는 루트로 서명되었는지 확인합니다. Chrome은 이 확인에 더 이상 운영 체제의 목록을 쓰지 않습니다. Windows와 macOS에서는 Chrome 108부터, Android에서는 Chrome 115부터 자체 목록인 Chrome Root Store를 내장하고 있습니다(Apple의 목록을 써야 하는 iPhone과 iPad는 예외). 이 목록에는 약 100개의 루트가 있으며 백그라운드에서 업데이트됩니다(Chrome Root Store). Windows와 macOS의 Edge는 Microsoft의 목록을, Firefox는 Mozilla의 목록을 내장하며, 모두 사용자나 회사가 컴퓨터에 추가한 루트도 신뢰합니다.

어느 고리든 빠지거나 알 수 없으면 이 오류가 납니다(자세한 내용은 SSL 인증서 체인이란 참고). 체인은 네 부분으로 이루어집니다.

• 루트 CA — 자체 서명되어 있으며 브라우저의 루트 목록에 내장되어 있습니다
• 중간 CA — 루트가 서명하며, 서버가 반드시 함께 보내야 합니다. Chrome은 빠진 중간 인증서를 인증서에 적힌 주소에서 직접 내려받지만, curl, 앱 등 많은 클라이언트는 그러지 못합니다
• 사이트 인증서 — 중간 CA가 서명하며, Subject Alternative Name 목록에 있는 이름에 대해 발급됩니다
• 검증 — 브라우저가 사이트 인증서에서 신뢰하는 루트까지 거슬러 올라가며, 모든 서명이 맞아야 합니다

NET::ERR_CERT_AUTHORITY_INVALID의 원인

어디에서 보이는지로 원인을 좁힐 수 있습니다. 한 웹사이트에서만 뜬다면 거의 항상 그 사이트의 인증서 문제입니다. 모든 HTTPS 사이트에서 뜬다면 내 기기나 네트워크 문제입니다.

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

직접 운영하지 않는 사이트에서 이 오류가 보인다면 아래 순서대로 시도하세요. 이 경고가 표시된 페이지에는 절대 비밀번호나 카드 번호를 입력하지 마세요.

해결법 1: Wi-Fi에 로그인하거나 다른 네트워크로 시도

호텔, 공항, 카페 Wi-Fi는 로그인 페이지를 보여 주려고 처음 몇 번의 연결을 가로채는 경우가 많고, 그러면 HTTPS 사이트에는 사이트 자신의 인증서 대신 네트워크의 인증서가 전달됩니다. Chrome 도움말에 따르면 이런 네트워크에서는 로그인해야 하며, http://를 쓰는 페이지에 접속하면 로그인 페이지가 열립니다. Chrome은 이 오류 대신 "Wi-Fi 연결" 페이지를 보여 줄 수도 있습니다. 로그인을 마친 뒤 새로고침하세요.

회사나 학교 네트워크도 자체 인증서로 HTTPS를 검사할 수 있습니다. 모바일 데이터에서는 오류가 사라진다면 그 네트워크의 IT 담당자에게 문의하세요. 관리 대상 기기에는 보통 그 루트 인증서가 설치되어 있지만, 내 기기에는 없을 수 있습니다.

해결법 2: 백신의 HTTPS 검사 확인

Kaspersky, Avast, ESET, Bitdefender 같은 백신 제품은 자체 인증서로 HTTPS를 복호화해 검사한 뒤 다시 암호화할 수 있습니다. 그 루트 인증서를 브라우저가 신뢰하지 않거나 업데이트 후 이 기능이 고장 나면, 모든 HTTPS 사이트에서 한꺼번에 이 오류가 납니다.

테스트하려면 HTTPS 검사나 웹 검사 기능만 일시 중지하고 새로고침하세요. 오류가 사라지면 백신을 복구하거나 업데이트해 인증서를 다시 설치하게 하거나, HTTPS 검사를 꺼 두세요.

해결법 3: 브라우저와 운영 체제 업데이트

브라우저와 운영 체제는 루트 목록을 정기적으로 업데이트하며(Chrome은 백그라운드 구성 요소 업데이트로), 오래된 시스템에는 새 루트가 빠져 있습니다. 예를 들어 7.1.1보다 오래된 Android는 ISRG Root X1을 신뢰하지 않으므로, 시스템 목록에 의존하는 브라우저와 앱에서는 Let's Encrypt 사이트가 열리지 않습니다.

먼저 브라우저를 업데이트하세요. Windows와 macOS의 Chrome과 Edge는 자체 루트 목록을 갖고 있고, Android의 Chrome도 버전 115부터 그렇습니다. 그다음 운영 체제를 업데이트하세요.

해결법 4: 날짜와 시간 확인

시계가 몇 달이나 몇 년씩 틀어져 있으면 인증서가 아직 유효하지 않거나 만료된 것처럼 보입니다. 이때 Chrome은 보통 별도의 경고("시간이 너무 먼 과거로 설정되어 있습니다" 또는 ERR_CERT_DATE_INVALID)를 보여 주지만, CMOS 배터리가 방전되었거나 가상 머신을 복원한 뒤처럼 시계가 크게 틀어지면 신뢰 확인까지 깨질 수 있습니다. 10초면 확인할 수 있습니다.

Windows: 설정 → 시간 및 언어 → 날짜 및 시간 → 자동으로 시간 설정 켜기. macOS: 시스템 설정 → 일반 → 날짜 및 시간 → 자동으로 시간 및 날짜 설정. Android: 설정 → 시스템 → 날짜 및 시간 → 자동으로 시간 설정 (Android 16에서는 날짜 및 시간 자동 설정).

해결법 5: 시크릿 모드로 시도한 뒤 브라우저 다시 시작

시크릿 창(Chrome과 Edge는 Ctrl+Shift+N, Firefox의 사생활 보호 창은 Ctrl+Shift+P)에서는 직접 허용하지 않은 확장 프로그램이 실행되지 않습니다. VPN·프록시 확장 프로그램은 자체 인증서를 제시하는 서버를 거쳐 트래픽을 보낼 수 있습니다. 시크릿 모드에서 사이트가 열린다면 chrome://extensions에서 확장 프로그램을 모두 끈 다음 하나씩 다시 켜 보세요.

사이트가 방금 인증서를 고쳤다면 브라우저 창을 모두 닫았다가 다시 열어, 브라우저가 새 인증서를 처음부터 다시 확인하게 하세요.

해결법 6: Android에서 해결하기

Android에는 따로 확인할 것이 몇 가지 있습니다.

• 날짜와 시간 자동 설정: 설정 → 시스템 → 날짜 및 시간 → "날짜 및 시간 자동 설정".
• Chrome과 Android System WebView 업데이트: Play 스토어에서 업데이트하세요. WebView로 웹 페이지를 보여 주는 앱은 Android 자체의 루트 목록으로 인증서를 확인하므로, 오래된 Android 버전에서는 여전히 실패할 수 있습니다.
• HTTPS를 필터링하는 VPN, 광고 차단, '안전 브라우징' 앱 끄기: 이런 앱이 켜져 있으면 상태 표시줄에 열쇠나 VPN 아이콘이 보입니다.
• Wi-Fi에 로그인: 공용 네트워크는 로그인 페이지에서 동의하기 전까지 이 오류를 보여 줍니다.
• 7.1.1보다 오래된 Android에서는 Let's Encrypt의 루트가 시스템 목록에 없으므로, 그 목록에 의존하는 앱과 브라우저는 해당 사이트를 검증할 수 없습니다. 자체 루트 목록을 갖춘 브라우저를 쓰는 것이 유일한 우회 방법입니다.

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

방문자들이 내 사이트에서 NET::ERR_CERT_AUTHORITY_INVALID가 뜬다고 알려 온다면, 대개 서버가 제공하는 인증서가 공개 루트까지 이어지지 않는 것입니다. 먼저 SSL 검사 도구로 확인한 뒤 발견된 문제를 고치세요. 설치한 것과 다른 인증서가 보인다면 DNS 조회로 도메인이 생각한 서버를 가리키는지, HTTP 헤더 검사로 어떤 서버가 응답하는지 확인하세요.

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

자체 서명 인증서나 자체 CA에서 발급한 인증서는 방문자의 브라우저에서 절대 신뢰받지 못합니다. 서명한 주체가 어떤 공개 루트 목록에도 없기 때문입니다.

대신 공개적으로 신뢰받는 CA의 인증서를 설치하세요. Let's Encrypt는 모든 주요 브라우저가 신뢰하는 무료 자동화 인증서를 발급하고, DigiCert, Sectigo, GlobalSign은 조직 검증과 기술 지원이 포함된 인증서를 판매합니다.

# 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: 완전한 인증서 체인 보내기

인증서 자체는 완벽하게 유효한데 서버가 중간 인증서를 빠뜨릴 수 있습니다. Chrome은 빠진 중간 인증서를 직접 내려받아 이 문제를 가려 주는 경우가 많아서, 사이트가 Chrome에서는 열리지만 curl, 앱, 결제 콜백, 일부 휴대폰에서는 실패합니다.

DNS Robot의 SSL Checker로 사이트를 검사하면 서버가 보내는 체인과, Mozilla, Chrome, Apple, Microsoft가 각각 그 체인을 신뢰하는지 보여 줍니다. 터미널에서 확인할 수도 있습니다.

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

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

신뢰할 수 있는 CA의 인증서가 만료되면 이 오류가 아니라 ERR_CERT_DATE_INVALID가 표시됩니다. Chrome은 더 심각한 문제를 보고하므로, 체인까지 신뢰할 수 없을 때만 ERR_CERT_AUTHORITY_INVALID가 보입니다. 어느 쪽이든 날짜를 확인하고 갱신하세요.

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

해결법 4: 방문자가 쓰는 모든 이름 포함하기

신뢰할 수 있는 인증서라도 주소창의 이름이 들어 있지 않으면 대신 ERR_CERT_COMMON_NAME_INVALID가 표시됩니다. 인증서까지 신뢰할 수 없을 때만 이 오류로 바뀌므로, 신뢰 문제를 먼저 고친 다음 이름을 고치세요.

브라우저는 예전의 Common Name이 아니라 Subject Alternative Name 목록만 확인합니다. 와일드카드(*.example.com)는 한 단계의 하위 도메인만 포함하고 example.com 자체는 포함하지 않으므로, 인증서를 신청할 때 둘 다 넣으세요. SSL 검사 도구에서 인증서에 포함된 이름 전체를 볼 수 있습니다.

해결법 5: 사설 CA나 회사 CA를 쓰는 경우

사내 사이트는 일부러 회사 CA를 쓰는 경우가 많습니다. 이 방식은 회사의 루트 인증서가 설치된 기기에서만 작동하며, Chrome과 Edge는 Windows나 macOS에 추가된 루트를 신뢰합니다(Chrome Root Store FAQ). 그룹 정책이나 기기 관리 도구로 배포하거나, 아래 명령으로 직접 추가하세요.

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

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

자체 서명 인증서를 쓰는 로컬 HTTPS 서버에서는 이 오류가 나는 것이 정상입니다. 경고를 클릭해 넘기지 말고, 내 컴퓨터에서 인증서를 신뢰하도록 만드세요.

• mkcert — mkcert -install은 로컬 CA를 만들어 시스템의 신뢰 저장소에 추가합니다(NSS의 certutil이 설치되어 있으면 Firefox에도). 그다음 mkcert localhost 127.0.0.1 ::1을 실행하면 Chrome, Edge, Firefox가 신뢰하는 인증서가 만들어집니다
• Next.js — next dev --experimental-https가 mkcert로 로컬에서 신뢰되는 인증서를 대신 만들어 줍니다
• Vite — @vitejs/plugin-basic-ssl은 신뢰되지 않는 인증서를 만들기 때문에 이 오류가 계속 보입니다. 대신 server.https가 mkcert의 파일을 가리키게 하세요
• 더 이상 통하지 않는 옛 방법 — chrome://flags/#allow-insecure-localhost 스위치는 Chrome 130 이후 만료되어 chrome://flags에서 사라졌습니다

# 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는 Chrome의 "연결이 비공개로 설정되어 있지 않습니다" 페이지에 나오는 여러 인증서 오류 중 하나입니다. 코드마다 가리키는 검사가 다릅니다.