מעקב אחר כשלי פרוקסי בבדיקות אישורי CRL ו-OCSP
עקבו אחר אחזור CRL או OCSP תחת חשבון המאמת כאשר היישום מגיע לפרוקסי שלו אך אימות האישור אינו יכול להסתיים.
בקשה לאתר יכולה להגיע לפרוקסי שלה ובכל זאת להיכשל משום שאימות האישור דורש בקשת רשת נוספת. אחזור CRL או OCSP עשוי לרוץ דרך רכיב פלטפורמה עם חשבון ומדיניות פרוקסי שונים מאלה של לקוח ה-HTTP של היישום.
התחילו בשגיאת השרשרת המדויקת. מבוטל פירושו משהו שונה מלא ניתן להשיג מידע ביטול עדכני. תפוגה ומנפיק לא מהימן הם שוב בעיות אחרות. רק כשל האחזור מחייב מעקב אחר מסלול חסר אל כתובת URL של סטטוס.
עבור אותו כשל, זהו שלושה דברים יחד: כתובת ה-URL הנאחזרת, הרכיב שמבצע את האחזור וזהות התהליך שלו. פתיחת כתובת ה-URL בהצלחה בדפדפן תחת החשבון האינטראקטיבי שלכם אינה מוכיחה ששירות יכול להזדהות מול אותו פרוקסי.
אם הרכיב שזוהה משתמש ב-WinHTTP, בדקו את המדיניות החלה עליו. תצורת פרוקסי סטטית והערכת פרוקסי אוטומטית לכל כתובת URL הן מנגנונים נפרדים. החילו את התצורה הנתמכת עבור החשבון המיועד; העתקת הגדרות דפדפן או שינוי סביבת ריצה לא קשורה עלולים להשאיר את האחזור בפועל ללא שינוי.
ב-.NET, UrlRetrievalTimeout במדיניות השרשרת שולט בהמתנה לאימות מקוון או לאחזור CRL. הארכת זמן התגובה הרגיל של HTTP אינה מאריכה את אותו טיימר, והארכת טיימר האחזור אינה מספקת אישורי פרוקסי או מסלול.
פרוקסי HTTPS יכול לחשוף תלות זו עוד לפני ה-TLS של היעד: האמון בחיבור הפרוקסי עשוי בעצמו לדרוש אחזור מידע ביטול. שחזרו את גישת האחזור הנתמכת ואת סידור האמון בשלב זה. השבתת בדיקת הביטול משנה את מדיניות האישורים; היא אינה משחזרת את האחזור שנכשל.