경고는 위협만 알려 주고 방법은 알려 주지 않습니다. r/techsupport에 한 사용자가 이 상황을 이렇게 적었습니다. 몇 년 동안 쓰던 스트리밍 사이트가 갑자기 "연결이 비공개로 설정되어 있지 않습니다" 페이지로 넘어갔는데, 경고를 본 것만으로 이미 PC가 감염된 것인지, 아니면 페이지를 넘기지 않았으니 아직 안전한 것인지 포럼에 물었습니다. 두 가능성 모두 그에게는 그럴듯하게 들렸습니다. 화면에는 어느 쪽인지 판단할 근거가 없었습니다.
하루를 통째로 날리는 경우도 있습니다. 영국의 한 학생은 Student Finance 로그인이 같은 경고에 막혔습니다. 꼭 필요한 정부 계정인데, 그 앞을 가로막은 페이지는 공격자가 비밀번호를 훔치려 할 수도 있다고 말하고 있었습니다. 그 스레드는 몇 달 동안 살아 있었습니다. 사용자들은 휴대폰에서는 되는데 노트북에서는 안 되고, Chrome에서는 실패하는데 Edge에서는 열리고, 일반 창에서는 거부하던 사이트가 시크릿 창에서는 열린다고 적었습니다. 그중 누구도 잘못한 것이 없었습니다.
두 사용자 모두에게 경고가 내놓는 답은 필요하지 않았습니다. "연결이 비공개로 설정되어 있지 않습니다"는 브라우저가 이 사이트가 주장하는 그 사이트인지 확인하지 못했다는 뜻입니다. 사이트가 보낸 인증서가 없거나, 만료됐거나, 다른 이름으로 발급됐거나, 브라우저가 신뢰하지 않는 기관이 서명했거나, 확인 자체가 불가능했다는 것입니다. 원인은 대개 사소합니다. 누군가 갱신을 잊었거나, 기기 시계가 틀어졌거나, 회사 프록시가 연결을 가로채고 있는 것입니다.
경고는 공격자를 언급합니다. 하지만 실제로 설명하는 실패는 검증 실패이고, 그 범위는 훨씬 좁습니다. 대개가 갱신 누락인데도 이 문구가 고발처럼 읽히는 이유가 그 간극입니다. 아래에서는 오류 코드마다 무엇을 가리키는지, 사이트 문제와 기기 문제를 어떻게 구분하는지, 언제 "계속 진행"을 눌러도 되는지, 시간을 가장 적게 낭비하는 해결 순서를 다룹니다. 해결책이 "비교해 볼 두 번째 깨끗한 브라우저가 필요하다"는 쪽이라면 Tabbit Browser를 예로 들어 설명하겠습니다.
핵심 요약
이 문구는 검증 실패를 알리는 것이지 악성코드를 탐지한 것이 아닙니다. 브라우저가 사이트의 신원을 확인해 주지 못한 것이고, 거부하는 쪽이 올바른 기본값입니다.
페이지에서 쓸모 있는 정보는 오류 코드입니다.
NET::ERR_CERT_DATE_INVALID,NET::ERR_CERT_AUTHORITY_INVALID,ERR_CERT_COMMON_NAME_INVALID는 각각 다른 원인과 다른 첫 조치를 가리킵니다.한 사이트만 실패하는지 전부 실패하는지가 문제를 가르는 가장 빠른 기준입니다. 한 사이트면 그 사이트 문제, 전부면 내 기기나 네트워크, 또는 그 사이에 있는 무언가의 문제입니다.
Chrome의 공식 문제 해결 문서는 기업용 HTTPS 가로채기 도구를 이름까지 밝혀 둡니다. Zscaler, Palo Alto Networks, Fortinet 뒤에 있는 업무용 기기라면 문서가 알려 주는 답은 직접 뭔가를 설치하지 말고 관리자에게 문의하라는 것입니다.
인증서 수명은 정해진 일정에 따라 짧아지고, 그만큼 만료 때문에 뜨는 경고는 늘어납니다. Chrome의 SSL 경고는 오랫동안 그냥 넘겨 버리기 쉬운 것이었으니, 코드를 읽는 습관의 값어치가 그만큼 커집니다.
이 경고가 실제로 말하는 것
브라우저는 네 가지 조건이 모두 맞아야 보안 연결을 받아들입니다. 서버가 인증서를 제시합니다. 그 인증서에 요청한 호스트 이름이 들어 있습니다. 브라우저가 이미 신뢰하는 인증 기관(CA)이 서명했습니다. 그리고 인증서가 유효 기간 안에 있습니다. 이 중 하나라도 어긋나면 경고 페이지가 뜹니다.
Cloudflare의 설명 문서는 서버 쪽에서 같은 조건을 나열합니다. 인증서가 아예 없거나, 만료됐거나, 정식 기관이 발급하지 않았거나, 다른 이름으로 발급됐을 수 있다는 것입니다. 이들이 드는 비유는 신분증을 요구했더니 손으로 쓴 쪽지를 내미는 계산원입니다. 계산원이 거래를 멈추는 것은 맞는 판단이고, 그 쪽지가 진짜일 수도 있습니다. 브라우저가 놓인 자리가 정확히 그렇습니다.
여기서 두 가지가 따라오고, 둘 다 다음 행동을 좌우합니다.
첫째, 경고는 페이지가 로드되기 전에 나타납니다. 아직 사이트에서 온 어떤 것도 내 기기에서 실행되지 않았습니다. 공격자가 비밀번호를 훔칠 수도 있다는 무서운 문장은 검증되지 않은 연결로 계속 진행했을 때 무엇이 가능해지는지를 설명하는 것이지, 이미 벌어진 일을 말하는 것이 아닙니다.
둘째, 브라우저는 "이 사이트가 고장 났다"와 "이 사이트가 악의적이다"를 구분하지 못합니다. 밖에서 보면 둘이 똑같습니다. 그래서 양쪽에 같은 페이지를 보여 주고, 실제 원인이 갱신 누락일 때 이 문구가 지나치게 과하게 느껴지는 것입니다.
오류 코드별 의미와 원인
제목 아래 작은 회색 글씨가 이 페이지에서 유일하게 기술적인 정보이고, 모두가 건너뛰는 부분입니다. 코드마다 원인이 다르고 첫 확인 사항도 다릅니다.
| 페이지에 표시되는 오류 코드 | 의미 | 먼저 확인할 것 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID, 또는 "시계가 뒤처지거나 앞서 있습니다" | 인증서가 유효 기간을 벗어났거나, 기기가 그렇게 인식하고 있음 | 기기의 날짜, 시간, 시간대. 자동 설정으로 바꾸고 새로고침 |
NET::ERR_CERT_AUTHORITY_INVALID | 발급자가 브라우저의 신뢰할 수 있는 기관 목록에 없음 | 회사 프록시, 백신 HTTPS 검사, VPN이 연결을 가로채고 있는지 |
ERR_CERT_COMMON_NAME_INVALID | 인증서는 진짜지만 입력한 이름으로 발급되지 않음 | www.를 붙이거나 뗀 주소, 또는 다른 하위 도메인에서 열리는지 |
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM | 서명 알고리즘이 현재 기준을 충족하지 못함 | 내 쪽에서 할 일 없음. 사이트가 인증서를 다시 발급해야 함 |
ERR_CERTIFICATE_TRANSPARENCY_REQUIRED | 인증서가 공개 투명성 로그에 기록되지 않음 | 내 쪽에서 할 일 없음. 서버 설정 문제 |
| 전체 화면 경고 없이 "안전하지 않음" 표시만 나옴 | HTTPS가 아니라 일반 HTTP로 페이지가 열림 | 사이트가 https:// 주소를 제공하는지 |
Google의 Chrome 도움말은 이 코드들을 한자리에 모아 두고, 대부분의 해결 기사가 건너뛰는 단계를 하나 덧붙입니다. 프록시가 HTTPS를 가로채는 업무용 컴퓨터에서 Chrome이 Zscaler, Palo Alto Networks, Fortinet을 지목하는 경우, NET::ERR_CERT_AUTHORITY_INVALID가 표시됩니다. 보통 프록시 인증서가 시스템에 없다는 뜻입니다. 문서가 알려 주는 지침은 관리자에게 문의하고, 인증서를 직접 설치하지는 말라는 것입니다. 같은 문서는 시계 문제를 "시계가 뒤처져 있습니다"라는 별도 오류로 분리해 두는데, 일주일 동안 잠들어 있던 기기가 갑자기 웹의 절반을 거부하기 시작할 때 기억해 둘 만합니다.
인증서가 멀쩡한데도 경고가 뜨는 이유
경고가 모두 인증서 불량을 뜻하지는 않습니다. 2026년 8월에 널리 공유된 글은 시민 데이터를 다루는 정부 사이트가 경고를 띄웠지만 인증서는 그해 10월까지 유효했다고 전합니다. 보고된 원인은 만료가 아니라 적용 범위였습니다. 인증서가 상위 도메인으로 발급돼 사람들이 실제로 찾아가는 하위 도메인을 포함하지 않았던 것입니다. 인증서는 유효한데 이름이 틀렸고, 페이지는 막혔습니다.
이것이 ERR_CERT_COMMON_NAME_INVALID 사례이고, 연결의 내 쪽에서는 고칠 수 없는 네 가지 서버 측 상황 중 하나입니다. 인증서가 그냥 만료일을 넘겼을 수도 있고, 그렇다면 내 기기는 아무 관련이 없습니다. example.com을 포함하는 인증서에 www.example.com을 요청했을 수도 있는데, 보통 인증서를 발급한 뒤에 호스트 이름을 추가했다는 뜻입니다. 진짜 인증서지만 브라우저가 더 이상 받아들이지 않는 기관이 서명했거나, 애초에 받아들인 적 없는 사설 기관이 서명했을 수도 있습니다. 여러 사이트가 IP 주소 하나를 공유하는 서버에서는 같은 기기에 올바른 인증서가 있어도 요청한 호스트 이름에 맞지 않는 인증서를 내보낼 수 있습니다.
아주 천천히 번지고 있어 놓치기 쉬운 다섯 번째 원인도 있습니다. 인증서 수명이 업계 규칙으로 줄고 있습니다. CA/Browser Forum 일정에 따르면 공개적으로 신뢰받는 TLS 인증서의 최대 수명은 2026년 3월 15일까지 398일이고, 그다음 200일, 2027년 3월 15일부터 100일, 2029년 3월 15일부터 47일입니다. 도메인 검증 데이터도 비슷한 주기로 갱신해야 하고, 2029년에는 재사용 제한 10일이 도입됩니다.
인증서가 덜 믿을 만해진 것은 아닙니다. 달라지는 것은 손으로 갱신하는 사이트가 해마다 늦을 기회를 더 많이 갖는다는 점이고, 그래서 만료 때문에 뜨는 경고는 드문 사건이 아니라 웹의 일상적인 모습이 됩니다. 그럴수록 어떤 코드를 보고 있는지 아는 일의 쓸모가 커집니다.
내 컴퓨터 문제일까, 사이트 문제일까
경고가 끝내 답하지 않는 질문이고, 다음 행동을 결정하는 질문입니다. 두 가지만 관찰하면 어떤 도구보다 빠르게 범위를 좁힐 수 있습니다.
첫째는 범위입니다. 서로 관계없는 사이트 두세 곳을 열어 봅니다. 하나만 실패하고 나머지가 멀쩡하면 그 사이트 문제입니다. 전부 실패하면 내 쪽이나 네트워크, 또는 나와 인터넷 사이에 있는 무언가의 문제입니다.
둘째는 브라우저 간 일관성입니다. 같은 사이트가 서로 다른 두 브라우저 엔진에서 같은 오류 코드로 실패한다면 브라우저는 변수가 아닙니다.
| 보이는 증상 | 가리키는 원인 | 첫 조치 |
|---|---|---|
| 한 사이트만 실패하고 나머지는 멀쩡함 | 그 사이트의 문제: 인증서 만료, 이름 불일치, 설정 오류 | 몇 시간 기다렸다가 다시 시도하고 사이트의 상태 페이지나 지원 채널 이용. Chromium 계열에서 확인해 보면 도움이 됨. 이런 차단이 어떻게 나타나는지는 Cloudflare 루프 해결 참고 |
| 오늘 아침까지 쓰던 사이트를 포함해 전부 실패함 | 내 기기, 네트워크, 또는 캡티브 포털 | 날짜와 시간이 자동으로 설정돼 있는지 확인하고, 일반 http:// 페이지를 열어 Wi-Fi 로그인 페이지가 뜨는지 확인 |
| 일반 프로필에서만 실패하고 시크릿 창에서는 됨 | 프로필이나 확장 프로그램에 국한된 원인 | 한꺼번에 지우지 말고 확장 프로그램을 하나씩 끄면서 확인 |
| 업무용 노트북이나 회사 VPN에서만 실패함 | 관리형 프록시의 HTTPS 가로채기 | IT에 문의. Chrome 문서도 이건 관리자 쪽에서 고칠 문제라고 밝힘 |
| 오래 잠들어 있던 기기에서 실패함 | 어긋난 시계 | 날짜와 시간 자동 설정을 켜고 새로고침한 뒤 다시 확인 |
| 운영체제 업데이트 직후 실패함 | 바뀐 신뢰 저장소 또는 불완전하게 적용된 업데이트 | 업데이트가 사이트를 망가뜨렸을 때 할 일을 읽고 코드를 다시 확인 |
| 페이지는 열리지만 주소 표시줄에 "안전하지 않음"이 표시됨 | 인증서가 전혀 없는 일반 HTTP | 아무것도 입력하지 않음. 사이트의 https:// 주소를 먼저 찾아봄 |
프로필 문제를 가릴 때 쓸 수 있는 유용한 방법은 두 번째 브라우저 프로필입니다. 브라우저 프로필은 방문 기록, 쿠키, 비밀번호, 확장 프로그램을 서로 격리하므로, 새 프로필은 쓰던 환경을 건드리지 않는 깨끗한 실험대가 됩니다. 프로필, 워크스페이스, 탭 그룹이 각각 하는 일은 한 번도 의도적으로 써 본 적이 없다면 10분을 들일 만합니다.
"모든 사이트 실패" 행에서 브라우저를 바꾸고 해결됐다고 결론 내리고 싶어집니다. 하지만 별로 도움이 되지 않습니다. 같은 기기의 두 번째 브라우저는 같은 시계, 같은 네트워크, 같은 시스템 프록시 설정을 물려받기 때문입니다. 다만 확장 프로그램이나 프로필이 관련됐는지는 알려 줍니다. 치료가 아니라 검사로 다루세요.
"계속 진행"을 눌러도 될까
경우에 따라 그렇습니다. 온라인에 돌아다니는 조언보다 기준선은 그리기 쉽습니다.
아무것도 제출하지 않고 아무것도 내려받지 않는, 식당 메뉴나 대중교통 시간표처럼 공개 정보만 보여 주는 페이지라면 눌러도 됩니다. 최악의 결과라 해도 누군가 내가 본 것을 같이 보는 정도입니다.
자격 증명, 결제 정보, 신분 문서, 의료 기록, 또는 회사 시스템을 다루는 곳에서는 어디든 정당화되지 않습니다. 무시하려는 그 검사는 한 가지 질문에 답하려고 존재합니다. 이 서버가 말하는 그 서버인가? 은행 사이트나 급여 포털, 정부 로그인에서는 그 질문만이 내 비밀번호와 반대편에 있는 누군가를 갈라놓습니다.
이 경고가 실제로 효과가 있는지에 대한 연구 결과는 밝지 않습니다. Firefox와 Chrome에서 2500만 건이 넘는 경고 노출을 현장에서 관찰한 연구에 따르면, 사용자는 Firefox의 SSL 경고는 약 3분의 1, Chrome의 SSL 경고는 70.2%를 그냥 넘어갔습니다. 같은 연구에서 악성코드와 피싱 경고의 통과율보다 훨씬 높은 수치입니다. 이 숫자는 USENIX Security 2013에서 나온 것이고 당시 브라우저 버전을 설명하므로 2026년의 측정값은 아닙니다. 그래도 진단 없이 던져지는 경고는 눌러서 넘기게 된다는 가장 분명한 공개 근거이고, 제목이 아니라 코드를 읽어야 하는 이유이기도 합니다.
필요한 사이트가 바로 그 문제 사이트일 때 쓸 수 있는 선택지
이 문제에서 어려운 부분은 해결책을 찾는 게 아닙니다. 하루 종일 쓰는 브라우저를 헤집지 않고 그것을 시험해 보는 일입니다. 월요일 아침 상황을 가정한 한 인프라 엔지니어는, 서버와 방화벽이 모두 멀쩡한데 사용자들이 잠기고 화면에 NET::ERR_CERT_DATE_INVALID가 떠 있는 상황에서 무엇을 먼저 확인해야 하는지 동료들에게 묻습니다. 로그인 세션이 살아 있는 브라우저 안에서 그 조사를 벌이는 것 자체가 위험입니다.
Tabbit Browser가 들어가는 자리가 여기이고, 이것이 여기서 무엇을 바꾸고 무엇을 바꾸지 않는지는 정확히 짚을 가치가 있습니다.
Tabbit은 Chromium에서 실행되므로 인증서 처리 방식이 Chrome, Edge와 같습니다. 검증을 건너뛰지 않고, 경고를 무시하지 않으며, 다른 브라우저가 감춰 둔 "그래도 계속" 버튼을 대신 내놓지도 않습니다. 인증서가 잘못됐다면 Tabbit도 페이지를 막습니다. 그게 핵심입니다. 같은 보안 모델에 다른 환경을 씌우는 것이고, 통제된 비교에 필요한 것이 바로 그것입니다.
그 비교를 값싸게 만드는 요소가 세 가지 있습니다.
첫째는 준비 비용입니다. Tabbit은 macOS와 Windows에서 무료이고, 첫 실행 때 기존 브라우저의 북마크, 방문 기록, 확장 프로그램, 저장된 비밀번호를 가져옵니다. 시험해 보는 데 의존하던 환경을 다시 만들 필요가 없고, 진단 결과가 "기본 프로필이 문제"라면 필요한 깨끗한 프로필을 이미 가진 셈입니다. 그전에 백업을 해 두려던 참이었다면 먼저 그것부터 하세요.
둘째는 어떤 문구를 이해해야 하는 대목입니다. Tabbit의 사이드 패널은 열어 둔 페이지를 읽고 그 내용에 대해 답합니다. 입력창에는 탭, 스크린샷, 로컬 파일을 @로 참조할 수 있습니다. 해결이 사이트 상태 페이지나 IT 공지, 공급업체의 갱신 안내를 읽는 일에 달려 있을 때, 오류 문구를 검색창에 붙여 넣고 목록형 글을 걸러 보는 대신 그 자리에서 페이지에 대해 물어볼 수 있습니다.
셋째는 조사가 다른 일을 방해하지 않게 하는 것입니다. Agent Mode는 위임한 작업을 별도 탭 그룹에서 실행하므로, 사이트의 폼을 훑거나 호스트 목록을 확인하는 작업이 쓰고 있는 창을 차지하지 않습니다. 그 작업 도중에 경고가 나타나면 해당 작업의 그룹에 뜨고 사람을 기다립니다.
한계도 분명히 짚어야 합니다. Tabbit은 인증서를 믿을 수 있는지 판단해 주지 못합니다. 그 판단은 인증서 규칙과 브라우저의 신뢰 저장소에 속하고, 페이지를 읽는 도우미의 몫이 아닙니다. 서버를 고치지도 못합니다. 경고를 사라지게 만들지 않고, 만들어서도 안 됩니다. 인증서 오류를 알리지 않고 억누르는 브라우저는 기능이 아니라 보안 문제입니다. HTTPS를 검사하는 프록시 뒤의 관리형 기기라면 해결은 여전히 관리자의 몫입니다. Tabbit이 바꾸는 것은 진단이 일어나는 장소와, 그 검사를 돌리기 위해 쓰던 환경을 얼마나 건드려야 하는지입니다.
다음에 겪었을 때 순서대로 할 일
제목이 아니라 코드를 읽습니다. 페이지에서 유일한 진단 정보입니다.
범위를 시험합니다. 서로 관계없는 사이트 두세 곳을 열어 봅니다. 하나만 실패하면 사이트, 전부 실패하면 내 쪽입니다.
날짜와 시간을 자동으로 설정합니다. 30초면 되고,
NET::ERR_CERT_DATE_INVALID의 가장 흔한 클라이언트 측 원인입니다.일반
http://페이지를 열어 Wi-Fi 로그인 포털이 기다리고 있는지 확인합니다. 호텔, 공항, 카페에서 이 경고가 끊임없이 나옵니다.시크릿 창에서 열어 봅니다. 거기서 열리면 확장 프로그램이나 프로필이 차이를 만든 것입니다. 개인정보 보호와 추적 방지 기능이 사이트를 망가뜨리는 경우는 대부분이 생각하는 것보다 흔합니다.
호스트 이름 형태를 확인합니다.
www.를 붙인 주소와 뗀 주소를 모두 시도합니다. 이름 불일치는 두 번째로 흔한 서버 측 원인입니다.업무용 기기라면 멈추고 IT에 문의합니다. Chrome은 관리형 프록시의 HTTPS 가로채기가
NET::ERR_CERT_AUTHORITY_INVALID를 만들고, 프록시 인증서 설치에는 관리자가 필요하다고 문서에 적어 두었습니다. 직접 설치하지 마세요.사이트가 정말 고장 났다면 사이트에 알립니다. 의존하는 서비스의 만료된 인증서는 사용자가 신고할 때 더 빨리 고쳐집니다. Chrome의 안내도 같은 말로 끝납니다. 오류가 계속되면 웹사이트 소유자에게 문의하세요.
자격 증명을 입력하려고 경고를 넘기지 않습니다. 기다리거나, 앱을 쓰거나, 전화합니다. 상황이 달라져도 바뀌지 않는 단 하나의 단계입니다.
접속할 수 없는 사이트가 Chrome에서만 작동하던 곳이라면 원인 목록이 다른 별개의 조사입니다. 환자 포털이 가장 분명한 예입니다. 경고가 앱으로 설치되지 않는 페이지나 사라진 기능과 함께 왔다면 인증서 문제가 아닐 수도 있습니다. 앱으로 설치를 거부하는 사이트와 쓰던 브라우저가 계속 실패할 때 브라우저를 고르는 법이 그 갈래를 다룹니다.
짧은 답
"연결이 비공개로 설정되어 있지 않습니다"는 브라우저가 이 사이트가 주장하는 그 사이트인지 확인하지 못했다는 뜻입니다. 대다수는 갱신 누락, 어긋난 시계, 인증서와 맞지 않는 호스트 이름, 또는 일을 잘못 처리하는 프록시입니다. 공격을 받았다는 증거가 아닙니다.
그러니 위험을 넘겨 버릴 문제가 아니라 진단할 문제로 다루세요. 코드를 읽고, 한 사이트만 실패하는지 전부 실패하는지 시험하고, 시계를 자동으로 맞춘 다음에야 설정을 바꾸기 시작하세요. 경고는 설계된 대로 하고 있는 것이고, 실패한 쪽은 어떤 해결책이 해당하는지 알려 주지 않는다는 점입니다.
예외는 좁게 유지하세요. 경고를 넘겨 계속하는 것은 공개 정보 페이지에서는 작은 위험이고, 신원을 묻는 페이지에서는 불필요한 위험입니다. 판단을 인증서 규칙에 맡기는 브라우저가 경고를 사라지게 해 주겠다고 약속하는 브라우저보다 여기서 더 쓸모 있습니다.
Tabbit를 받고 경고를 의미 있게 유지하기
Tabbit Browser는 macOS 12 Monterey 이상과 Windows 10 64비트 이상에서 무료이고, 첫 실행 때 북마크, 방문 기록, 확장 프로그램, 저장된 비밀번호를 가져옵니다. 설치 파일은 tabbit.ai/download에 있습니다.
설치 전에 기대치를 정리해 두겠습니다. Tabbit은 인증서 경고를 대신 없애 주지 않고, 그럴 목적으로 만들지도 않았습니다. Chrome과 같은 검증을 실행하므로 잘못된 인증서는 여기서도 페이지를 막습니다. 이 문제에서 Tabbit이 주는 것은 1분이면 세울 수 있는 두 번째 환경, 페이지가 무슨 말을 하는지 물어볼 자리, 그리고 위임한 작업이 읽는 탭 밖에 머무는 작업 모델입니다. 연결 반대편에 누가 있는지에 대한 판단은 여전히 인증서 규칙과 여러분의 몫입니다.
자주 묻는 질문
「연결이 비공개로 설정되어 있지 않습니다」 경고가 뜨면 컴퓨터가 이미 감염된 걸까요?
아닙니다. 이 경고는 어떤 콘텐츠도 로드되기 전에 나타나고, 사이트가 아니라 브라우저가 직접 만든 것입니다. 경고 페이지에 도착하는 것만으로는 아무것도 설치되지 않습니다. 위험은 경고를 넘겨 계속한 뒤 브라우저가 검증하지 못한 연결에서 자격 증명을 입력하거나 파일을 내려받을 때 시작됩니다.
다른 사이트는 멀쩡한데 한 곳에서만 이 경고가 뜨는 이유는 무엇인가요?
한 사이트만 실패한다는 것은 내 기기가 아니라 그 사이트를 가리킵니다. 흔한 원인은 인증서 만료, 입력한 호스트 이름을 포함하지 않는 인증서, 해당 도메인에 맞지 않는 인증서를 내보내는 서버입니다. 브라우저는 추측을 거부하는 방식으로 올바르게 동작하고 있습니다.
휴대폰에서는 열리는데 컴퓨터에서는 안 열리는 이유는 무엇인가요?
두 기기는 인증서 검사에 영향을 주는 여러 면에서 다릅니다. 신뢰하는 루트 인증서가 다를 수 있고, 서로 다른 네트워크에 있을 수 있고, 날짜와 시간이 다를 수 있습니다. Chrome은 시계가 정확하지 않으면 `NET::ERR_CERT_DATE_INVALID`가 발생한다고 문서에 적어 두었고, 그러면 오래된 기기가 고장 난 웹사이트처럼 보입니다.
그래도 "계속 진행"을 눌러도 안전한 경우가 있나요?
공개 정보만 제공하고 로그인을 요구하지 않는, 위험이 적은 페이지라면 경우에 따라 그렇습니다. 사이트가 비밀번호, 결제, 신분 문서, 업무 시스템을 다룬다면 안전하지 않습니다. 무시하려는 검사의 목적이 그 데이터를 누가 받는지 확인하는 것이기 때문입니다.
다른 브라우저로 바꾸면 오류가 해결되나요?
확장 프로그램이 인증서 검사를 방해하거나 프로필이 손상된 것처럼 원인이 브라우저 안에 있을 때만 그렇습니다. 두 번째 브라우저는 진단 검사이지 수리가 아닙니다. 같은 사이트가 두 엔진에서 같은 오류 코드로 실패한다면 문제는 사이트나 네트워크에 있습니다.
요즘 이런 인증서 경고가 더 흔해진 것처럼 느껴지는 이유는 무엇인가요?
인증서 수명이 업계 규칙으로 짧아지고 있기 때문입니다. CA/Browser Forum 일정은 2026년 3월 15일부터 최대 200일로 정하고, 2027년에는 100일, 2029년에는 47일로 줄입니다. 수명이 짧아진다는 것은 손으로 갱신하는 모든 사이트가 잊어버릴 기회를 더 많이 갖는다는 뜻입니다.