תעודת VPN שטרם תקפה: שלושה גורמים, סדר בדיקה אחד
«טרם תקפה» פירושה שהשעון של המכשיר מפגר, שהחלון באמת מתחיל מאוחר יותר, או שתעודת ביניים טרם נפתחה. בדקו אותם בסדר הזה.
אתם פותחים את הלקוח, בוחרים את הפרופיל שבו השתמשתם חודשים, והוא נעצר עם "certificate is not yet valid". שום דבר בהתחברות שלכם לא השתנה, ומאגר האמון כנראה תקין: התעודה שמוצגת בלחיצת היד נושאת חלון תוקף שמתחיל מאוחר יותר מהרגע שבו משתמש המאמת. שלושה מצבים שונים מייצרים בדיוק את ההודעה הזו, והם דורשים פעולות שונות. הסדר שלמטה אומר לכם איזה מהם יש לכם לפני שאתם נוגעים בשעון או בקובץ תעודה.
איזה משלושת הגורמים אתם רואים
הגורם הראשון מקומי: במכשיר שמבצע את הבדיקה יש שעון מוקדם מתאריך ההתחלה של התעודה. רואים את זה בחומרה עם סוללת CMOS מתה, במכונות וירטואליות ששוחזרו מצילום מצב ישן, במכשירים שהיו כבויים מספיק זמן כדי לאבד את הזמן, וברשתות שבהן NTP יוצא חסום ואיש לא שם לב. התעודה יכולה להיות תקפה לחלוטין ובכל זאת להיכשל בדרך הזו.
הגורם השני שייך למנפיק, כי התעודה באמת מתחילה בעתיד: הונפקה מוקדם, נוצרה עם זמן התחלה מפורש, או נחתמה כחלק משלב הפעלה שטרם רץ. הגורם השלישי מבזבז את הזמן הרב ביותר, כי העלה עדכני בעוד שתעודה אחרת בשרשרת שהוצגה אינה, ולכן השגיאה מציינת חומר שמעולם לא התקנתם.
שאלה אחת מפרידה ביניהם. האם הכשל עוקב אחרי המכשיר או אחרי השירות? שתי מכונות באותה רשת שמתנהגות אחרת מצביעות על שעונים. כל לקוח שנכשל באותה דרך מצביע על החלון של התעודה ועל השרשרת שמאחוריו.
קראו את החלון מהתעודה שהוצגה בפועל
אל תבדקו קובץ PEM שנותר מפריסה קודמת; בקשו מהשירות את השרשרת שהוא שולח עכשיו. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts מדפיס כל תעודה בשרשרת. שמרו את הבלוק שמעניין אתכם והריצו openssl x509 -noout -subject -issuer -dates; האחרון מדפיס את notBefore ו-notAfter, ואלה שני הערכים שמכריעים. ב-Windows, דיאלוג התעודה של החיבור ו-certutil -dump על קובץ מיוצא מציגים את אותם שדות.
קראו את שני הקצוות של החלון, לא רק את ההתחלה. תעודה שנפתחת בעוד שעתיים ותעודה שנסגרת בעוד שעתיים נכשלות בהודעות שונות ומערבות צוותים שונים. שימו לב איזו תעודה השגיאה מציינת — עלה, ביניים או שורש — כי זה קובע אם אפשר לתקן משהו בצד הלקוח בכלל.
אפשר גם לבדוק את החלון בלי לחכות לו. האימות מקבל זמן מפורש: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem מעריך את השרשרת באותה חותמת זמן. הריצו אותו עם הזמן הנוכחי כדי לשחזר את הכשל, ואז עם זמן ההתחלה של התעודה כדי לאשר שאותה שרשרת עוברת ברגע שהחלון נפתח. RFC 5280 מגדיר את שדה התוקף ואת הכלל שאסור להשתמש בתעודה מחוצה לו, וזה בדיוק הכלל שהלקוח שלכם אכף זה עתה.
השעון שלכם או שלהם
השוו את שעון המכשיר לתחילת התעודה ב-UTC, ממקור שאתם סומכים עליו. date -u נותן את הרגע, ו-timedatectl status במארח systemd מדווח גם אם השעון מסונכרן. ב-Windows, w32tm /query /status מציג את המקור הנוכחי ואת הסנכרון המוצלח האחרון. אזור זמן שמוצג במגש הוא בחירת תצוגה, לא שעון שגוי; המאמת משווה רגעי UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
אם השעון מפגר, סנכרנו מחדש ובדקו שוב לפני שתשנו חומר תעודה כלשהו. מכשיר שסוטה בדקות או בשעות דוחה כל תעודה שהונפקה לאחרונה שהוא פוגש, לא רק שירות אחד, ולכן הסבר של שירות אחד הוא בדרך כלל השגוי. אם השעון נכון ומסונכרן, הפסיקו להסתכל על המכשיר: החלון שייך למנפיק, ואף הגדרה מקומית לא צריכה להשתנות כדי שהוא יעבור.
הטבלה הזו היא כל ההחלטה. להזיז את השעון למה שהתעודה מצפה לו אינו תיקון, וכיבוי בדיקות הזמן גם אינו תיקון, כי שניהם מסתירים את המצב שיצר את השגיאה.
למה השרשרת נכשלת בזמן שהעלה נראה תקין
עלים מחודשים ותעודות ביניים חלופיות נשלחים בדרך כלל יחד, והם לא תמיד נוחתים באותו רגע. שירות יכול לשלוח עלה חדש שנחתם על ידי תעודת ביניים שהחלון שלה עצמה מתחיל מאוחר יותר, או להמשיך להגיש תעודת ביניים ישנה יותר תחת עלה טרי. כך או כך השרשרת נכשלת בזמן שהתאריכים של העלה עצמו נראים סבירים.
נקודות קצה עם איזון עומסים הופכות את זה משבור ללא עקבי. אם ניסיון חוזר מצליח, או רשת אחת עובדת ואחרת לא, רשמו איזה עמית ענה ואיזו שרשרת הוא שלח לפני שתשנו הגדרות. openssl s_client מדפיס את הכתובת המחוברת, ולכן כמה ניסיונות חושפים אם כל צומת מגיש את אותה שרשרת.
מסלולי תיקון ששומרים על האימות
בעיית שעון מתוקנת במכשיר כשהאימות נשאר פעיל. בעיית תעודה מתקן המפעיל בחומר שהונפק לחלון שכבר כולל את עכשיו. שום הגדרת לקוח לא הופכת תעודה שטרם תקפה לתקפה; הדגלים שמדלגים על בדיקות זמן קיימים כדי לאשר אבחון, לא כדי להעלות אותם לפרודקשן.
כשהתעודה מוכנה להפעלה מתוכננת, פעלו לפי תוכנית המעבר. התקינו אותה כשהחלון שלה נפתח, או השתמשו בנוהל החפיפה שהספק מתעד, במקום להתקין מוקדם וללמד משתמשים ללחוץ דרך אזהרות. אזהרות שאנשים לומדים להתעלם מהן עולות יותר מעיכוב קצר.
לבסוף, בדקו שוב בדרך שבה הכשל קרה: הפעלה חדשה, אותו לקוח, המשאב שבאמת דרוש לכם. ספריות TLS עשויות לשמור שרשרת מאומתת במטמון לכל חיי החיבור, והפעלה מחודשת לא בהכרח בודקת אותה שוב, ולכן הפעלה ישנה יכולה להמשיך להיכשל אחרי התיקון או להמשיך לעבוד אחרי רגרסיה. קובץ שנפתח בצופה רק מוכיח שהקובץ קריא; לחיצת יד שהושלמה מוכיחה שהשרשרת מאומתת.
לפני שסוגרים את הפנייה, אשרו ארבעה דברים: זמן UTC ומצב הסנכרון של המכשיר שנכשל, ערכי notBefore ו-notAfter של כל תעודה בשרשרת שהוצגה, אותה שרשרת מלקוח שני, והשם שהשגיאה נותנת לתעודה. אם השעון נכון והחלון טרם נפתח, השאר הוא עבודת המפעיל, והצעד הנכון מצדכם הוא להמתין לחלון במקום להחליש את הבדיקה.