פרוקסי HTTPS צריך לשלוח גם את שרשרת האישורים שלו
אבחנו אישורי ביניים חסרים במאזין ה-TLS מהלקוח אל Squid בנפרד מהאישור של אתר היעד.
אם לקוחות דוחים את פרוקסי ה-HTTPS לפני שהם מגיעים לאתר, בדקו את השרשרת שהמאזין של הפרוקסי שולח. ייתכן שאישור עלה תקף לבדו אינו מספק את אישורי הביניים שהלקוח צריך.
- זהו את נקודת הקצה הנבדקת. קראו את שם המארח בכתובת ה-URL של הפרוקסי המוגדרת ואת השגיאה של אותו חיבור. אישור המאזין חייב לכסות את השם הזה. אישור של אתר או אישור לכינוי IP אחר אינם יכולים להחליפו.
- בדקו את תצורת השרשרת של המאזין. תצורת OpenSSL הנתמכת ב-Squid יכולה לכלול אישורי ביניים בקובץ האישור. אשרו את הסידור במסמך הייחוס של המאזין עבור גרסת Squid המותקנת וה-TLS backend; התנהגות החבילות אינה אחידה. דוגמת מאזין ה-TLS של Squid 6.13 שומרת על אמון המאזין בנפרד מה-TLS של היעד.
- בדקו את אמון הלקוח בנפרד. שליחת אישורי ביניים עוזרת לבנות את השרשרת, אבל הלקוח עדיין צריך את עוגן האמון של השורש המיועד. ייבוא של כל שרשרת השרת למאגר שורשים בלי הבחנה הוא שינוי שונה מתיקון מה שהשרת שולח.
השאירו את האימות פעיל. הוא מזהה את פרוקסי ה-HTTPS שהלקוח התכוון להשתמש בו. לאחר שאותו חיבור יאומת, שגיאת אישור אתר מאוחרת שייכת להפעלת ה-TLS של היעד דרך הפרוקסי, עם חקירת שם המארח והאמון שלה.