크롬 연결 비공개 아님 인증서 오류 해결

 

 

크롬 연결 비공개 아님 인증서 오류 해결

솔직히, 2025년에 “연결이 비공개로 설정되어 있지 않습니다” 화면을 또 보게 될 줄은 몰랐습니다. 기본 중의 기본인 인증서 매칭조차 안 돼서 사용자에게 경고창을 던져놓고 “고급 → 계속 진행(안전하지 않음)”을 누르라고요? 게다가 사례를 보면 Subject가 “*.tistory.com”, 만료일은 2021-04-07, 경고는 net::ERR_CERT_COMMON_NAME_INVALID… 말 그대로 이름 불일치에 더해 만료까지! 이런 실수, 변명의 여지가 없습니다. 다만 분노는 분노대로, 해결은 해결대로 가야 합니다. 아래에 사용자와 운영자 모두를 위한 실전 해결 가이드를 정리했습니다. 빠르게 고쳐서 다시는 같은 일이 반복되지 않도록 합시다.

왜 이 경고가 치를 떨리게 하나요

“연결이 비공개로 설정되어 있지 않습니다”의 진짜 의미

• 크롬은 TLS 핸드셰이크 단계에서 서버 인증서의 도메인(SAN/CN)과 접속 도메인이 일치하는지 검증합니다.
• 일치하지 않거나 만료, 체인 오류가 있으면 중간자 공격(MITM) 위험이 있다고 봅니다. 그래서 경고를 띄우는 거죠.
• 메시지 예: “This server could not prove that it is interview.infodemic.kr; its security certificate is from *.tistory.com.”

이 사례에서 드러난 핵심 사실

• 오류 코드: net::ERR_CERT_COMMON_NAME_INVALID
• Subject: *.tistory.com (커스텀 도메인과 불일치)
• Issuer: Thawte TLS RSA CA G1
• Expires on: 2021-04-07 (이미 한참 전에 만료)
• 결과: 이름 불일치 + 만료의 이중 문제. 이쯤이면 사용자는 절대 ‘계속’ 누르면 안 됩니다.

왜 위험한가?

• 이런 상태에서 로그인·결제·개인정보 전송은 자살행위나 다름없습니다. 트래픽 탈취, 변조 가능성 배제 못 합니다.
• 특히 공용 Wi‑Fi, 사설 프록시, 기업 보안장비가 끼어 있으면 위험은 기하급수적으로 커집니다.

당장 하지 말아야 할 것

• “고급 → 안전하지 않음 연결 계속” 절대 금지!
• 경고를 무시하고 비밀번호 입력? 말도 안 됩니다. 브라우저는 장식이 아닙니다.

원인 분석: net::ERR_CERT_COMMON_NAME_INVALID

CN/SAN 불일치가 본질

• RFC 6125와 CA/B Forum Baseline Requirements에 따르면, 이제는 CN보다 SAN(Subject Alternative Name)을 기준으로 이름 검증을 합니다.
• *.tistory.com 인증서로 interview.infodemic.kr을 덮는 건 구조적으로 불가능합니다. SAN에 해당 도메인이 없으니까요.

만료/체인 문제의 덤

• 2021-04-07 만료라니요… 2025년에 이게 그대로 노출된다는 건 자동 갱신이 없거나 배포가 깨졌다는 뜻입니다.
• 중간 인증서(Intermediate) 누락, 잘못된 체인, 폐지(Revocation) 상태도 종종 함께 터집니다.

SNI/프록시/커스텀 도메인 설정 꼬임

• 같은 IP에 여러 호스트를 얹는 SNI 환경에서, 프록시/로드밸런서가 잘못된 인증서를 내보내면 도메인 불일치가 즉시 발생합니다.
• 티스토리·블로그·SaaS 커스텀 도메인은 “CNAME 설정 + 플랫폼 쪽에서 도메인 검증 후 자동 인증서 발급” 두 단계가 정상적으로 돌아가야 합니다.

클라이언트 측 이슈도 있다

• 시스템 시간 불일치(±5분만 어긋나도 검증 실패!)
• 기업형 HTTPS 검사(안티바이러스/프록시)가 자체 CA로 트래픽 복호화
• 공용 Wi‑Fi의 캡티브 포털(로그인을 유도하며 TLS를 가로챔)

사용자(방문자) 해결 체크리스트

1분 점검

• 주소 재확인: http → https 자동 리다이렉트 과정에서 피싱 도메인으로 튄 건 아닌지 확인하세요.
• 다른 네트워크로 재시도: LTE/5G로 바꾸거나, 공용 Wi‑Fi라면 당장 탈출!
• 시스템 시간 동기화
• Windows: 관리자 PowerShell에서 w32tm /resync
• macOS: 시스템 설정에서 자동 시간 설정 켜기
• Linux: timedatectl set-ntp true

고급 점검: HSTS, DNS, QUIC

• HSTS 정책 삭제(문제 사이트만) 1) 주소창에 chrome://net-internals/#hsts 2) Delete domain security policies에서 도메인을 입력 후 Delete
• DNS를 신뢰 가능한 제공자(DoH/DoT)로 전환 후 재시도
• 일시적으로 QUIC 비활성화 테스트
• chrome://flags → Experimental QUIC protocol → Disabled
• 문제 재현 후 다시 원복하세요.

보안 제품/프록시 영향 제거

• 백신의 “HTTPS 검사” 옵션 잠깐 꺼보고(테스트 후 반드시 복구)
• 기업망이라면 보안팀에 TLS 중간검사 정책과 CA 배포 상태 문의

언제 우회가 비교적 덜 위험한가?

• 민감 정보 전송이 전혀 없고, 단순 페이지 열람만 필요하며,
• 사이트 운영자 신원을 다른 채널로 확인했고,
• 내부망 등 신뢰 경로에서 일시적으로 접근할 때.
• 그 외엔? 우회 금지. 기본 방침은 “접속 중단”입니다.

운영자(관리자) 근본 해결

제대로 된 인증서 발급(SAN, ACME 자동화)

• SAN에 실제 도메인(예: interview.infodemic.kr)이 반드시 들어가야 합니다.
• 2025년 핵심 원칙: 자동화! ACME(Let’s Encrypt, Google Trust Services, ZeroSSL)로 60~90일 주기 갱신 파이프라인을 구축하세요.
• ECDSA(P‑256) + RSA(2048/3072) 듀얼 인증서도 고려하면 호환성과 성능을 동시에 잡습니다.

SaaS/티스토리/클라우드 환경에서의 정석

• 커스텀 도메인이라면 CNAME을 정확히 설정하고, 플랫폼의 도메인 검증이 완료될 때까지 대기해야 합니다.
• 플랫폼이 “Custom Hostname + 자동 인증서”를 제공하는지 확인. 없다면 Cloudflare SSL for SaaS, Fastly Compute@Edge 등으로 자체 오리진에 SSL을 얹으세요.
• SNI 라우팅, 인증서 번들(chain) 제공, OCSP Stapling 설정까지 확인 필수.

배포와 자동 갱신 파이프라인

• 인증서 및 키를 비밀관리(Vault, KMS)로 버전관리하고, 스테이징 → 프로덕션 무중단 교체(Blue/Green, Canary)로 운영하세요.
• 갱신 실패 알림을 걸어두세요. 만료 D‑14, D‑7, D‑1에 PagerDuty/슬랙 알람이 울리도록!

보안 강화 옵션

• TLS 1.3 우선, 불필요한 레거시 스위트 제거
• OCSP Stapling + Must‑Staple(가능 시)
• HSTS는 완벽히 안정화된 후 점진적 적용 → 프리로드는 마지막 단계
• HTTP → HTTPS 301 강제, 혼합콘텐츠 제거

실전: interview.infodemic.kr 사례 해부

증상 요약

• 서버가 interview.infodemic.kr임을 증명하지 못함.
• 제시된 인증서는 *.tistory.com, 심지어 2021-04-07 만료. 이건 완벽한 부적합 + 과실입니다.

재현과 진단

• 브라우저 보안 패널 확인
• 커맨드라인 진단

openssl s_client -connect interview.infodemic.kr:443 -servername interview.infodemic.kr -showcerts
openssl x509 -in server.crt -noout -text | grep -E "Subject:|DNS:"
curl -vI https://interview.infodemic.kr

• 기대값: Certificate chain이 신뢰 기준을 만족하고, SAN에 정확히 interview.infodemic.kr이 포함되어야 합니다.

바로잡는 절차

• DNS 확인: apex(A) 또는 CNAME이 실제 제공 사업자 지시대로 맞는지 재검증
• 플랫폼에서 커스텀 도메인 소유권 검증을 통과시키고, TLS 발급 상태를 “활성”으로 만들 것
• 직접 호스팅이라면 certbot 등으로 즉시 새 인증서 발급:

sudo certbot certonly --dns- -d interview.infodemic.kr
# 또는 Nginx 예시
ssl_certificate     /etc/letsencrypt/live/interview.infodemic.kr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/interview.infodemic.kr/privkey.pem;

• 로드밸런서/프록시 레벨에서 SNI별로 올바른 인증서 바인딩 재확인

복구 후 검증

• SSLLabs 서버 테스트(A 등급 목표), Hardenize로 종합 점검
• 혼합 콘텐츠, 리다이렉트 루프, HSTS 오작동 여부 확인
• 실사용자 모니터링(RUM)으로 오류율 지표 추적. 경고 재발 시 즉시 롤백/핫픽스

2025 보안 동향과 체크리스트

90일 유효기간 상시화

• 업계는 398일 → 90일 이하로 가속 중. 결과? 자동화 없는 운영은 사실상 불가능해졌습니다.
• Let’s Encrypt를 포함한 대다수 CA가 대규모 자동발급·갱신을 지원. “수동 갱신”은 더 이상 선택지가 아닙니다.

자동화/무중단 갱신

• GitOps/DevOps 파이프라인에 인증서 발급·배포를 편입하세요.
• 멀티리전·멀티엣지에서는 분산 캐시 갱신 지연으로 옛 인증서가 노출되기도 합니다. 전파 모니터링이 필수입니다.

브라우저 정책 강화

• 이름 검증은 SAN 중심. CN에만 도메인을 넣는 구식 방식은 신뢰 안 됩니다.
• 약한 암호 스위트·낮은 키 길이, SHA‑1 계열은 전부 차단. TLS 1.3 우선 정책이 보편화되었습니다.
• 혼합 콘텐츠, 불명확 리다이렉트, 취약한 리소스 로드에 대해 경고 수위가 올라갔습니다.

운영 가이드라인(핵심만!)

• “정확한 SAN + 자동 갱신 + 체인 완전성 + SNI 바인딩” 이 네 가지만 절대 놓치지 마세요.
• 장애는 대개 “사소한 오타와 누락”에서 시작됩니다. 체크리스트를 문서화하고 2인 이상 검증 프로세스를 두세요.

마무리 일침과 요청

책임 있는 운영

• 사용자에게 경고창을 떠넘기는 건 책임 회피입니다. 운영자는 올바른 인증서를, 올바른 방식으로, 제때 내보내야 합니다. 이건 선택이 아니라 의무입니다.

투명한 공지

• 문제가 발생했다면 복구 ETA, 영향 범위, 재발 방지 대책을 즉시 공개하세요. 침묵은 신뢰를 갉아먹습니다.

사용자를 위험에 밀어넣지 말 것

• “고급 → 계속”을 유도하는 문구, 이제 그만 보게 해주십시오. 기본을 지키면 해결됩니다. 이름이 맞는 인증서, 유효한 체인, 자동 갱신. 정말 어렵지 않습니다!

---

참고로, 공개 자료에 따르면 크롬의 HTTPS 사용률은 이미 90%를 훌쩍 넘었고, 대다수 인증서는 자동화로 발급·갱신되고 있습니다. 즉, 지금의 오류는 기술의 한계가 아니라 운영의 태도 문제에 가깝습니다. 더는 변명하지 말고, 오늘 당장 교정 작업에 들어가십시오. 사용자 데이터는 실험 대상이 아닙니다.