למה שני אישורי OpenVPN יכולים לחלוק מדיניות CCD אחת

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

השרת מכריע שם, לא מספר סידורי

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

כך עוברת בדיקת ייחודיות בצד ה-CA בעוד ה-VPN עדיין מתנגש. שתי הבדיקות עונות על שאלות שונות.

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

איזה שם המיפוי באמת משתמש בו

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

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

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

שני CA יכולים לאשר את אותו שם

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

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

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

חידוש הוא שימוש חוזר שמור, לא התנגשות

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

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

openssl x509 -in device42.crt -noout -subject -serial -issuer

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