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-এর মধ্যে ফাইল সরানো তার ভূমিকা বেছে নেওয়ার নির্ভরযোগ্য উপায় নয়।