AWS Client VPN: תעודת שרת מול תפקיד תעודת לקוח
תעודת השרת של נקודת הקצה מוכיחה את השירות. אימות הדדי מוסיף זהויות לכל לקוח ואמון ב-CA בלי לשתף את מפתח השרת.
נקודת קצה של Client VPN זקוקה תמיד לתעודת שרת TLS. זו היא הזהות שנקודת הקצה המנוהלת מציגה כשמתחבר לקוח. זהו אובייקט אחר מהתעודות שלקוחות בודדים מציגים כשמשתמשים באימות הדדי. ערבוב בין השניים הוא הסיבה הנפוצה ביותר לכך שהגדרת ACM נכונה אחרת נכשלת עדיין בחיבור הראשון.
להלן סקירה מהקונסול החוצה, לפי הסדר שבו חיבור באמת עובר.
שני תפקידים, נקודת קצה אחת
לנקודת הקצה יש זהות שרת, ולחלופין גם דרך לאמת זהויות של לקוחות. את אלה מגדירים בנפרד. האחד קובע אם הלקוח יכול לסמוך על השירותכן האחר קובע אם השירות מקבל את הלקוח.
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
קראו את הטבלה כשלוש דרישות בלתי תלויות ולא כתעודה אחת. תעודת השרת והמפתח הפרטי שלה נשארים אצל השירות. תעודת לקוח והמפתח הפרטי המתאים לה נמצאים במכשיר. חומר ה-CA הוא מה שמאמת משתמש כדי לבדוק את השרשרת. רק השורה האמצעית שייכת למחשב נייד.
מה עושה תעודת השרת ב-ACM
כשיוצרים את נקודת הקצה, תעודת השרת חייבת להיות זמינה ב-ACM באותו אזור שבו נמצאת נקודת הקצה. הקונסול מבקש ARN, וכתובת ARN זו חייבת להיפתר שם. ACM יכולה להחזיק תעודה שהקציתם עם אימות דומיין, או תעודה שייבאתם יחד עם המפתח והשרשרת שלה. שתיהן עובדות בתפקיד הזה; הן נבדלות בחידוש ובמי מחזיק במפתח הפרטי.
בחרו את מסלול ההקצאה שמתאים למי שיכול לחדש את התעודה, ולא את זה שבמקרה יצר קובץ שנראה תקף.
מה מוסיף אימות הדדי
בחירת אימות לקוח מבוסס תעודה מוסיפה שאלה שניה: אילו לקוחות רשאים בכלל להתחבר. כל לקוח מציג תעודה מושל ומוכיח שהוא מחזיק במפתח הפרטי המתאים. זהויות נפרדות הן מה שמאפשר מאוחר יותר ביטול סלקטיבי. העתקת מפתח לקוח אחד לכל מכשיר משליכה בשקט את התכונה הזו, גם כשתעודת השרת הושגה באופן מושלם.
שיטת האימות של נקודת הקצה היא בחירה, לא דרישה אוניברסלית.
Active Directory ואימות פדרטיבי עונים על אותה שאלה בדרכים אחרות. מתכון של תעודה הדדית אינו אוטומטית תכנון הכניסה לפריסות האלה, ואימות ה-TLS של השרת נשאר בתוקף ללא תלות באופן שבו המשתמש מתקבל.
למה אותו ARN של CA אינו שיתוף מפתחות
AWS מתעדה שכאשר תעודת השרת ותעודת הלקוח מונפקות בידי אותה CA, אפשר להשתמש ב-ARN של תעודת השרת גם לבחירת תעודת הלקוח. המשפט הזה עוסק בשרשרת שנקודת הקצה סומכת עליה בעת האימות. הוא אינו אומר ללקוחות להשתמש במפתח הפרטי של השרת. מחשב נייד עדיין זקוק לתעודת לקוח מושל ולמפתח מתאים מושל.
כשה-CA של הלקוח הוא מנפיק אחר, המסלול המתועד הוא לייבא את ה-CA הזה ל-ACM ולבחור בו לתפקיד הלקוח.
החזירו את הכישלון לשלב
זהו איזה שלב נכשל לפני שאתם מחליפים משהו. אם הלקוח דוחה את נקודת הקצה, החשוד הוא ה-ARN של השרת או השרשרת שלו. אם נקודת הקצה דוחה את הלקוח, הסתכלו בתעודת הלקוח, במנפיק שלה ובשיטת האימות שנבחרה. אם המנהרה עולה והתעבורה עדיין נכשלת, כבר עברתם את התעודות.
החליפו אובייקט אחד בכל פעם, כי החלפת שני הקצוות יחד משחזרת את העמימות שפתחתם בה.
בדקו גם את אלגוריתמי המפתח הנתמכים ואת ההרחבות הנדרשות של השירות לתפקיד המסוים. תעודה שמספקת אתר ציבורי אינה הוכחה שכל דרישות הזהות של Client VPN מולאו.
רשמו איזה ARN מחזיק כל שדה, איזה CA הנפיק את תעודת הלקוח ואיזו שיטת אימות נקודת הקצה באמת משתמשת. שלוש שורות תיעוד הופכות את החידוש הבא למשימה במקום לחקירה.