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 کے درمیان فائل منتقل کرنا اس کا کردار چننے کا قابل اعتماد طریقہ نہیں ہے۔