שגיאות אישור SSL לאחר הפניות עם חבילת CA מותאמת
בדקו אם קובץ ה-CA שנבחר במפורש מכיל את כל חומר האמון שנדרש לנתיב הבקשה בפועל, כולל מארחים שהופנו.
קובץ ה-CA של החברה מתקן את כתובת ה-URL הראשונה, ואז הפניה נכשלת באימות. בדקו אם אפשרות ה-CA המותאמת החליפה את קלט האמון הקודם של הלקוח במקום להוסיף לו.
התנהגות זו תלויה ב-backend של TLS ובאפשרות. קובץ שמכיל רק את ה-CA הארגוני עלול להשאיר את הלקוח בלי רשויות אחרות שהוא צריך.
- עקבו אחרי כל עמית. ייתכן שהמארח הראשון מיורט תחת המנפיק הארגוני. מארח מאוחר יותר יכול להשתמש בעקיפה, בנתיב בדיקה אחר או בשרשרת שהונפקה באופן ציבורי.
- תעדו את הקלטים של הלקוח שנכשל. שמרו את שם המארח המבוקש, יעד ההפניה, המנפיק שהתקבל, תוצאת האימות ותצורת האמון שנבחרה. דפדפן עובד עשוי להשתמש במאגר שורשים אחר.
- בדקו את כללי הבחירה של ה-backend. בניות curl יכולות להשתמש באימות מקורי או בשורשים מבוססי קבצים, ואפשרויות CA מפורשות יכולות לשנות את הבחירה. מתכון לאותו קובץ הרצה אינו מגדיר סביבת Python או JVM.
השתמשו בחבילה מתוחזקת או בסידור מאגר אמון נתמך שמכיל את הרשויות הציבוריות והפרטיות שהאפליקציה אמורה לבטוח בהן. אל תוסיפו מפתח פרטי של CA ואל תקדמו כל תעודת עלה שנכשלת לשורש רק כדי לנקות את השגיאה הבאה.
אספקו את חומר האמון דרך נתיב העדכון הנתמך של הפריסה. החלפה ידנית של חבילת CA של ספק עלולה להתבטל בעדכון הבא שלה; השאירו את הבעלים ותהליך התחזוקה מפורשים כדי שהאימות יימשך לאורך כל מסלול הבקשה.