תעודת VPN מחודשת: חלק מהלקוחות עדיין דוחים אותה

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

חידוש אחד, שתי התנהגויות

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

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

חידוש מחליף את האובייקט, לא רק את התאריך

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

קראו מה הלקוח מצמיד

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

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

השוו את התעודה שכל שרת עורפי מגיש

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

שנו את האמון דרך המסלול המנוהל

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

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