기술 · 실용 가이드
pip CERTIFICATE_VERIFY_FAILED? TLS를 우회하기 전에 신뢰 경로를 증명하세요
정확한 Python, pip 설정, 프록시 발급자와 CA 출처를 확인한 뒤 가장 작은 지원 계층을 고치고 우회 없이 원래 요청을 검증합니다.
pip TLS 실패는 하나의 만능 명령으로 해결되는 문제가 아니다. 잘못된 인터프리터, 숨은 설정, 가로채기 프록시, 불완전한 CA 체인, 오래된 백엔드, 다른 경로를 쓰는 격리 빌드가 같은 오류를 낼 수 있다. 안전한 첫 단계는 실제 프로세스와 신뢰 출처를 확인하는 것이다.
실패한 프로세스와 요청을 고정
`python -m pip ...`로 재현하고 실행 파일, OpenSSL, pip 버전을 기록한다. 정확한 인덱스 호스트와 주 설치·의존성 해결·격리 빌드 중 어디서 실패했는지도 적는다. 브라우저 성공은 Python이 같은 신뢰 저장소나 프록시를 쓴다는 증거가 아니다.
수정 전에 설정을 공개
`python -m pip config debug`로 보이는 파일과 값을 확인하고 CA, 프록시, 인덱스 환경 변수를 점검한다. 자격 증명은 공개하지 않는다. 사용자 파일, 가상환경 파일, 환경 변수가 예상한 값을 덮을 수 있다.
발급자와 CA 백엔드를 식별
공개 CA, 조직 프록시, 예상치 못한 중간 인증서 중 누가 체인을 발급했는지 확인한다. 지원되는 최신 조합은 truststore를 통해 시스템 인증서와 certifi를 쓰지만 pip와 Python 버전에 따라 다르며 명시적 CA 파일도 경로를 바꾼다.
가장 작은 지원 수리를 선택
인터프리터가 다르면 목표 Python을 호출하고 버전이 너무 오래되면 허용된 유지보수 경로에서 업그레이드한다. 조직 TLS 검사라면 관리자로부터 루트 인증서를 받아 OS 신뢰 저장소나 승인 CA 번들에 넣는다. 잘못된 프록시나 인덱스는 근원에서 고친다.
우회는 진단으로만 사용
trusted-host나 검증 해제는 인증서 검증이 경계임을 보여 줄 뿐 서버 신원을 증명하거나 체인을 고치지 않는다. 전역 설정, 이미지, CI, 복사 명령에 남기지 말고 임시 시험 뒤 바로 제거하며 비밀 자료를 공개 이슈에 올리지 않는다.
새 프로세스에서 완료 검증
새 셸이나 재구성 환경에서 우회 없이 같은 요청을 실행하고 설정을 다시 본다. 목표 인터프리터와 CA 출처, 직접 의존성과 빌드 의존성이 모두 작동하는지 확인한다. 격리 빌드만 실패하면 별도 프로세스 경계의 증거로 남긴다.
