Un collega vi consegna il certificato CA dell'organizzazione. Requests offre un parametro chiamato cert. I nomi sembrano coincidere, ma rispondono a domande diverse.

ImpostazioneScopo
verifySeleziona il materiale di fiducia usato per verificare la controparte
certPresenta un certificato client, con la sua chiave privata, quando è richiesta l'autenticazione del client

Per una CA di intercettazione approvata, un'operazione Requests può selezionare il bundle CA previsto:

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

Qui routes è la mappatura proxy esistente dell'applicazione. Il percorso deve indicare il bundle di fiducia leggibile corretto per questo client. Non è un certificato di sito web scaricato e scelto solo perché la connessione è fallita.

La variabile d'ambiente REQUESTS_CA_BUNDLE è un'altra fonte di fiducia supportata. Controllate il percorso di invio effettivo se sembra inefficace; i flussi di richieste preparate e le impostazioni esplicite possono modificare il modo in cui viene unita la configurazione dell'ambiente.

Non dovresti aver bisogno della chiave privata della CA

Il certificato CA pubblico è ciò di cui un client ha bisogno per riconoscere un emittente approvato. La sua chiave privata di firma è un segreto potente di un'altra parte. Non dovrebbe essere distribuita agli utenti dell'applicazione come parte di una riparazione ordinaria della fiducia del proxy.

Un certificato client può comunque essere richiesto da una destinazione particolare o da un'altra relazione TLS configurata separatamente. È un requisito separato, non qualcosa che si deduce da ogni errore di verifica del certificato.

Quando compare l'errore successivo, nominate l'operazione: caricare un file CA, verificare un certificato di controparte o presentare un'identità client. Spostare un file tra verify e cert finché il messaggio non cambia non è un modo affidabile per sceglierne il ruolo.

Articoli correlati