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 הוא מיפוי ה-proxy הקיים של היישום. הנתיב חייב לציין את צרור האמון הנכון והקריא עבור לקוח זה. זו אינה תעודת אתר שהורדה ונבחרה רק מפני שהחיבור נכשל.
משתנה הסביבה REQUESTS_CA_BUNDLE הוא מקור אמון נתמך נוסף. בדקו את נתיב השליחה בפועל אם הוא נראה לא יעיל; זרימות עבודה של בקשות מוכנות והגדרות מפורשות יכולות לשנות כיצד תצורת הסביבה ממוזגת.
לא אמור להיות לכם צורך במפתח הפרטי של ה-CA
תעודת ה-CA הציבורית היא מה שלקוח צריך כדי לזהות מנפיק מאושר. המפתח הפרטי לחתימה שלה הוא סוד עוצמתי של צד אחר. אין להפיץ אותו למשתמשי היישום כחלק מתיקון שגרתי של אמון proxy.
תעודת לקוח עדיין עשויה להידרש על ידי יעד מסוים או על ידי קשר TLS אחר שהוגדר בנפרד. זו דרישה נפרדת, לא משהו שנגזר מכל שגיאת אימות תעודה.
כאשר מופיעה השגיאה הבאה, תנו שם לפעולה: טעינת קובץ CA, אימות תעודת עמית או הצגת זהות לקוח. העברת קובץ בין verify ל-cert עד שההודעה משתנה אינה דרך אמינה לבחור את תפקידו.