한국에서 HTTPS 인증서를 제공하는 웹사이트 171,510개 중 19%가 표준 인증서 검증에 실패한다.
이 사이트들로 연결되는 https:// 링크를 방문한 사용자는 "연결이 비공개로 설정되어 있지 않습니다" 오류를 접하게 된다.
실패 원인을 유형별로 분석한 결과, 대부분은 사이트 관리자가 명령어 두 개만으로 진단하고 쉽게 해결할 수 있는 몇 가지 흔한 설정 오류에서 비롯된다는 사실을 밝혀냈다.
측정 방식
페이지 요청을 보내지 않고 루트 도메인(bare domain)과 www. 서브도메인 모두에 대해 443번 포트로 단일 TLS 핸드셰이크를 시도하는 방식으로 국내 도메인 211,126개를 조사했다.
아래 분석에서는 (www. 접두사 유무와 관계없이) 두 호스트네임 중 하나라도 검증을 통과하면 해당 도메인을 신뢰할 수 있는 것으로 간주했다.
총 171,510개 도메인이 인증서를 응답하여 전달했다.
81%의 도메인은 검증을 통과했지만, 19%는 실패한 것으로 나타났다.
이 글에서는 검증에 실패한 도메인에 초점을 맞춘다.
취약한 암호화 알고리즘 부재
신뢰할 수 있는 인증서 전체에서 SHA-1이나 MD5 서명은 단 하나도 발견되지 않았으며, 2,048비트 미만의 RSA 키도 없었다.
취약한 암호 기술은 거의 예외 없이 신뢰할 수 없는 인증서에서만 발견되었으며, 특정 파일 유형에 집중되어 있었다. 검출된 MD5 서명의 99%는 교체되지 않은 기본(default) 인증서에서 발생했다.
1. 도메인 이름 불일치 (Common Name Mismatch)
NET::ERR_CERT_COMMON_NAME_INVALID
실패한 사이트의 절반 가까이(48%)가 다른 도메인 이름으로 발급된 CA 인증서를 제시했다.
이 중 절반가량은 호스팅 업체의 와일드카드(wildcard) 인증서를 그대로 제공하고 있었다.
가장 자주 발견된 호스팅 업체는 gabia.com, cafe24.com, gabia.io, godomall.com, anybuild.com이었다.
공유 서버에 해당 도메인 전용 인증서가 설정되어 있지 않으면 서버는 기본값으로 자체 인증서를 출력한다. 이것이 어떻게 발생하는지는 공유 호스팅에 관한 이전 글에서 자세히 다루었다.
- 전자상거래 플랫폼은 인증서를 자동 발급한다: 카페24 쇼핑몰과 NHN커머스의 고도몰에서는 도메인을 연결하면 무료로 인증서가 자동 발급된다.
- 웹호스팅(공유 호스팅)은 유료 옵션을 제공한다: 카페24 웹호스팅, 가비아, 블루웹은 신청과 비용 지불이 필요하며, 닷홈은 작성 시점 기준 월 2,000원을 부과한다.
2. 자체 서명된 인증서 (Self-signed certs)
NET::ERR_CERT_AUTHORITY_INVALID
실패한 사이트의 30%는 자체 서명된 임시(placeholder) 인증서를 제시했다. 이 중 83%(전체 실패 사이트의 4분의 1)는 동일한 단 하나의 인증서 파일 때문이었다.
Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Serial: 0
Signature: md5WithRSAEncryption
Valid: 2017-04-13 to 2117-03-20
Newbury, Berkshire, "My Company Ltd"는 Red Hat의 구형 OpenSSL 프롬프트에 포함된 기본 임시 값이다. 2017년 4월 13일에 생성된 이 동일한 기본 인증서가 약 1,087개 서버 주소에 일괄 복사되어 배치되어 있었다.
이 사이트의 대부분(87%)은 HTTP 전용 사이트로 정상 작동하고 있다.
세부 동작 방식은 다를 수 있으나, 일반적으로 방문자가 도메인을 입력하면 브라우저가 HTTP 사이트에 접속한 뒤 "안전하지 않음"(한국어 크롬에서는 "주의 요함")으로 표시한다. 반면 https:// 링크로 직접 접속을 시도하는 방문자는 전체 화면 경고 페이지를 마주하게 된다.
구글은 2025년 10월 발표를 통해 크롬 154 버전부터 해당 설정을 기본 활성화할 것이라고 밝혔다. 크롬 154는 2026년 9월 22일 정식 버전(stable channel)으로 출시되었다. 이 옵션이 활성화되면 크롬은 HTTPS가 적용되지 않은 공개 사이트에 접근할 때 사용자에게 먼저 승인을 요청한다.
- 실제 인증서 설치하기: 이전 섹션에 언급된 모든 호스팅 업체에서 인증서를 제공한다.
- 443 포트 서비스 중단하기: 유효한 인증서가 없다면 HTTPS 요청에 응답할 이유가 없다.
3. WWW 불일치 (WWW Mismatch)
웹사이트의 19.3%는 {domain}.com과 www.{domain}.com 설정이 일치하지 않았다. 두 주소 중 어느 한쪽에만 유효한 인증서가 설정되어 있는 상태다.
티스토리 개인 도메인 사례에서 이러한 패턴이 잘 드러난다. 465개 도메인이 2026년 3월 30일에 만료된 티스토리 자체의 *.tistory.com 인증서를 제시했다. 이 도메인 중 85%는 대체 호스트네임으로 접속할 때 정상 동작했다. 75%는 루트 도메인에서는 작동하지만 www.에서는 실패했고, 10%는 반대의 현상을 보였다.
티스토리 FAQ에 그 이유가 설명되어 있다. "티스토리 보안 인증서는 발급 시 작성한 주소 1개만 허용합니다."
이러한 불일치를 해결하는 방법은 다음과 같다.
- 두 호스트네임을 모두 커버하고 리다이렉트 처리하기
- 사용하지 않는 DNS 레코드 삭제하기
4. 불완전한 인증서 체인 (Incomplete Certificate Chain)
검증 실패 사이트의 9%는 신뢰할 수 있는 루트 인증 기관(Root CA)까지 연결되지 않는 인증서 체인을 전송했다.
이 사이트 중 44%는 자체 인증서만 단독으로 전송했으며, 나머지 56%는 중간 인증서를 포함했으나 여전히 신뢰할 수 있는 루트에 도달하지 못했다.
브라우저는 누락된 중간 인증서를 알아서 우회 처리하곤 한다. 크롬과 사파리는 누락된 중간 인증서를 자동으로 가져오며, 데스크톱 파이어폭스는 알려진 중간 인증서를 미리 로드해 둔다. 결과적으로 일반적인 데스크톱 브라우저 방문자는 경고를 거의 겪지 않는다.
그러나 브라우저가 아닌 클라이언트는 끊어진 체인을 복구하는 경우가 드물다. curl FAQ의 설명처럼 "웹 브라우저에서는 검증이 성공하지만 curl에서는 실패하는" 현상이 발생한다. 파이썬 스크립트, 자바 애플리케이션, 안드로이드 앱에서도 마찬가지로 실패한다.
빠른 해결 방법:
- 전체 인증서 체인을 전송하기! CA에서 제공한 풀 체인(full chain) 파일(서버 인증서 및 모든 중간 인증서 포함)을 전송하도록 서버를 설정한다.
5. 만료된 인증서 (Expired Certificate)
NET::ERR_CERT_DATE_INVALID
실패 사이트의 21%는 만료된 인증서를 사용하고 있었다. 이 중 42%는 2026년에 만료되었으며, 가장 오래전에 만료된 인증서는 2013년까지 소급된다.
수동 갱신은 앞으로 훨씬 더 어려워질 전망이다.
애플이 제안한 CA/브라우저 포럼의 Ballot SC-081안에 따라 2026년 3월 15일 이후 발급되는 인증서의 최대 유효기간은 200일로 줄어든다. 이 제한은 2027년 3월 15일부터 100일, 2029년 3월 15일부터는 47일로 단축된다.
단축되는 만료 주기에 대응하는 방법:
- 인증서 갱신 자동화하기 (최선의 방법): 호스팅 업체의 자동 갱신 기능을 사용하거나 Certbot 같은 ACME 클라이언트를 도입한다.
- 독자적으로 만료일 모니터링하기: 인증서 교체 담당 팀에 만료 알림이 발송되도록 설정한다.
내 사이트 점검하기
확실한 점검을 위해 아래 명령어를 루트 도메인과 www. 도메인에 각각 한 번씩 실행해 보는 것을 권장한다.
이 명령어들은 openssl CLI 도구를 사용한다.
웹 기반 검사를 원한다면 SSL Labs를 추천한다.
첫 번째 명령어는 검증 결과를 반환한다.
openssl s_client -connect example.com:443 -servername example.com \
-verify_hostname example.com </dev/null 2>/dev/null | grep 'Verify return code'
결과 해석 방법:
0 (ok): 도메인이 유효하며 정상 작동 중이다.- 출력 없음: 도메인이 443번 포트에서 TLS 핸드셰이크에 응답하지 않는다.
62 (hostname mismatch): 인증서 호스트네임 불일치.10 (certificate has expired): 만료된 인증서(호스트네임 불일치도 함께 발생할 수 있음).20또는21: 인증서 체인이 신뢰할 수 있는 루트에 도달하지 않음.18 (self-signed certificate): 도메인 이름으로 발급된 자체 서명 인증서.
그다음, 아래 명령어를 사용하여 인증서 상세 정보를 확인하고 문제의 원인을 찾아낸다.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
도메인이 주체(subject)나 대체 이름 목록(subjectAltName)에 포함되어 있지 않다면 검증에 실패한다.
참고 자료
- Panke — SNI 사례 연구: 설정 오류가 발생한 도메인 730개 (2026년 9월 29일)
- 카페24 — SSL 인증서는 어떻게 신청하나요? (쇼핑몰 도움말 921번 게시글)
- NHN커머스 — SSL 보안서버 관리 (고도몰 도움말)
- 카페24 — SSL 인증서 신청 FAQ
- 블루웹 — SSL 신청 절차
- 닷홈 — SSL 가격
- Red Hat — Red Hat Enterprise Linux 4 시스템 관리 가이드, 25.8. 자체 서명 인증서 생성
- 구글 보안 블로그 — HTTPS by default (2025년 10월 28일)
- 티스토리 — SSL 전면 적용 관련 FAQ (2019년 1월 16일)
- 가비아 — 고객센터 호스팅 매뉴얼 437/1961
- 모질라 보안 블로그 — Preloading Intermediate CA Certificates into Firefox (2020년 11월 13일)
- 애플 — SecTrustSetNetworkFetchAllowed(::)
- 크로미엄 — net/cert/cert_verify_proc_builtin.cc
- curl — 자주 묻는 질문(FAQ)
- 오라클 — Java PKI 프로그래머 가이드 (Java SE 21)
- 안드로이드 개발자 — 네트워크 프로토콜을 사용한 보안
- 크로미엄 — components/ssl_errors_strings.grdp
- CA/브라우저 포럼 — Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (2025년 4월 11일)
- Qualys — SSL Server Test
Instagram