איזה קובץ CA נכנס לפרופיל OpenVPN עם סיסמה בלבד?
שדה ה-CA מאמת את השרת, לא את המשתמש. ראו מה הפרופיל כבר מכיל, הפרידו את ארבעת סוגי החומר וקראו את השגיאה הבאה.
עברו על ארבע שאלות לפי הסדר והדיאלוג של CA מפסיק להיות דו-משמעי. איזה חומר הנפיק המפעיל בפועל, מה הפרופיל כבר מכיל, איזה שדה שואל, ומה קורה אחרי שהקובץ נטען? עצרו בשאלה הראשונה שאינכם יכולים לענות עליה מתוך ההוראות של המפעיל עצמו, כי ניחוש מעבר לה הוא הדרך שבה תעודת CA ציבורית נמצאת מזווגת למפתח פרטי שמעולם לא היה אמור לעזוב את השרת.
הסדר חשוב: לשתי השאלות האחרונות יש משמעות רק כשיודעים איזה חומר אמור להתקיים.
התחילו במה שהפרופיל כבר מכיל
פתחו את הפרופיל בעורך טקסט וחפשו בלוק ca לפני שאתם מחפשים קובץ. בלוק ca מוטבע שמכיל את ה-CA הציבורי של המפעיל משמעו שהפרופיל עצמאי, ולקוח שעדיין מבקש קובץ CA אולי קורא פרופיל אחר או ייבוא חלקי. אם בפרופיל יש במקום זאת שורת ca שמצביעה על נתיב, הנתיב הזה יחסי לתיקיית העבודה של הלקוח בחלק מהאינטגרציות ומוחלט באחרות. רשמו איזו צורה יש לכם לפני שתשנו משהו.
ca /absolute/path/operator-ca.crt auth-user-pass remote-cert-tls server
בדקו בחבילה שנמסרה את הקבצים שהפרופיל מפנה אליהם: תעודת CA, לפעמים תעודת לקוח ומפתח נפרדים, ואולי קובץ tls-auth או tls-crypt. פרופיל שמפנה לארבעה קבצים ומגיע עם שניים אינו שלם, ושום כמות של הצבעה על שדות לא מתקנת זאת. בקשו מהמפעיל את החלק החסר במקום להחליף אותו בתעודה שיש לכם במקרה.
הפרידו ארבעה סוגי חומר
תעודת CA היא חומר ציבורי שמשמש לאימות זהות השרת. תעודת לקוח מזהה את המשתמש או המכשיר בפני השרת. מפתח פרטי הוא החצי הסודי של תעודת הלקוח הזאת, ואסור שיהיה אי פעם מפתח החתימה של ה-CA או מפתח שרת. חומר tls-auth או tls-crypt הוא סוד משותף נפרד שמגן על ערוץ הבקרה. ארבעת אלה אינם ניתנים להחלפה, והפניית שדה ה-CA לתעודת לקוח מייצרת כשל אימות שנראה כמו בעיית אמון.
אימות בסיסמה בלבד משנה איזה מארבעתם דרוש לכם, לא מה משמעותם. עם auth-user-pass ו-remote-cert-tls server הלקוח עדיין מאמת את השרת מול CA, ולכן שדה ה-CA מופיע גם כשאין תעודת לקוח. המדיניות של המפעיל קובעת אם גם תעודת לקוח נדרשת, ואף דיאלוג לא יכול לומר לכם זאת.
כוונו את הלקוח לקובץ האמון
בחרו את קובץ תעודת ה-CA עצמו, לא את התיקייה שמכילה אותו ולא חבילת .p12 שמכילה זהות לקוח. ב-Windows תחביר הנתיב ובורר הקבצים מתנהגים אחרת מדוגמאות ה-Linux ברוב המדריכים, לכן השתמשו במה שהלקוח המותקן מקבל ואמתו שהחשבון שמריץ אותו יכול לקרוא את הקובץ. בעיית הרשאות וקובץ חסר נראים אותו דבר בדיאלוג אבל מייצרים שורות יומן שונות. לאחר הבחירה פתחו מחדש את הגדרות הפרופיל כדי לאמת שהלקוח שמר את הבחירה.
<ca> -----BEGIN CERTIFICATE----- ...operator-provided public CA... -----END CERTIFICATE----- </ca>
אם הלקוח תומך בבלוקים מוטבעים, העדיפו את הפרופיל המוטבע של המפעיל על פני פרופיל שנבנה ביד. חומר מוטבע נוסע עם הפרופיל ושורד ייבוא מחדש, ואילו נתיב מוחלט נשבר ברגע שהפרופיל עובר למכונה אחרת.
קראו את השגיאה הבאה, לא את אותה אחת
המטרה של אספקת ה-CA הנכון היא לשנות את השגיאה, לא לגרום לה להיעלם. כשל זהות שרת לאחר טעינת ה-CA משמעו שהתעודה לא תאמה את השם המצופה או את ציפיית remote-cert-tls, וזה תיקון שונה מדחיית סיסמה. דחיית סיסמה משמעת שכבת TLS הצליחה ושהפרטים שגויים. שמרו את ההודעה החדשה הראשונה; היא השימושית.
לקוח שמתחבר אך לא מגיע לשום מקום עבר לגמרי מעבר לאמון ועומד כעת בפני שאלת ניתוב או DNS.
לעולם אל תשביתו את האימות כדי לעבור את הדיאלוג הזה. ללקוח שמקבל כל תעודה אין סיבה לבקש CA, והמנהרה שהוא בונה אינה זו שהמפעיל התכוון אליה.