SSL 인증서 오류로 ‘연결이 비공개로 설정되어 있지 않습니다’가 뜨는 원인과 해결방법

ELIYAHUB 2026년 8월 13일 최종 수정 8월 27일 읽는 시간 약 8분

이 경고가 나타나는 기술적 배경

‘연결이 비공개로 설정되어 있지 않습니다(NET::ERR_CERT_*)’는 크롬이 TLS/SSL 핸드셰이크 과정에서 서버가 제시한 인증서를 신뢰할 수 없다고 판단할 때 표시하는 경고다. 브라우저는 HTTPS 연결 시 서버 인증서가 신뢰할 수 있는 루트 인증기관(CA)까지 이어지는 체인을 갖추고 있는지, 인증서 도메인과 실제 접속 도메인이 일치하는지, 유효 기간이 지나지 않았는지를 종합 검증한다. 이 중 하나라도 충족되지 않으면 브라우저는 중간자 공격(MITM) 등 실제 보안 위협으로부터 사용자를 보호하기 위해 경고를 띄운다. 즉 이 오류는 표시 결함이 아니라 정상적인 방어 기제다.

인증서 만료 — 가장 흔한 원인과 해결법

가장 흔한 원인은 서버 관리자가 SSL 인증서 갱신 시점을 놓쳐 인증서가 만료된 경우다. Let’s Encrypt처럼 무료 발급 인증서는 보통 90일의 짧은 유효 기간을 가지며, 자동 갱신 스크립트(certbot 등)가 정상 작동하지 않으면 만료일을 넘기기 쉽다. 상용 인증서 역시 1~2년 주기로 갱신이 필요한데, 담당자 변경이나 결제 실패로 갱신이 누락되는 사례가 실무에서 적지 않다. 이 경우 크롬은 NET::ERR_CERT_DATE_INVALID 오류 코드를 함께 표시한다.

해결법: 사이트 운영자는 서버에 접속해 인증서 만료일을 즉시 확인하고 재발급 절차를 진행해야 한다. Let’s Encrypt를 쓴다면 certbot renew 명령으로 수동 갱신을 시도하고, 자동 갱신 크론 작업이 정상 등록돼 있는지 crontab -l로 점검한다. 상용 인증서라면 발급사 대시보드에서 결제 상태를 확인하고, 갱신 후에는 웹서버를 재시작해 새 인증서가 실제로 적용됐는지 openssl s_client 명령이나 온라인 SSL 체커로 재검증해야 한다. 방문자 입장에서는 재발급이 완료될 때까지 접속을 미루는 것이 안전하다.

도메인 불일치 — CN/SAN 검증 실패와 해결법

인증서에는 해당 인증서가 어떤 도메인을 위해 발급됐는지 명시하는 필드(SAN)가 포함되는데, 실제 접속 URL의 도메인과 이 필드가 일치하지 않으면 NET::ERR_CERT_COMMON_NAME_INVALID 오류가 발생한다. 대표적 사례는 www.example.com용 인증서로 example.com에 접속하는 경우다. 서브도메인을 여러 개 운영하면서 와일드카드 인증서 없이 개별 인증서만 발급받았을 때도 자주 발생한다.

해결법: 인증서를 재발급할 때 SAN 필드에 www 포함 여부, 서브도메인 목록을 빠짐없이 명시해야 한다. 서브도메인이 늘어날 가능성이 있다면 와일드카드 인증서(*.example.com)로 전환하는 것이 유지보수 측면에서 효율적이다. 재발급 후에는 실제 접속 도메인 각각으로 접속해 SAN 목록에 해당 도메인이 포함돼 있는지 직접 확인해야 한다.

신뢰 체인 문제 — 자체 서명 인증서와 중간 인증서 누락, 해결법

공인 인증기관을 거치지 않은 자체 서명(Self-signed) 인증서는 브라우저 신뢰 저장소에 등록돼 있지 않아 NET::ERR_CERT_AUTHORITY_INVALID 오류가 뜬다. 사내 인트라넷에서는 흔한 상황이지만, 공개 웹사이트에서 발생한다면 심각한 문제다. 또 다른 원인은 서버가 중간 인증기관(Intermediate CA) 인증서를 함께 전송하지 않는 설정 오류다.

해결법: 공개 웹사이트라면 자체 서명 인증서 대신 공인 인증기관이 발급한 인증서로 교체해야 한다. 중간 인증서 누락이 원인이라면 전체 체인 파일(fullchain.pem 등)을 서버 설정에 반영해 최상위부터 중간 인증서까지 순서대로 전송되도록 구성해야 한다. SSL Labs의 SSL Server Test로 체인 구성을 확인하면 유용하다.

사용자 측 환경 문제 — 시스템 시간과 네트워크 개입, 해결법

인증서 검증은 현재 시스템 시간을 기준으로 이뤄지기 때문에, 기기의 날짜·시간이 실제와 크게 어긋나 있으면 정상 인증서도 잘못 판단돼 오류가 발생할 수 있다. 회사·학교 방화벽, 백신의 ‘HTTPS 검사’ 기능, 공용 와이파이의 캡티브 포털이 통신을 가로채 자체 인증서로 재서명하는 경우에도 동일한 경고가 뜬다.

해결법: 윈도우는 ‘설정 > 시간 및 언어’, 맥은 ‘시스템 설정 > 일반 > 날짜 및 시간’에서 ‘자동으로 설정’ 옵션을 켜면 대부분 즉시 해결된다. 동기화 후에도 남아있다면 브라우저 캐시 삭제나 재부팅으로 반영시킨다. 네트워크·보안 소프트웨어가 의심된다면 회사·학교의 경우 IT 부서에 HTTPS 검사 예외 처리를 요청하고, 개인 백신이 원인이라면 ‘HTTPS 검사’ 기능을 일시적으로 꺼서 확인해본다. 공용 와이파이의 캡티브 포털이 원인이라면 로그인 페이지를 먼저 완료하거나 다른 네트워크로 전환하는 것이 가장 빠른 해결책이다.

오류 발생 시 사용자가 지켜야 할 원칙

무작정 ‘고급 > 안전하지 않음으로 이동’을 눌러 우회하기보다 원인을 먼저 가늠해보는 것이 안전하다. 기기의 날짜·시간을 확인하고, 같은 사이트를 다른 기기나 네트워크에서 접속해봐서 오류가 재현되는지 확인하면 문제 소재를 어느 정도 구분할 수 있다. 은행이나 쇼핑몰처럼 민감한 정보를 다루는 사이트라면 절대 우회하지 말고 별도 경로(공식 앱, 고객센터)로 확인하는 것이 원칙이다.

장단점 분석

원인 유형	해결 주체	해결 난이도	핵심 조치
인증서 만료	사이트 운영자	낮음(재발급으로 즉시 해결)	certbot renew, 자동 갱신 점검
도메인 불일치(SAN)	사이트 운영자	중간(인증서 재구성 필요)	SAN 필드 보완, 와일드카드 전환
신뢰 체인 누락	사이트 운영자	중간~높음(서버 설정 전반 점검)	fullchain.pem 적용, SSL Labs 검증
시스템 시간 오류	사용자	낮음(시간 동기화로 즉시 해결)	자동 시간 동기화 설정
네트워크·보안 SW 개입	사용자/네트워크 관리자	중간(신뢰 인증서 등록 필요)	HTTPS 검사 예외 처리

사용자 평가 및 후기

가장 많이 언급되는 해결 사례는 의외로 ‘컴퓨터 시간이 틀어져 있었다’는 경우다. 오래된 노트북이나 배터리가 방전됐던 데스크탑에서 반복적으로 보고되며, 시간 동기화 후 바로 해결됐다는 후기가 많다. 회사 네트워크 사용자들 사이에서는 사내 보안 프로그램의 HTTPS 검사 기능이 원인이었다는 경험담도 자주 등장한다. 사이트 운영자 입장에서는 Let’s Encrypt 자동 갱신 스크립트가 조용히 실패해 있었다는 사례가 반복적으로 언급된다.

내 의견

개인적으로는 이 오류를 접했을 때 ‘우회 접속’과 ‘원인 진단’을 명확히 구분하는 태도가 중요하다고 생각한다. 로그인·결제 정보를 입력해야 하는 사이트라면 경고를 무시하는 순간의 편리함보다 잠재적 피해가 훨씬 크기 때문에 절대 우회하지 않는 것이 원칙이어야 한다. 반대로 원인이 기기 시간 오류나 사내 보안 프로그램처럼 비교적 무해한 경우도 꽤 많다는 점을 알아두면 불필요한 불안을 줄일 수 있다. 사이트 운영자라면 인증서 자동 갱신 설정과 함께 갱신 실패 시 알림이 오도록 모니터링 체계를 구축해두는 것을 강력히 권하고 싶다.

ELIYAHUB