Un compañeiro dálle o certificado CA da organización. Requests ofrece un parámetro chamado cert. Os nomes parecen coincidir, pero responden a preguntas distintas.

AxustePropósito
verifySelecciona o material de confianza usado para verificar o par
certPresenta un certificado de cliente, coa súa clave privada, cando se require autenticación de cliente

Para unha CA de intercepción aprobada, unha operación de Requests pode seleccionar o paquete CA previsto:

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

Aquí routes é a asignación de proxy existente da aplicación. A ruta debe nomear o paquete de confianza lexible correcto para este cliente. Non é un certificado de sitio web descargado e escollido só porque a conexión fallou.

A variable de contorno REQUESTS_CA_BUNDLE é outra entrada de confianza admitida. Comprobe a ruta de envío real se parece ineficaz; os fluxos de solicitudes preparadas e os axustes explícitos poden alterar como se fusiona a configuración do contorno.

Non debería necesitar a clave privada da CA

O certificado CA público é o que un cliente necesita para recoñecer un emisor aprobado. A súa clave privada de sinatura é un segredo poderoso doutra parte. Non debería distribuirse aos usuarios da aplicación como parte dunha reparación rutineira da confianza do proxy.

Un certificado de cliente aínda pode ser requirido por un destino concreto ou por outra relación TLS configurada por separado. Iso é un requisito aparte, non algo inferido de cada erro de verificación de certificado.

Cando apareza o seguinte erro, nomee a operación: cargar un ficheiro CA, verificar un certificado de par ou presentar unha identidade de cliente. Mover un ficheiro entre verify e cert ata que cambie a mensaxe non é unha forma fiable de escoller o seu papel.

Artigos relacionados