חידוש תעודת VPN מבלי לשנות את הזהות שלה

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

שלושה תנאים קובעים את צורת החידוש

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

התחל בבדיקת התעודה שיש לך. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName מדפיס את הנושא, המנפיק, חלון התוקף והשמות שהתעודה תקפה עבורם בפועל. השדה האחרון הוא החשוב ביותר וגם זה שהכי מניחים אותו מראש: בקשת חידוש שמשמיטה SAN שהלקוח מסתמך עליו מייצרת תעודה שתקפה טכנית אך שגויה תפקודית. העתק את רשימת ה-SAN מהתעודה הישנה אל הבקשה במקום להקליד אותה מחדש מהזיכרון.

תנאי ראשון: האם משהו נועל את העלה

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

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

תנאי שני: השווה את הנעילות ואת השרשרת

טביעות אצבע הופכות את הנעילה לבדיקה: openssl x509 -noout -fingerprint -sha256 -in server.crt על התעודה הישנה והחדשה, ו־openssl x509 -noout -pubkey כדי להשוות מפתחות ציבוריים. אם תצורת הלקוח, פרופיל נייד או מאגר אמון של מכשיר מכיל אחד מהערכים, יש לך נעילה. פרופילי VPN ניידים הם מקום מחבוא נפוץ, כי הפרופיל מופץ פעם אחת ולא נבדק שוב.

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

בדוק את השרשרת שהשרת באמת שולח עם openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, ואמת אותה מקומית עם openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. עשייה כזאת לפני השינוי נותנת לך קו בסיס להשוות אליו אחר כך.

תנאי שלישי: מי עוד מאמת את השם

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

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

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

פרס, אמת עם אימות חדש, ואז הוצא משימוש

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

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

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