הגדרת תעודת IKEv2 ב-iPhone: רישום ידני מול רישום מנוהל
נתיב הרישום קובע אילו אפשרויות תעודה קיימות. בחרו תחילה ידני או מנוהל, ואז התאימו את זהות השרת, פרטי הלקוח והאלגוריתם.
בחירת RSA מפני שכלי התעודות של השער משתמש בו כברירת מחדל היא החלטה שמתקבלת לפני השאלה החשובה: כיצד יירשמו מכשירי ה-iPhone האלה? חיבור שהמשתמש מקליד בעצמו ופרופיל תצורה שהניהול מספק חושפים הגדרות שונות, וכמה אפשרויות תעודה קיימות רק באחד מהנתיבים האלה. סדרו נכון את הסדר והתוכנית של התעודה מתקצרת; טעו בו ותנפיקו אישור שהטלפון לא ישתמש בו. התייחסו לשלבים שלהלן כרצף, מפני שכל אחד מצמצם את האפשרויות הזמינות לבא אחריו.
שלב ראשון: בחרו את נתיב הרישום
התקנה ידנית פירושה שהמשתמש מזין את כתובת השרת, בוחר את שיטת האימות ומספק כל אישור שהממשק מתיר. רישום מנוהל פירושה שפרופיל נושא את הכתובת, את המזהים ואת ההפניה למטען של אישורים. הנתיב המנוהל יכול לבטא צירופים שהמסך הידני אינו יכול, ולכן החלטת התעודה חייבת לבוא אחרי הבחירה הזו ולא לפניה.
שני הנתיבים יכולים לאמת טלפון. הם נבדלים במה שאפשר להגדיר ובמי הבעלים של הזהות, לכן בחרו אחד בכוונה במקום לערבב פרופיל מנוהל עם הזנה ידנית של אישורים.
שלב שני: בחרו אלגוריתמים לנתיב שבחרתם
עבור מכשירי iPhone שהוגדרו ידנית, הערות התאימות של strongSwan עם iOS ממליצות על תעודת שרת RSA, מפני שהלקוח הידני עשוי שלא לקבל תעודת שרת ECDSA; אותן הערות מתייחסות ל-macOS בנפרד. קראו את זה כהנחיה לקבוצת הלקוחות הנתמכת, לא כחוק קבוע לגבי מכשירי Apple. לפרופיל מנוהל יש יותר מרחב: הוא יכול לבחור סוג תעודה במפורש, כולל זהות לקוח ECDSA, כאשר המטען והשער תומכים בכך שניהם.
אמתו את גרסאות ה-iOS שאתם באמת תומכים בהן לפני שתפרסו משהו. טלפון מעבדה בגרסה החדשה ביותר אינו מתאר צי שכולל מכשירים ישנים יותר, ואלגוריתם שעובד במעבדה עדיין עלול להיכשל בטלפון הישן ביותר בשטח. קחו את טווח הגרסאות מניהול המכשירים ולא מהזיכרון. אם הצי משתרע על פני כמה גרסאות, בדקו תחילה את הישנה ביותר, מפני ששם הממשק הידני מגביל ביותר.
שלב שלישי: קראו את שדות הפרופיל כדברים נפרדים
כמה מפתחות בעלי שם דומה מתארים אובייקטים שונים. הכתובת המרוחקת היא המארח שהטלפון מחייג אליו. המזהה המרוחק הוא זהות ה-IKE שהטלפון מצפה שהשער יציג. הפניית התעודה במטען מצביעה על אישור לקוח, ושדה סוג התעודה בוחר את הסוג שמשמש לאימות מכונה ב-IKEv2. אף אחד מאלה אינו אלגוריתם החתימה של ה-CA, למרות שהמילים חופפות.
הפניה של Apple למטען IKEv2 מפרטת את RSA כסוג התעודה המוגדר כברירת מחדל עם וריאנטים מפורשים של ECDSA, והיא קושרת את מפתח שם המנפיק להגדרות אימות מסוימות. קראו את הקשרים האלה בהפניה לשיטה שבחרתם במקום להעתיק מפתח אחד מפריסה שעובדת.
שלב רביעי: התאימו את זהות השער לתעודה שלו
השתמשו בשם שער מפורש, למשל vpn.example.com והניחו שם חלופי תואם של נושא בתעודת השרת. ההנחיה של strongSwan ל-Apple מצפה גם לשימוש מורחב במפתח לאימות שרת. בחירה ב-RSA או ב-ECDSA אינה משנה דבר מזה: אלגוריתם אינו יכול לתקן אי-התאמה בשם, EKU חסר או שרשרת לא שלמה.
הפצת עוגן האמון היא משימה נפרדת מהצהרת הזהות. הטלפון זקוק לשרשרת תעודות שהוא יכול לאמת, והוא חייב להיות מוגדר לצפות לשם שבאמת הנחתם בתעודה.
התחברות מוצלחת של פלטפורמה אחרת היא ראיה לכללי האימות של אותה פלטפורמה, לא רשות להקל בכללים של הטלפון. שמרו על בדיקות זהות בין לקוחות אלא אם יש לכם סיבה מתועדת לשוני.
שלב חמישי: הפרידו את זהות הלקוח מאמון ה-CA
תעודת לקוח והמפתח הפרטי שלה אינם אותו אובייקט כמו תעודת ה-CA שהטלפון בוטח בה. אריזת תעודת CA בתוך זהות PKCS#12 אינה מתקינה אותה אוטומטית כעוגן אמון בכל מכשיר נתמך, לכן התייחסו להפצת אמון כשלב בפני עצמו עם אימות משלו.
אם העיצוב משתמש ב-EAP מבוסס סיסמה במקום זאת, הטלפון זקוק לאימות החשבון המיועד בתוספת אימות השרת. הנתיב הזה אינו מצדיק שליחת מפתח פרטי משותף אחד של לקוח לכל הצי, שזה עיצוב אחר עם אופן כשל גרוע בהרבה.
סיימו את התוכנית תוך מחשבה על חידוש וביטול: מי מנפיק מחדש את אישור הלקוח, כיצד הפרופיל מתעדכן וכיצד טלפון שאבד מנותק. תעדו את גרסת הפרופיל ואת גרסאות המכשירים שמולן אימתם, מפני שהתיעוד הזה הוא שהופך את החלפת התעודה הבאה לשינוי שגרתי.