ב-macOS, בחירת ECDSA בהגדרת לקוח IKEv2 עונה על שאלה צרה: איזו תעודה מוכיחה את זהות ה-Mac. היא אינה מתארת את תעודת השער, את החתימה שהנפיקה את תעודת הלקוח, או את הצעת ההצפנה של המנהרה. התייחסות לארבעת התפקידים האלה כאל שאלת תאימות אחת היא הדרך שבה הגדרה מקומית נכונה מואשמת באי-התאמה בצד השרת. ההחלטה קטנה, אבל הראיות שמשמשות לקבלתה חייבות להיות מדויקות.

השדה נוקב בתעודה אחת: הזהות המקומית

Network Extension API של Apple חושף סוג תעודה עבור פרטי הלקוח, כולל NEVPNIKEv2CertificateType.ECDSA256, המתועד כסוג התעודה ECDSA p-256. המאפיין חל על התעודה שסופקה דרך identityReference או identityData.

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

פרופילים מנוהלים מקבלים את אותה החלטה דרך CertificateType של מטען IKEv2, יחד עם הפניה לתעודה כגון PayloadCertificateUUID. לשדות האלה יש דרישות מוקדמות וסכימה עבור גרסת מערכת ההפעלה היעד; ערך סוג גולמי שהועתק לפרופיל אינו ניתן להתקנה, וחלון הגדרות אולי לא חושף כל אפשרות API. בדוק את דרישות המוקד של המטען לאותה גרסה לפני הפריסה.

החלט לפי תפקיד, לא לפי תווית התעודה

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

What you inspectedWhat it controlsDoes it choose the Mac certificate type?
Client leaf public keyThe identity the Mac presentsYes, this is the field's subject
Issuer signature algorithmHow the client certificate was signedNo
Gateway certificateWhat the Mac validates as the peerNo, check it separately
IKE and ESP proposalsAlgorithms for the tunnelNo, separate proposal settings

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

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

תעודת השער היא החלטה נפרדת

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

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

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

חתימת המנפיק וקבוצת הסכמת המפתחות אינן סוג הלקוח

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

הצעות IKE ו-Child SA הן ציר אחר. סוג תעודה ECDSA אינו בחירת הצפנת ESP, ושינוי קבוצת הסכמת המפתחות אינו בוחר סוג תעודה. בפרופיל יכולות להיות הצעות תקפות וסוג זהות שגוי, או סוג זהות נכון והצעה שהעמית דוחה.

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

אמת את ההחלטה באמצעות השדות שהגדרת

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

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

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

מאמרים קשורים