OpenVPN verify-x509-name: ההבדל בין subject, name ו-name-prefix

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

מה האפשרות בעצם קובעת

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

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

subject: השם המזהה המלא, תו אחר תו

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

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

name: שדה אחד, בדרך כלל השם הנפוץ

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

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

name-prefix: רחב מלכתחילה, ולכן צריך לתחום אותו

ציפייה מסוג name-prefix מתאימה לתחילת השדה הנבחר. זה נוח לתכנית שמות ומסוכן לכל דבר משותף.

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

בחרו את הסוג לפי המזהה, ואז הוכיחו אותו

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

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

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