אישור עלה תקף, השרשרת פגה: קראו את העומק

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

העומק נוקב בשם האישור שנכשל

באבחון של OpenSSL, עומק 0 הוא אישור היעד ועומק 1 הוא המנפיק שחתם עליו, כאשר מספרים גבוהים יותר ממשיכים לעבר עוגן האמון. תפוגה המדווחת בעומק 1 אינה סותרת notAfter עדכני על העלה, ולכן בדיקה חוזרת של האישור הנראה לעין לעולם לא תסביר את השגיאה.

רשמו את טביעת האצבע של האישור שנכשל יחד עם ה-subject שלו, משום שאישורים שונים יכולים לשאת אותו שם CA. חתימה צולבת יוצרת בדיוק את המצב הזה: אותה רשות מופיעה יותר מפעם אחת, עם תאריכי תוקף שונים, והמאמת בחר בזה שלא ציפיתם לו. תווית מוכרת אינה מזהה, וטביעת אצבע היא מה שמבדיל בין שני אובייקטים החולקים שם.

שימו לב גם למוצרים עם יותר מתפקיד אישור אחד. ב-OpenVPN Access Server, האישורים המגנים על ממשקי האינטרנט נפרדים מאלה המשמשים לחיבורי VPN, ולכן דפדפן שפותח את דף הניהול אינו מוכיח דבר על נתיב המנהרה.

קלטי אמון אינם זהים למועמדי שרשרת

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

השבתת הנתיב ומאגר ברירת המחדל עם -no-CApath -no-CAstore שומרת על כנות הבדיקה: התוצאה תלויה אז בקבצים שציינתם, לא במה שתחנת העבודה בוטחת בו במקרה. מדריך האימות של OpenSSL מתעד את האפשרויות הללו ואת האבחון שהן מייצרות.

-show_chain מדפיס את השרשרת הבנויה כאשר האימות מצליח, וזה שימושי כדי לוודא שהנתיב הוא זה שהתכוונתם אליו. כאשר הוא נכשל, שמרו את העומק וה-subject המדווחים; שני השדות הללו אומרים לקורא הבא איזה אישור לבדוק.

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

מה הבדיקה מוכיחה ומה היא משאירה בחוץ

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

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

כדי לראות את חלון התוקף של כל אישור במקום אחד בכל פעם, הדפיסו אותם כסט:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

תקנו את הנתיב בלי להחליש את האימות

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

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

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