כיצד OpenVPN פותר את האישור והמפתח: PEM מוטמע או נתיב

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

שתי צורות אחסון, הנחיה אחת

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

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

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

כיצד בלוק מוטמע הופך לאובייקט

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

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

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

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

כיצד נפתרת הפניה לנתיב

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

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

עבור אישור המאוחסן בנפרד, ניתוח לא מקוון מאשר את האובייקט לפני שתנפו משהו מעליו:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

מה שגיאת המפענח יכולה לומר ומה לא

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

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

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