תעודת VPN של Mac: מדוע בורר הזהות נשאר ריק
הלקוח צריך תעודה עם המפתח הפרטי שלה, במאגר שהוא קורא. בדוק קודם את הזהות, ואחר כך אם השער מקבל אותה.
התקנת את התעודה, היא מופיעה ב-Keychain Access עם שם ידידותי, ובורר הזהות של לקוח ה-VPN עדיין ריק. הלקוח אינו מחפש תעודה. הוא מחפש זהות: תעודה שמזווגת למפתח הפרטי שיכול להוכיח בעלות, מאוחסנת במקום שבו ללקוח מותר לקרוא אותה.
מה שהלקוח מבקש הוא זהות
מסגרת האבטחה של Apple מתייחסת לתעודה ולזהות כאל אובייקטים שונים. תעודה היא נתונים ציבוריים. זהות היא התעודה הזו בתוספת המפתח הפרטי שלה, ורק הזהות יכולה להשלים אתגר. תעודת CA מהימנה, לעומת זאת, מאפשרת ללקוח להעריך מנפיק; היא אינה הופכת את המחשב לבעל אישור לקוח שהונפק.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
לכן ייבוא קובץ .cer לעולם אינו מייצר זהות לקוח שמישה. הקובץ נושא חומר ציבורי בלבד, וכל שינוי שם או מתן אמון אינו הופך אותו לצמד מפתחות.
שלוש סיבות לכך שהבורר נשאר ריק
הראשונה היא מפתח פרטי חסר, כלומר תהליך ההרשמה או הייבוא לא סיפק אחד. השנייה היא מאגר שהלקוח אינו בודק: פרופיל בהיקף משתמש מחפש במחזיק המפתחות של המשתמש, ופריט שהוצב במאגר מערכת עשוי להיות בלתי נראה עבורו. השלישית היא אי-התאמה של מטרה או מדיניות, שבה התעודה קיימת אך אינה תקפה לאימות לקוח לפי כללי הפריסה.
security find-identity -v -p ssl-clientזה מפרט את הזהויות שהמערכת מחשיבה תקפות לאימות לקוח. אם הספירה היא אפס, הבעיה נמצאת לפני לקוח ה-VPN ושום עריכת פרופיל לא תתקן אותה. אם הזהות מופיעה כאן אך לא בלקוח, ההבדל הוא במאגר או בהיקף של הלקוח.
היכן חי המפתח הפרטי, ומי רשאי להשתמש בו
כשאתה מייבא זהות דרך Keychain Access, תיבת הדו-שיח של הייבוא מציעה מחזיק מפתחות יעד. איזה יעד נכון תלוי בלקוח ובשאלה אם הפרופיל הוא בהיקף משתמש או מכשיר. תשובה ישנה שממליצה על מחזיק המפתחות של המערכת אינה כלל גורף, והעתקת פריטים בין מאגרים אינה תיקון.
System Roots הוא אוסף אמון. הצבת תעודה שם משנה את המנפיקים שהמערכת נותנת להם אמון; היא אינה יוצרת מפתח פרטי, והיא אינה מאגר זהויות. העברת תעודות לא קשורות כדי למלא בורר היא מסוג התיקונים שמשאיר מחשב עם סט אמון מורחב לצמיתות.
הגישה למפתח הפרטי היא בקרה נפרדת. מתן הרשאה לכל יישום להשתמש במפתח פותר את בעיית הבחירה של לקוח אחד ומעביר את אותה יכולת לכל השאר במחשב. תן אותה ללקוח שזקוק לה, ובדוק אם המפתח מגובה בחומרה או מסומן כבלתי ניתן לייצוא; אם כן, יש להשתמש בספק הנתמך ולא בעותק מיוצא.
איך הפרופיל מצביע על האישור
בתצורת IKEv2 מקורית מנוהלת, הפרופיל מפנה למטען האישור שלו דרך PayloadCertificateUUID. הזהות שאליה מפנים והאופן שבו סופקה הם הקובעים; עריכת שם תצוגה בפרופיל אינה מתקנת הפניה למטען שגוי או לכזה שמעולם לא סיפק מפתח.
ספק צד שלישי עשוי להשתמש במנגנון בחירה שונה לחלוטין, כמו המאגר שלו או הנחיה של המערכת. קרא את התיעוד של אותו ספק במקום להעביר הנחות של פרופיל מקורי, ואמת את ההפניה בפרופיל שמותקן בפועל, ולא בטיוטה שבמסוף הניהול.
בחירה וקבלה הן אבני דרך נפרדות
בורר מאוכלס אומר שהלקוח יכול למצוא זהות ולהשתמש בה. זה לא אומר דבר על האם השער יקבל אותה. השרת עדיין בודק את המנפיק, את חלון התוקף, את מצב הביטול ואת המיפוי מאותו אישור לחשבון.
בדוק את שני השלבים במפורש, בסדר הזה. אשר שהזהות מוצעת, התחבר, ואז בקש מבעל השער לאשר איזה אישור הוצג ואיזו כלל מיפוי צרך אותו. אם הלקוח מציע זהות והשרת דוחה אותה, העבודה שנותרה היא בצד השרת. התקנה מחדש של התעודה ב-Mac לא תשנה את התוצאה, כמה פעמים שלא תחזור עליה.