Kolega przekazuje ci certyfikat CA organizacji. Requests oferuje parametr o nazwie cert. Nazwy wyglądają jak para, ale odpowiadają na różne pytania.

UstawienieCel
verifyWybiera materiał zaufania używany do weryfikacji drugiej strony
certPrzedstawia certyfikat klienta wraz z jego kluczem prywatnym, gdy wymagane jest uwierzytelnienie klienta

Dla zatwierdzonego CA przechwytującego operacja Requests może wybrać zamierzony pakiet CA:

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

Tutaj routes to istniejące mapowanie proxy w aplikacji. Ścieżka musi wskazywać właściwy czytelny pakiet zaufania dla tego klienta. To nie jest pobrany certyfikat witryny wybrany tylko dlatego, że połączenie się nie powiodło.

Zmienna środowiskowa REQUESTS_CA_BUNDLE to kolejne obsługiwane źródło zaufania. Sprawdź rzeczywistą ścieżkę wysyłania, jeśli wydaje się nieskuteczna; przepływy pracy z przygotowanymi żądaniami i jawne ustawienia mogą zmienić sposób scalania konfiguracji środowiska.

Nie powinieneś potrzebować klucza prywatnego CA

Publiczny certyfikat CA jest tym, czego klient potrzebuje, aby rozpoznać zatwierdzonego wystawcę. Jego prywatny klucz podpisujący jest potężnym sekretem innej strony. Nie powinien być rozpowszechniany wśród użytkowników aplikacji w ramach rutynowej naprawy zaufania proxy.

Certyfikat klienta nadal może być wymagany przez określony cel lub przez inną osobno skonfigurowaną relację TLS. To osobne wymaganie, a nie coś wywnioskowanego z każdego błędu weryfikacji certyfikatu.

Gdy pojawi się następny błąd, nazwij operację: ładowanie pliku CA, weryfikacja certyfikatu drugiej strony lub przedstawienie tożsamości klienta. Przenoszenie pliku między verify i cert, dopóki komunikat się nie zmieni, nie jest niezawodnym sposobem wybierania jego roli.

Powiązane artykuły