שני תעודות OpenVPN, שם CCD אחד: מה השתבש

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

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

כלי התעודות שלכם לא יזהרו אתכם, מפני שייחודיות בתוך X.509 וייחודיות של שם מדיניות OpenVPN הן דרישות שונות שנאכפות על ידי מערכות שונות.

השרת מחפש שם, לא טביעת אצבע

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

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

כששתי רשויות מתאימות לאותו שם

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

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

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

הקצו את השם האפקטיבי לפני החתימה

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

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

החידוש עושה שימוש חוזר בשם בכוונה

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

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

אמתו את המיפוי עם הכלים שעל המכונה

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

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

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

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