Python Requests: بستههای CA جایشان در verify است، نه cert
مواد اعتماد CA تأییدشده را در پیکربندی بررسی قرار دهید، نه اینکه خطای گواهی را درخواست کلید خصوصی کلاینت تلقی کنید.
همکاری گواهی CA سازمان را به شما میدهد. Requests پارامتری به نام cert ارائه میکند. نامها شبیه هم به نظر میرسند، اما به پرسشهای متفاوتی پاسخ میدهند.
| تنظیم | هدف |
|---|---|
verify | مواد اعتماد مورد استفاده برای بررسی طرف مقابل را انتخاب میکند |
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 تا زمانی که پیام تغییر کند، روش قابل اعتمادی برای انتخاب نقش آن نیست.