Python Requests: CA बंडल verify में रहते हैं, cert में नहीं

एक सहकर्मी आपको संगठन का CA प्रमाणपत्र देता है। Requests 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 के बीच फ़ाइल खिसकाना उसकी भूमिका चुनने का विश्वसनीय तरीका नहीं है।