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

אובדן קובץ אינו אובדן הרשומה של ה-CA

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

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

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

קראו קודם את המנפיק ואת הסידורי

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

השוו את הערכים לרשומות ה-CA ולמכשיר או לאדם שלדעתכם מחזיק בתעודה.

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

למה ביטול התעודה החדשה לא עושה דבר

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

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

שתי הטעויות נובעות מהתייחסות לשם כאל הזהות.

בטלו את התעודה שהמספר הסידורי מציין

זהו את האובייקט לפני שאתם נוגעים ב-CA: openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates מדפיס את ארבעת הערכים במעבר אחד, והמספר הסידורי הוא מה שמתאימים לארכיון ה-CA. Easy-RSA שומר את הארכיון תחת pki/certs_by_serial, עם קובץ אחד לכל מספר סידורי. פקודת הביטול מקבלת שם נפוץ ולא מספר סידורי, לכן העתיקו את הקובץ המאוחסן אל pki/issued/<common-name>.crt ותנו לשם להצביע על האובייקט שזיהיתם. הריצו easyrsa revoke <common-name> מספריית ה-PKI, ואז בדקו שהשורה המתאימה ב-index.txt עברה ל-R. המספר הסידורי הוא הדרך לבחור את האובייקט, לא ארגומנט שהפקודה מקבלת.

openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates
cp pki/certs_by_serial/A1B2C3D4.pem pki/issued/client-01.crt
./easyrsa revoke client-01
grep -n client-01 pki/index.txt
./easyrsa gen-crl

אם index.txt אינו מציג R, עצרו וקראו את השגיאה לפני יצירת CRL, משום ש-CRL שנבנה מרשומה שעדיין בתוקף אינו מושך דבר. רק לאחר שהשורה משתנה תריצו easyrsa gen-crl ותעברו להפצת הקובץ.

פרסמו את ה-CRL במקום שבו הוא נאכף בפועל

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

קובץ מעודכן שיושב על ה-CA לא משנה דבר, משום שה-VPN מסיים את ההחלטה במאמת שלו עצמו. בדקו את המנפיק של ה-CRL, את תקופת התוקף ואת המספרים הסידוריים שבוטלו, וודאו שהשירות טוען מחדש את הקובץ ולא שומר במטמון את הקודם. בעלות ונתיב חשובים כמו התוכן: CRL שהדמון אינו יכול לקרוא אינו נבדל מהיעדר CRL. האפשרות crl-verify של OpenVPN מציינת את הקובץ שהדמון קורא, לכן בדקו את הנתיב הזה ואת בעלות הקובץ בתצורת השרת.

אמתו בניסיון חיבור אמיתי, לא בחותם הזמן של הקובץ.

דעו מתי CRL הוא הכלי הלא נכון

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

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

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

מאמרים קשורים