תעודת לקוח חתומה בעצמה? שרת ה-VPN עדיין דוחה אותה

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

האמון חי בשרת, לא בפרופיל שלך

אימות בתעודה הוא השוואה. הלקוח מציג תעודה; השער בודק אם היא נחתמה בידי אחד מה-CA בקונפיגורציה שלו.

הפרופיל שלך מציין את קובץ ה-CA שהלקוח צריך להשתמש בו כדי לאמת את השרת. הוא אינו יכול לציין CA שהשרת צריך להשתמש בה כדי לאמת אותך. החצי הזה של הקונפיגורציה אינו שלך.

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

למה תעודה חתומה בעצמה לא יכולה להחליף

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

השער לא שואל אם התעודה עקבית מבפנים. הוא שואל אם מנפיק מהימן חתם עליה.

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

מסלול ה-CSR שומר על המפתח הפרטי שלך

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

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

חבילות מיובאות, לא מותקנות

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

כלל הטיפול נובע מהתוכן. אם הפרופיל מטמיע מפתח פרטי, זו הרשאה והיא ראויה לאותה זהירות כמו סיסמה: בלי דואר, בלי מאגר, בלי תיקיית הורדות משותפת. כשהמפעיל מספק ca.crt, client.crt ו-client.key בנפרד, אחסן אותם יחד עם הרשאות מגבילות והפנה את הפרופיל אליהם.

הוסף את הבדיקות שהמפעיל אולי דילג עליהן

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

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

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

הגדרות אימות אינן תיקון לשרשרת שבורה. אם המנפיק שגוי, התשובה היא תעודה מה-CA הנכון, לא דגל שמכבה את הבדיקה. כיבוי האימות הופך כשל אימות לכזה שלא זוהה.

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