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

האימות מתבצע בלקוח, עם עוגני הלקוח

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

לכן שרשרת מלאה מוכיחה שלשרת יש את החלקים. היא אינה מוכיחה שהלקוח יקבל אותם.

כדי לראות מה השרת באמת שולח, הרצו openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts וספרו את התעודות בפלט. שרשרת חסרה שם היא תיקון בצד השרת. שרשרת מלאה מעבירה את השאלה ללקוח ולעוגנים שלו, שם לשרת אין קול.

מה בדיקת TLS באמת משנה

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

ההסדר מכוון ומקומי. דבר בשרשרת של השרת המקורי אינו יכול לכפות על דפדפן לא מנוהל לקבל את הזהות החלופית, ודבר בה אינו מונע ממכשיר מנוהל לעשות כן.

סיום VPN אינו פענוח HTTPS

שכבת VPN נושאת מנות בין לקוח לשער. הסרתה, או קריאת התצורה שלה, אינה חושפת מטען HTTPS בפנים.

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

קבעו ציפיות ברכיב שאתם שולטים בו

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

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

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

מאמרים קשורים