למה cryptoapicert נכשל ב-OpenVPN 3 וב-Connect ב-Windows

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

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

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

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

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

מה ספריית הליבה חושפת במקום

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

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

מה עושה במקום החזית של Windows

OpenVPN Connect הולך בדרך אחרת: המפעיל מייבא קובץ PKCS#12 המכיל את התעודה ואת המפתח הפרטי שלה אל OpenVPN Certificate Store שנוצר למטרה זו, ואז מקצה את התעודה החיצונית לפרופיל. זהו שלב ייבוא מכוון, ולא גילוי אוטומטי של מה שמקרה נמצא במאגר האישי. ההבחנה חשובה כשמישהו מניח שתעודה שהותקנה למטרה אחרת פשוט תופיע ברשימת הלקוח.

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

בחרו מסלול שמתאים למדיניות של המפתח

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

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

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