기술 · 실용 가이드
Python SSLCertVerificationError: 신뢰를 바꾸기 전에 인증서 소유자를 확인하세요
검증을 켠 채 요청 이름, SNI, 피어 SAN, 발급자, 프록시 경로와 실제 CA 번들을 기록한 뒤 진짜 소유 구성 요소를 고칩니다.
SSLCertVerificationError는 하나의 근본 원인이 아니라 판정입니다. 체인, 만료, 시계, 호스트 이름, IP URL, 가상 호스트, HTTPS 프록시 또는 CA 경로가 원인일 수 있습니다.
첫 조치는 verify=False가 아닙니다. 같은 프로세스와 네트워크 경로에서 재현하고 요청 대상, 실제 응답자, 인증서 신원과 신뢰 저장소를 기록합니다.
실패 요청 고정
전체 URL과 포트, Python/OpenSSL 및 라이브러리 버전, 프록시 환경 변수, verify 또는 CA 설정과 전체 예외를 기록합니다. 증거를 CERTIFICATE_VERIFY_FAILED 한 줄로 줄이지 않습니다.
동일한 프로세스 신원과 네트워크 경로에서 재현합니다. 브라우저, curl, 컨테이너, 예약 작업과 가상 환경은 서로 다른 프록시나 신뢰 저장소를 쓸 수 있습니다.
체인보다 먼저 엔드포인트 식별
URL 호스트 이름, 연결 IP, SNI 이름과 HTTP Host 헤더를 따로 기록합니다. 일반 호출에서는 일치하지만 IP URL, 프록시 터널 또는 사용자 adapter에서는 나뉩니다.
TLS 인증서 선택과 호스트 이름 검증은 HTTP보다 먼저 일어납니다. Host 헤더만으로 IP를 기대한 TLS 신원을 DNS 이름으로 바꿀 수 없습니다.
검증 실패 분류
호스트 이름 불일치에서는 예상 이름과 피어 subjectAltName을 비교합니다. CA를 추가해도 누락된 이름은 생기지 않습니다. 체인 오류는 issuer path와 실제 CA 번들을, 유효 기간 오류는 실행 시계도 확인합니다.
issuer가 origin이 아니라 기업 보안 제품이면 승인된 HTTPS 프록시가 활성화됐는지 확인합니다. 기업 CA 신뢰는 관리 환경의 정책 결정입니다.
한 소유자만 수정
SAN에 운영 DNS 이름이 없으면 server를, 잘못된 identity를 요청했으면 URL/SNI를, 의도한 proxy가 소유자면 routing 또는 승인 CA를, 프로세스가 CA를 읽지 않았으면 library 설정을 고칩니다.
한 번에 하나만 바꾸고 verify=True를 유지합니다. private CA는 전용 Session 또는 PoolManager로 제한합니다.
성공과 거부 경로 검증
동일 요청을 반복하고 peer subject, SAN, issuer, 예상 이름, CA 출처와 proxy 상태를 기록하며 응답이 목표 서비스인지 확인합니다.
잘못된 호스트 이름, 승인되지 않은 root 또는 실패해야 할 무프록시 경로를 negative test로 추가해 거부가 유지되는지 증명합니다.
