구글크롬 Localhost SSL 보안경고 비활성화 알림 끄는방법
크롬 localhost SSL 보안 경고 해결｜Chrome 플래그 대신 mkcert 로컬 HTTPS 인증서 설정
로컬 개발 환경에서 https://localhost, https://127.0.0.1, 또는 hosts 파일에 등록한 테스트 주소로 접속했을 때 크롬이 연결이 비공개로 설정되어 있지 않습니다라는 보안 경고를 표시하는 경우가 있습니다.
대표적으로 NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_DATE_INVALID 같은 인증서 오류가 나타나며, 예전에는 Chrome flags에서 경고를 무시하는 방법이 많이 사용됐습니다.
하지만 현재는 보안 경고를 브라우저에서 끄는 방식보다, 로컬 환경에 신뢰할 수 있는 개발용 인증서를 설치하는 방식이 훨씬 안정적입니다. 특히 OAuth 로그인, HTTP/2, API 테스트, PWA, 사용자 지정 로컬 도메인, 실제 운영 환경과 동일한 HTTPS 동작을 점검해야 한다면 인증서 설정이 필요합니다.
핵심 요약
일반적인 로컬 개발은 http://localhost만으로도 충분한 경우가 많습니다. 다만 HTTPS 전용 API, HTTP/2, OAuth, 사용자 지정 도메인, 운영 환경과 동일한 쿠키·보안 정책 테스트가 필요하다면 Chrome 경고를 무시하지 말고 mkcert로 로컬 신뢰 인증서를 만들어 사용하는 것이 정석입니다.
Google web.dev 로컬 HTTPS 안내 mkcert 로컬 HTTPS 설정 방법
localhost에서 SSL 보안 경고가 뜨는 이유
브라우저는 인증서 발급자와 접속 주소를 함께 확인합니다
HTTPS 접속 시 브라우저는 서버가 보내는 인증서를 확인합니다. 이때 인증서를 발급한 기관이 신뢰할 수 있는지, 접속한 도메인과 인증서의 이름이 같은지, 인증서 유효기간이 남아 있는지 등을 검사합니다.
로컬 개발 서버는 대부분 직접 만든 자체 서명 인증서(Self-signed Certificate)를 사용합니다. 이 인증서는 공인 인증기관이 발급한 인증서가 아니기 때문에 크롬이 신뢰하지 못하고 경고를 표시합니다.
| 오류 코드 | 주요 원인 | 확인할 부분 |
|---|---|---|
| NET::ERR_CERT_AUTHORITY_INVALID | 브라우저가 인증서 발급자를 신뢰하지 않음 | 자체 서명 인증서, 로컬 CA 미설치 여부 |
| NET::ERR_CERT_COMMON_NAME_INVALID | 인증서의 도메인과 접속 주소가 다름 | localhost 인증서로 127.0.0.1 또는 mysite.test 접속 여부 |
| NET::ERR_CERT_DATE_INVALID | 인증서 만료 또는 PC 시간 오류 | 윈도우 날짜·시간·표준 시간대, 인증서 만료일 |
| ERR_SSL_PROTOCOL_ERROR | HTTPS 서버 설정 또는 프로토콜 불일치 | 서버 포트, 인증서 경로, HTTP 포트에 HTTPS 접속했는지 확인 |
| ERR_CONNECTION_REFUSED | 서버가 실행되지 않음 또는 포트 차단 | 개발 서버 실행 여부, 포트 번호, 방화벽 설정 |
localhost와 127.0.0.1은 같은 주소처럼 보여도 인증서는 다르게 판단할 수 있습니다
localhost와 127.0.0.1은 모두 내 컴퓨터를 가리키는 루프백 주소이지만, 인증서 이름 검사에서는 서로 다른 값으로 판단될 수 있습니다.
예를 들어 인증서를 localhost 이름으로만 만들고, 브라우저에서 https://127.0.0.1:3000으로 접속하면 주소 불일치 오류가 발생할 수 있습니다. 따라서 로컬 HTTPS 인증서를 만들 때는 실제로 사용할 주소를 함께 등록하는 것이 좋습니다.
먼저 확인할 점｜http://localhost만으로 충분한 경우
로컬 개발이라고 해서 무조건 HTTPS를 사용할 필요는 없습니다. http://localhost는 일반적인 외부 HTTP 사이트와 달리 브라우저에서 특수하게 취급됩니다. 따라서 로컬 개발 중에는 서비스 워커, 인증 관련 API, 일부 센서 API 등 보안 컨텍스트가 필요한 기능도 대부분 정상적으로 테스트할 수 있습니다.
http://localhost를 우선 사용해도 되는 상황
- 단순한 HTML, CSS, JavaScript 화면 개발
- 로컬 API 호출과 데이터 처리 테스트
- React, Vue, Next.js, Vite 등 개발 서버의 일반 기능 점검
- Service Worker와 PWA 기본 동작 확인
- 내 PC에서만 사용하는 테스트 페이지
- localhost 또는 127.0.0.1 주소로만 접속하는 환경
HTTPS가 필요한 대표 상황
- HTTP/2 또는 HTTP/3 기반 동작을 실제처럼 테스트해야 하는 경우
- OAuth 로그인, 외부 인증 서비스, 결제 API처럼 HTTPS를 요구하는 서비스를 연동하는 경우
- 혼합 콘텐츠(Mixed Content) 오류를 운영 환경과 동일하게 재현해야 하는 경우
- mysite.test, dev.company.test처럼 사용자 지정 로컬 도메인을 사용하는 경우
- 운영 사이트의 HTTPS 쿠키, 리디렉션, CSP, CORS, 보안 헤더 동작을 정확히 검증해야 하는 경우
- 개발 서버를 다른 기기에서 접속하거나 HTTPS 기반 프록시와 연동하는 경우
개발 환경 추천 기준
일반 작업은 http://localhost로 빠르게 개발하고, 운영 HTTPS 환경과 동일한 테스트가 필요한 프로젝트만 mkcert + HTTPS로 구성하면 됩니다. 모든 프로젝트에 브라우저 보안 경고 해제 설정을 적용할 필요는 없습니다.
권장 해결 방법｜mkcert로 신뢰 가능한 로컬 SSL 인증서 만들기
mkcert는 내 PC에서만 신뢰되는 로컬 인증기관(CA)을 만들고, 이 CA가 서명한 개발용 인증서를 생성하는 도구입니다. 크롬은 Windows 인증서 저장소를 신뢰하므로, mkcert로 만든 인증서를 개발 서버에 연결하면 localhost 접속 시 보안 경고 없이 HTTPS를 사용할 수 있습니다.
중요한 점은 일반 자체 서명 인증서와 달리, mkcert가 만든 인증서는 내 PC의 신뢰 저장소에 등록한 로컬 CA로 서명되기 때문에 브라우저 경고가 줄어든다는 것입니다.
Windows에서 mkcert 설치하기
Windows에서는 Chocolatey, Scoop 또는 mkcert 공식 GitHub 저장소의 사전 빌드 파일을 이용해 설치할 수 있습니다. 개발 PC에 이미 Chocolatey 또는 Scoop이 설치돼 있다면 아래 방식으로 설치하면 됩니다.
Chocolatey 사용 시
choco install mkcertScoop 사용 시
scoop bucket add extras
scoop install mkcert1단계. 내 PC에 로컬 CA 설치
mkcert 설치 후 명령 프롬프트, PowerShell 또는 Windows Terminal을 실행하고 아래 명령을 입력합니다.
mkcert -install이 작업은 현재 PC의 신뢰할 수 있는 루트 인증 기관 저장소에 개발용 로컬 CA를 등록합니다. 이후 이 CA로 서명한 localhost 인증서를 크롬, 엣지 등에서 신뢰할 수 있습니다.
rootCA-key.pem 파일은 절대 공유하면 안 됩니다
mkcert 설치 과정에서 만들어지는 rootCA-key.pem은 매우 중요한 개인 키입니다. 이 파일이 외부에 유출되면 공격자가 내 PC에서 신뢰되는 것처럼 보이는 인증서를 만들 수 있습니다.
팀원에게 인증서 파일을 그대로 전달하거나, Git 저장소·OneDrive·공유 폴더에 rootCA-key.pem을 올리면 안 됩니다. 팀 개발 환경에서는 각자 자신의 PC에서 mkcert를 설치하고 인증서를 생성하는 방식이 안전합니다.
mkcert -CAROOT위 명령을 입력하면 로컬 CA 파일이 저장된 위치를 확인할 수 있습니다.
2단계. localhost·127.0.0.1용 인증서 생성
프로젝트 폴더 또는 인증서를 보관할 별도 폴더로 이동한 뒤 아래 명령을 입력합니다.
mkcert localhost 127.0.0.1 ::1이 명령은 localhost, IPv4 루프백 주소인 127.0.0.1, IPv6 루프백 주소인 ::1 접속에 사용할 수 있는 인증서와 개인 키 파일을 생성합니다.
프로젝트별로 파일명을 일정하게 관리하고 싶다면 아래처럼 인증서와 키 파일 이름을 직접 지정할 수 있습니다.
mkcert -cert-file localhost.pem -key-file localhost-key.pem localhost 127.0.0.1 ::13단계. 개발 서버에 인증서와 키 파일 연결
인증서를 생성했다고 해서 서버가 자동으로 HTTPS로 실행되지는 않습니다. 사용하는 개발 서버, 로컬 WAS, Apache, Nginx, IIS, Node.js, Vite, React 개발 서버 등의 설정에서 다음 두 파일 경로를 지정해야 합니다.
| 설정 항목 | 연결할 파일 | 역할 |
|---|---|---|
| SSL Certificate / cert | localhost.pem | 브라우저에 전달하는 공개 인증서 |
| SSL Certificate Key / key | localhost-key.pem | 서버가 보관해야 하는 개인 키 |
주의
인증서 파일은 프로젝트 설정에서 참조할 수 있지만, 개인 키 파일은 Git에 올리면 안 됩니다. .gitignore에 *.pem, *.key, 또는 인증서 보관 폴더를 추가해 저장소에 업로드되지 않도록 관리하는 것이 좋습니다.
사용자 지정 로컬 도메인 mysite.test HTTPS 설정
프로젝트가 여러 개이거나 쿠키, 서브도메인, 리디렉션, 도메인 기반 API 연동을 테스트해야 한다면 localhost 대신 mysite.test처럼 테스트용 도메인을 사용하는 경우가 있습니다.
이때 단순히 hosts 파일만 수정하고 HTTP로 접속하면 브라우저는 해당 주소를 localhost와 동일하게 보지 않을 수 있습니다. 사용자 지정 도메인을 사용할 때는 HTTPS 인증서를 함께 설정하는 편이 안정적입니다.
1. hosts 파일에 로컬 도메인 등록
메모장을 관리자 권한으로 실행한 뒤 아래 경로의 hosts 파일을 엽니다.
C:\Windows\System32\drivers\etc\hosts파일 맨 아래에 다음처럼 입력하고 저장합니다.
127.0.0.1 mysite.test
127.0.0.1 api.mysite.test2. 사용자 지정 도메인용 인증서 생성
mkcert mysite.test api.mysite.test localhost 127.0.0.1 ::1이후 개발 서버의 HTTPS 설정에 생성된 인증서와 키 파일을 연결한 뒤 https://mysite.test로 접속합니다. 주소창에 자물쇠 경고가 나오지 않고 정상 연결된다면 인증서 설정이 완료된 것입니다.
.local 도메인보다 .test 또는 .localhost를 권장하는 이유
로컬 테스트 주소는 일반 인터넷 도메인과 충돌하지 않도록 관리해야 합니다. mysite.test 또는 dev.mysite.localhost처럼 개발 목적에 맞는 이름을 사용하면 실제 운영 도메인과 혼동할 가능성을 줄일 수 있습니다.
특히 localhost 하위 도메인인 project.localhost 형식은 로컬 개발에서 활용하기 좋습니다. 다만 실제 접속 주소, 서버 바인딩 주소, 인증서 SAN 항목이 서로 일치해야 합니다.
chrome://flags allow insecure localhost는 지금도 사용해도 될까?
예전에는 Chrome 주소창에 아래 주소를 입력한 뒤 Allow invalid certificates for resources loaded from localhost 항목을 Enabled로 바꾸는 방법이 널리 사용됐습니다.
chrome://flags/#allow-insecure-localhost하지만 이 방법은 현재 모든 Chrome 버전에서 안정적으로 제공된다고 보기 어렵습니다. Chrome 업데이트에 따라 플래그가 보이지 않거나 만료·제거될 수 있으며, 브라우저 보안 검증을 우회하는 방식이기 때문에 장기적인 개발 환경 설정으로 적합하지 않습니다.
플래그 방식이 권장되지 않는 이유
- Chrome 버전마다 메뉴 노출 여부와 동작이 달라질 수 있음
- Chrome에서만 적용되어 Edge, Firefox, Safari 테스트 환경과 차이가 생김
- 잘못된 인증서·주소 불일치 문제를 해결하는 대신 숨길 수 있음
- 운영 HTTPS 환경과 다른 방식으로 테스트하게 됨
- 브라우저 보안 정책을 무시하는 습관으로 이어질 수 있음
unsafely treat insecure origin as secure 플래그와 차이
Chrome에는 특정 HTTP 주소를 보안 컨텍스트처럼 취급하도록 하는 개발용 플래그가 별도로 존재할 수 있습니다. 하지만 이것은 자체 서명 인증서 경고를 해결하는 기능이 아니라, 특정 로컬 주소에서 Service Worker 같은 보안 컨텍스트 기능을 테스트하기 위한 임시 개발 옵션에 가깝습니다.
즉, 인증서 오류가 목적이라면 Chrome flags를 건드리기보다 mkcert로 올바른 로컬 인증서를 구성하는 방식이 더 정확합니다.
SSL 보안 경고가 계속될 때 점검 순서
인증서 주소와 실제 접속 주소가 일치하는지 확인
인증서를 localhost로 만들었다면 브라우저도 https://localhost:포트번호로 접속해야 합니다. 127.0.0.1, ::1, mysite.test, api.mysite.test 등으로 접속할 계획이라면 인증서를 만들 때 해당 이름과 IP를 함께 지정해야 합니다.
개발 서버가 HTTP가 아닌 HTTPS로 실행 중인지 확인
서버는 HTTP 포트로 실행 중인데 주소창에 https를 붙여 접속하면 SSL 프로토콜 오류가 발생할 수 있습니다. 개발 서버 설정에서 HTTPS 옵션이 켜져 있는지, 인증서 파일 경로가 맞는지, 서버 재시작이 됐는지 확인합니다.
PC 날짜와 시간이 정확한지 확인
Windows 날짜·시간·표준 시간대가 크게 틀어져 있으면 정상 인증서도 만료되었거나 아직 유효하지 않은 인증서로 판단될 수 있습니다. 특히 CMOS 배터리 문제, 듀얼 부팅, 가상 머신, 장기간 사용하지 않은 PC에서는 시간 동기화 상태를 확인하는 것이 좋습니다.
이전 인증서와 브라우저 캐시를 정리
인증서를 새로 만들었는데도 이전 오류가 반복된다면 개발 서버를 완전히 종료한 뒤 다시 실행하고, 크롬 탭을 닫은 뒤 새 창에서 재접속합니다. 서비스 워커 또는 캐시가 남아 있는 프로젝트라면 Chrome 개발자 도구의 Application 탭에서 해당 사이트 데이터와 서비스 워커 상태도 확인해야 합니다.
외부 IP 또는 모바일 기기 접속은 별도로 생각하기
내 PC의 192.168.x.x 같은 사설 IP로 스마트폰이나 다른 PC에서 접속하려면, localhost용 인증서만으로는 부족합니다. 해당 IP 또는 내부 도메인 이름을 인증서에 포함해야 하고, 접속하는 다른 기기에서도 로컬 CA를 신뢰하도록 별도 설정이 필요할 수 있습니다.
보안 주의
개발용 로컬 CA의 루트 인증서와 개인 키를 다른 사람에게 전달하거나, 스마트폰·외부 PC에 무분별하게 설치하면 보안 위험이 생길 수 있습니다. 사내 서비스·고객 테스트·외부 공유가 필요하다면 로컬 인증서보다 정식 HTTPS 도메인, 테스트 서버, 보안 프록시 환경을 검토하는 것이 좋습니다.
localhost SSL 보안 경고와 CORS 오류는 다른 문제입니다
로컬 개발 중에는 SSL 보안 경고와 CORS 오류를 혼동하는 경우가 많습니다. 하지만 두 문제는 해결 방식이 다릅니다.
| 구분 | 주요 증상 | 해결 방향 |
|---|---|---|
| SSL 인증서 오류 | 연결이 비공개로 설정되어 있지 않음, 인증서 경고 | 신뢰 인증서 설정, 주소·인증서 이름 일치 확인 |
| CORS 오류 | No 'Access-Control-Allow-Origin' header 오류 | API 서버의 Access-Control-Allow-Origin 설정 수정 |
| Mixed Content 오류 | HTTPS 페이지에서 HTTP 이미지·스크립트·API 차단 | 모든 리소스를 HTTPS로 변경하거나 상대 경로 사용 |
| 연결 거부 | ERR_CONNECTION_REFUSED | 서버 실행, 포트 번호, 방화벽, 프록시 설정 확인 |
Chrome flags에서 보안 경고를 무시해도 CORS 오류나 API 인증 오류는 해결되지 않습니다. 브라우저 콘솔의 정확한 오류 메시지를 먼저 보고, 인증서 문제인지 서버 응답 헤더 문제인지 구분해야 합니다.
localhost SSL 인증서 FAQ
http://localhost는 HTTPS가 아닌데도 Service Worker가 작동하나요?
대부분의 경우 가능합니다. localhost와 127.0.0.1 같은 루프백 주소는 로컬 개발 편의를 위해 브라우저에서 특수하게 신뢰할 수 있는 주소로 취급됩니다. 다만 HTTP/2 테스트, 사용자 지정 도메인, 외부 OAuth·API 연동처럼 실제 HTTPS가 필요한 상황은 별도로 인증서를 설정해야 합니다.
chrome://flags/#allow-insecure-localhost가 검색되지 않습니다
Chrome 버전에 따라 해당 플래그가 보이지 않거나 이미 제거됐을 수 있습니다. 이 경우 플래그를 복구하려고 하기보다 http://localhost로 개발하거나 mkcert를 이용해 로컬 신뢰 인증서를 만드는 방식을 권장합니다.
localhost 인증서를 만들었는데 127.0.0.1에서 오류가 납니다
인증서에 127.0.0.1이 포함되지 않았을 가능성이 큽니다. mkcert localhost 127.0.0.1 ::1처럼 실제로 사용할 호스트와 IP를 함께 지정해 인증서를 다시 만들고 서버 설정에 새 파일을 적용합니다.
mkcert 인증서는 운영 서버에도 사용해도 되나요?
안 됩니다. mkcert는 개인 PC 또는 내부 개발 환경에서만 신뢰되는 로컬 CA를 만드는 도구입니다. 실제 서비스 사이트에는 Let’s Encrypt, DigiCert, Sectigo 등 공인 인증기관이 발급한 인증서를 사용해야 합니다.
개발 서버 인증서 파일을 GitHub에 올려도 되나요?
인증서 공개 파일 자체보다도 개인 키 파일과 rootCA-key.pem 유출이 특히 위험합니다. 팀 개발이라면 인증서 파일을 공유하기보다 각 개발자가 mkcert를 설치해 자신의 PC에서 인증서를 만드는 방식이 안전합니다.
크롬 보안 경고를 무시하고 접속해도 되나요?
직접 만든 단발성 테스트 서버에서 원인을 분명히 아는 경우에만 임시로 사용할 수 있습니다. 하지만 반복 개발 환경에서는 잘못된 인증서 설정을 놓칠 수 있고, 다른 브라우저 테스트도 어려워지므로 mkcert 기반 설정으로 바꾸는 것이 좋습니다.
관련 글
웹사이트 SSL 보안인증서 설치 중요성 컴퓨터 개인정보 보호·인터넷 보안 설정
Chrome 경고를 끄기보다 로컬 HTTPS 환경을 제대로 구성
localhost SSL 보안 경고는 크롬이 고장 난 것이 아니라, 브라우저가 인증서의 신뢰성과 주소 일치를 확인하는 정상적인 보안 동작입니다.
간단한 로컬 개발은 http://localhost를 사용하면 대부분 빠르게 해결할 수 있습니다. 하지만 운영 HTTPS 환경과 동일한 동작을 확인해야 하거나, HTTP/2·OAuth·사용자 지정 도메인·보안 쿠키·혼합 콘텐츠를 테스트해야 한다면 mkcert로 로컬 인증서를 만들고 개발 서버에 연결하는 방식이 가장 안정적입니다.
예전에 사용하던 Chrome flags 방식은 버전 의존성이 크고 브라우저 보안 검증을 우회하는 방식입니다. 개발 환경을 오래 유지해야 한다면 임시 경고 해제보다 인증서·도메인·서버 설정을 정상적으로 맞추는 것이 결과적으로 더 빠르고 안전합니다.
태그: localhost SSL 오류, 크롬 보안경고 해결, Chrome localhost 인증서, mkcert 설치, 로컬 HTTPS 설정, NET ERR CERT AUTHORITY INVALID, 127.0.0.1 SSL 오류, Chrome flags localhost, 자체서명 인증서, 개발서버 HTTPS