2 분 소요

Chrome NET::ERR_CERT_AUTHORITY_INVALID 해결방법

사내 개발 서버나 로컬 테스트 서버에 접속할 때 Chrome에서 NET::ERR_CERT_AUTHORITY_INVALID가 뜨면 처음에는 서버가 완전히 죽은 것처럼 느껴질 수 있다. 그런데 실제로는 서버가 죽은 게 아니라 브라우저가 해당 인증서를 신뢰하지 않는 상태인 경우가 많다. 개발 환경에서는 self-signed certificate나 내부 CA를 쓰는 경우가 흔해서 더 자주 만난다.

문제는 해결 방법을 잘못 익히면 위험하다는 점이다. 검색하면 thisisunsafe나 --ignore-certificate-errors 같은 우회가 먼저 나오는데, 이건 어디까지나 개발용 임시 수단이다. 운영 환경 문제를 이런 방식으로 덮으면 안 된다. 이 글에서는 빠른 우회와 근본 해결을 분리해서 본다.

이 오류가 의미하는 것

Chrome은 TLS 연결 시 서버가 제시한 인증서가 신뢰 가능한 CA 체인으로 이어지는지 확인한다. 아래 같은 경우 이 오류가 자주 난다.

  • self-signed 인증서를 직접 사용함
  • 회사 내부 CA를 로컬 신뢰 저장소에 설치하지 않음
  • 중간 인증서 체인이 누락됨
  • 인증서의 SAN, 도메인, 유효기간이 맞지 않음

즉, “HTTPS인데 왜 안 되지?”가 아니라 브라우저가 이 서버를 믿을 근거가 부족한 상태라고 이해하는 편이 정확하다.

가장 먼저 해야 할 판단

문제가 난 서버가 개발용인지, 운영에 가까운 서버인지부터 구분해야 한다.

개발 또는 로컬 테스트 환경

짧게 우회해서 기능을 확인할 수 있다. 다만 우회는 정말 임시 수단으로만 써야 한다.

운영 또는 스테이징 환경

인증서 체인, 루트 CA, SAN, 중간 인증서를 정상화해야 한다. 브라우저 경고를 무시하는 방식은 답이 아니다.

빠른 임시 우회 방법

1) thisisunsafe

Chrome 경고 화면에 포커스를 둔 상태에서 키보드로 thisisunsafe를 입력하면 경고를 넘길 수 있는 경우가 있다. 오래된 개발자 팁으로 꽤 유명하다.

이 방법은 빠르지만 단점도 분명하다.

  • 팀 문서로 남기기엔 지나치게 마법 주문 같다
  • 브라우저 버전이나 정책에 따라 항상 기대하면 안 된다
  • 근본 원인을 전혀 해결하지 않는다

개인적으로는 “지금 당장 로컬 화면 확인이 급할 때” 정도로만 쓴다.

2) Chrome 실행 옵션으로 우회

개발용 별도 브라우저 인스턴스를 띄워 임시로 우회하는 방법도 있다.

macOS 예시는 아래와 같다.

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --ignore-certificate-errors \
  --ignore-urlfetcher-cert-requests

이 방식 역시 편하지만, 평소 쓰는 메인 브라우저에 습관적으로 적용하는 것은 추천하지 않는다. 보안 감각을 둔하게 만들기 쉽다.

근본 해결: 신뢰 가능한 인증서 체인 만들기

장기적으로는 이쪽이 맞다. 로컬 개발이라면 아래 선택지를 고려할 수 있다.

  • 내부 CA를 만들어 로컬 신뢰 저장소에 설치
  • mkcert 같은 도구로 로컬 신뢰 가능한 개발 인증서 발급
  • 프록시 도구 예를 들어 Charles의 루트 인증서를 정확히 설치

특히 팀 단위 개발에서는 “각자 thisisunsafe 입력”보다 공통 개발 인증서 발급 방식을 정해 두는 편이 훨씬 건강하다.

예를 들어 mkcert를 쓰면 로컬에서 신뢰 가능한 개발용 인증서를 비교적 편하게 만들 수 있다.

mkcert -install
mkcert local.example.test localhost 127.0.0.1 ::1

그 뒤 서버 설정에서 해당 인증서를 사용하면 브라우저 경고 없이 개발할 수 있다.

자주 겪는 함정

도메인 이름이 인증서와 다르다

요즘은 CN보다 SAN이 더 중요하다. localhost용 인증서로 api.dev.local에 접속하면 당연히 경고가 뜬다. 이름이 맞는지부터 확인해야 한다.

중간 인증서 누락

서버에 리프 인증서만 달아두고 중간 인증서를 빠뜨리는 실수가 꽤 흔하다. 로컬에서는 가끔 되고, 다른 환경에서는 안 되는 이상한 증상으로 보이기도 한다.

프록시 도구 인증서와 충돌한다

Charles 같은 프록시를 쓰는 환경에서는 프록시 CA를 신뢰해야 HTTPS 복호화가 된다. 이 상태를 잘못 이해하면 서버 인증서 문제와 프록시 인증서 문제를 섞어버리기 쉽다.

실무 판단

내 기준은 아래와 같다.

  • 잠깐 화면만 봐야 한다 → thisisunsafe 가능
  • 하루 이상 반복 테스트한다 → 신뢰 가능한 로컬 인증서 구성
  • 팀 공용 서버다 → 체인과 발급 방식부터 바로잡기

편한 우회가 항상 좋은 해결책은 아니다. 특히 자동화 테스트나 사내 공용 개발 환경에서는 HTTPS 구성이 안정적이어야 재현성도 좋아진다.

체크리스트

  • 이 서버가 개발용인지 운영용인지 먼저 구분했다
  • self-signed, 내부 CA, 체인 누락 중 어떤 문제인지 확인했다
  • 임시 우회는 임시로만 사용했다
  • 반복 개발 환경이라면 mkcert 등으로 로컬 신뢰 체계를 만들었다
  • 프록시 도구 사용 중이라면 별도 인증서 문제를 분리해서 봤다

마무리

NET::ERR_CERT_AUTHORITY_INVALID는 겉보기에는 단순한 브라우저 에러지만, 실제로는 신뢰 체인 설계가 허술한 상태를 드러내는 신호다. 급할 때 우회는 가능하지만, 개발 생산성을 생각하면 결국은 인증서 구성을 바로잡는 편이 훨씬 덜 번거롭다. 브라우저를 속이는 방법보다 브라우저가 신뢰할 수 있는 환경을 만드는 쪽이 오래 간다.

댓글남기기