כניסות VPN חדשות נכשלות בזמן שהתעודות תקפות: בדקו את ה-CRL

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

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

שני שעונים, ורק אחד מהם הוא התעודה

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

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

קראו את הרשימה שהשירות באמת טוען

התחילו מהתצורה שרצה ולא מהקובץ שאתם מצפים לו. הנתיב של crl-verify יכול להיות מוחלט, יחסי לפרופיל, או עותק שנאפה בתוך תמונה, והמאמת קורא את העותק הזה. בדקו אותו במקומו עם openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate והשוו את התאריכים לשעון השרת.

לאחר מכן אשרו שהקובץ הוא באמת הקובץ שבשימוש: בדקו את החתימה שלו עם openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, שמדווח על תוצאת אימות במקום להדפיס שדות בשקט. רשימה שנחתמה על ידי CA אחרת, או עותק מיושן שנשאר בתיקייה שנייה, נכשלת בדיוק כמו רשימה שפגה.

צרו מחדש מבסיס הנתונים של הביטולים, לא מאפס

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

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

פרסו היכן שהמאמת מסתכל

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

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

הפכו את המועד הבא לגלוי לפני שהוא חולף

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

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