remote-cert-tls server: מה הוא בודק בפרופיל OpenVPN
ההנחיה בודקת את התפקיד המקודד בתעודת העמית, לא את שמה. השוו תפקיד, עוגן אמון ובדיקת שם מארח לפני שמשביתים משהו.
שלוש שאלות שונות נענות על ידי שלושה חלקים שונים בפרופיל OpenVPN, ומיזוגן הוא הדרך שבה אנשים בסופו של דבר מכבים בדיקה שעבדה. האם תעודת העמית חתומה על ידי הרשות שאני סומך עליה? האם התעודה הזו מצהירה על תפקיד שרת TLS? האם זה השרת המסוים שאליו התכוונתי להגיע? remote-cert-tls server עונה רק על השאלה האמצעית, והוא עושה זאת על ידי קריאת הרחבות בתוך התעודה.
שלוש בדיקות שקל למזג בראש
עוגן האמון נמצא בהנחיה ca. בדיקת התפקיד שייכת ל-remote-cert-tls. בדיקת הזהות שייכת ל-verify-x509-name, כאשר פרופיל משתמש בה, או לכל בדיקת שם שהפריסה מוסיפה.
הן מכסות כשלים שונים:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
לפרופיל יכולות להיות כל השלוש ועדיין להיות חלש אם ה-CA משותף רחב מדי, וזו שאלה של ניהול מפתחות ולא של הנחיה.
מה בדיקת התפקיד קוראת
ההנחיה היא מאקרו. היא נפרשת לדרישת שימוש במפתח ולדרישת שימוש מורחב במפתח שמציינת את תפקיד שרת האינטרנט של TLS, ולכן תעודת העמית חייבת להצהיר על המטרה הזו בפועל. תעודה שהונפקה לאימות לקוח אינה עומדת בה, גם כאשר אותה רשות חתמה על שתיהן.
זה חשוב משום ש-CA משותף נפוץ בפריסות קטנות. רשות אחת חותמת על כל לקוח ועל השרת, ובלי בדיקת תפקיד כל אחת מהתעודות האלה הייתה יכולה להשלים את צד השרת של לחיצת היד. הבדיקה לא הופכת את התרחיש לבלתי אפשרי, אבל היא מסירה את הגרסה הטריוויאלית שלו.
ההנחיה א-סימטרית בתכנון: לקוחות נושאים remote-cert-tls server, ושרתים נושאים remote-cert-tls client. החליפו ביניהם וכל חיבור ייכשל בשגיאת תפקיד שנראית כמו תעודה שבורה.
פרופילים ישנים משתמשים לפעמים ב-ns-cert-type לאותה מטרה. עמודי המדריך הנוכחיים מתייחסים לאפשרות הזו כאל מיושנת, ולכן פרופיל שעדיין נשען עליה שווה הגירה ולא ניפוי באגים.
למה השבתתה מרגישה כמו תיקון
כשבדיקת התפקיד נכשלת, החיבור נעצר בשגיאת אימות והמהלך המתבקש הוא למחוק את השורה. אז החיבור עולה, מה שמרגיש כמו התקדמות והוא למעשה מצב הכשל שההנחיה קיימת כדי למנוע. עכשיו אתם מקבלים עמית שהתעודה שלו מעולם לא נועדה לתפקיד הזה.
קראו את השגיאה במקום. היא מציינת את הבדיקה שנכשלה, ואת התעודה בצד השני אפשר לבדוק כדי לראות אילו הרחבות היא באמת נושאת. שתי דקות של קריאה מכריעות אם התקלה היא בהנפקה או בתצורה. ניחוש עולה אחר צהריים ובדרך כלל מסתיים בפרופיל מוחלש. תעודת שרת מחודשת שאיבדה את השימוש המורחב במפתח היא תקלה אמיתית בחידוש, לא סיבה להרפות מהלקוח.
בדיקת השם היא הנחיה נפרדת
עמידה בבדיקת התפקיד אומרת שהעמית הוא איזה שרת חתום על ידי הרשות שלכם. היא לא אומרת דבר על איזה, וזה חשוב כאשר אותו CA מנפיק תעודות לכמה שערים ואחד מהם נפרץ או הוסב מחדש.
verify-x509-name משווה את נושא התעודה לערך שאתם מגדירים, עם מצבי התאמה לנושא מדויק, לתחילית או לשדה יחיד. השתמשו בשדה שמזהה את השער בפועל, וצפו לעדכן אותו בכוונה כשהשם משתנה.
אף אחת מההנחיות לא מחליפה טיפול טוב במפתחות. אם קובץ מפתח הלקוח מועתק סביב עם הפרופיל, זהות העמית חזקה רק כמו רשימת ההפצה.
בדקו את התעודה לפני שעורכים את הפרופיל
קראו את תעודת העמית ואת יומן הלקוח, בסדר הזה. התעודה מספרת אילו תפקידים היא מצהירה; היומן מספר איזו בדיקה דחתה אותה.
הפקודות האלה מדפיסות את הרחבות השימוש ואת שורות האימות מחיבור מפורט:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyאם ההרחבות מראות את תפקיד השרת והיומן עדיין מדווח על כשל תפקיד, הפרופיל כנראה מצביע על קובץ התעודה הלא נכון ולא על תעודה רעה. אם ההרחבות מראות רק אימות לקוח, הפסיקו להסתכל על הלקוח ותקנו את ההנפקה. בכל מקרה, החזירו את הבדיקה לפני שאתם קוראים לחיבור בריא, כי לחיצת יד מוצלחת אחרי הסרת האימות מוכיחה פחות מהשגיאה שהיא החליפה.