Python Requests: CA 번들은 verify에 두어야 하며 cert가 아닙니다
인증서 오류를 클라이언트 개인 키 요청으로 취급하지 말고 승인된 CA 신뢰 자료를 검증 구성에 두십시오.
동료가 조직의 CA 인증서를 건넵니다. Requests에는 cert라는 매개변수가 있습니다. 이름은 짝처럼 보이지만 서로 다른 질문에 답합니다.
| 설정 | 목적 |
|---|---|
verify | 상대방을 검증하는 데 사용할 신뢰 자료를 선택합니다 |
cert | 클라이언트 인증이 필요할 때 클라이언트 인증서와 개인 키를 제시합니다 |
승인된 가로채기 CA의 경우 Requests 작업은 의도한 CA 번들을 선택할 수 있습니다:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)여기서 routes는 애플리케이션의 기존 프록시 매핑입니다. 경로는 이 클라이언트에 맞는 올바른 읽기 가능한 신뢰 번들을 지정해야 합니다. 연결이 실패했다는 이유만으로 선택한 다운로드된 웹사이트 인증서가 아닙니다.
환경 변수 REQUESTS_CA_BUNDLE는 또 다른 지원되는 신뢰 입력입니다. 효과가 없어 보이면 실제 전송 경로를 확인하십시오. 준비된 요청 워크플로와 명시적 설정이 환경 구성이 병합되는 방식을 바꿀 수 있습니다.
CA의 개인 키는 필요하지 않아야 합니다
클라이언트가 승인된 발급자를 인식하는 데 필요한 것은 공개 CA 인증서입니다. 그 서명 개인 키는 다른 당사자의 강력한 비밀입니다. 일상적인 프록시 신뢰 수리의 일부로 애플리케이션 사용자에게 배포해서는 안 됩니다.
클라이언트 인증서는 특정 대상이나 별도로 구성된 다른 TLS 관계에서 여전히 요구될 수 있습니다. 그것은 별도의 요구 사항이며 모든 인증서 검증 오류에서 추론되는 것이 아닙니다.
다음 오류가 나타나면 작업을 구체적으로 말하십시오. CA 파일 로드, 상대 인증서 검증, 또는 클라이언트 신원 제시입니다. 메시지가 바뀔 때까지 파일을 verify와 cert 사이에서 옮기는 것은 그 역할을 선택하는 신뢰할 수 있는 방법이 아닙니다.