איזה צד של פרוקסי הבדיקה דחה את התעודה?

הלקוח סומך על פרוקסי הבדיקה המאושר. הבקשה עדיין נכשלת בגלל שגיאת תעודה. שתי העובדות יכולות להיות נכונות: לפרוקסי הזה יש מערכת יחסים נוספת של TLS לבדוק.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

בהסדר יירוט, המתווך מסיים את ה-TLS של הלקוח ויוצר חיבור משלו הלאה. הלקוח יכול לקבל את התעודה שמוצגת בצד שלו, בעוד הפרוקסי דוחה את התעודה שהוא מקבל מהאתר.

קראו את השגיאה של המאמת

קבעו איזה תהליך דיווח על השרשרת או שם המארח שנכשלו. דף שגיאה שהפרוקסי מייצר יכול להגיע ללקוח בהצלחה דרך חיבור תקין. שינוי נוסף של קובץ ה-CA של הלקוח אינו מעדכן את תצורת האמון של הפרוקסי כלפי מעלה.

לדוגמה, Mitmproxy מתעד אפשרויות אמון נפרדות כלפי מעלה, כולל ssl_verify_upstream_trusted_ca. המנהל המתאים יכול להגדיר אמון מאושר לשירות במעלה הזרם תוך שמירה על האימות. מוצר פרוקסי אחר זקוק לממשק המתאים שלו.

בדקו גם את שם היעד בפועל ואת השרשרת. שירות פרטי שחסר בו תווך, תעודה שפגה ומנפיק פרטי לא מוכר דורשים תיקונים שונים. חריגה מכוונת לשירות פרטי אחד לא צריכה להפוך בשקט לקבלה עולמית של כל תעודה.

מנהרת CONNECT רגילה שונה

מנהרת העברה אטומה אינה מפצלת את ה-TLS של היעד בדרך זו. היישום בדרך כלל מנהל ומאמת בעצמו את אותו מופע TLS מקצה לקצה. קבעו תחילה אם היירוט הוא באמת חלק מהמסלול, במקום להחיל הגדרות פרוקסי בדיקה על כל מתווך.

תעדו את שתי תוצאות האימות בנפרד. „התעודה של הפרוקסי מהימנה“ עונה על השאלה בצד הלקוח; היא אינה מעידה על מה שהפרוקסי ראה כשהתחבר כלפי מעלה.