Python Requests: CA-paket hör hemma i verify, inte i cert
Lägg godkänt CA-förtroendematerial i verifieringskonfigurationen i stället för att behandla ett certifikatfel som en begäran om klientens privata nyckel.
En kollega ger dig organisationens CA-certifikat. Requests erbjuder en parameter som heter cert. Namnen ser ut att höra ihop, men de svarar på olika frågor.
| Inställning | Syfte |
|---|---|
verify | Väljer det förtroendematerial som används för att verifiera motparten |
cert | Presenterar ett klientcertifikat med dess privata nyckel när klientautentisering krävs |
För en godkänd avlyssnings-CA kan en Requests-åtgärd välja det avsedda CA-paketet:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)Här är routes applikationens befintliga proxy-mappning. Sökvägen måste namnge rätt läsbart förtroendepaket för den här klienten. Det är inte ett nedladdat webbplats-certifikat som valdes bara för att anslutningen misslyckades.
Miljövariabeln REQUESTS_CA_BUNDLE är ännu en stödd förtroendekälla. Kontrollera den faktiska sändningsvägen om den verkar ineffektiv; arbetsflöden med förberedda förfrågningar och explicita inställningar kan ändra hur miljökonfigurationen slås samman.
Du borde inte behöva CA:ns privata nyckel
Det offentliga CA-certifikatet är vad en klient behöver för att känna igen en godkänd utfärdare. Dess privata signeringsnyckel är en annan parts kraftfulla hemlighet. Den bör inte distribueras till applikationsanvändare som en del av en rutinmässig proxy-förtroendereparation.
Ett klientcertifikat kan fortfarande krävas av en viss destination eller av en annan separat konfigurerad TLS-relation. Det är ett separat krav, inte något som härleds från varje certifikatverifieringsfel.
När nästa fel dyker upp, namnge åtgärden: läsa in en CA-fil, verifiera ett motpartscertifikat eller presentera en klientidentitet. Att flytta en fil mellan verify och cert tills meddelandet ändras är inte ett pålitligt sätt att välja dess roll.