ל-IKEv2 יש שני חתימות: תעודה ו-IKE_AUTH
ה-CA חותם על התעודה, והעמית חותם על חילופי ה-IKE_AUTH שלו בסכימה משלו. קראו כל חתימה מהשדה שלה, ואז תרשמו את שתיהן.
הכרטיס שלכם אומר שהתעודה היא SHA-256 בעוד יומן השער מציין אלגוריתם חתימה אחר, ומישהו כבר ניסח בקשה להוציא את ה-CA מחדש. לפני שהבקשה הזו יוצאת לאנשהו, הפרידו בין שתי החתימות: האחת היא החותם של המנפיק על מפתח ציבורי, והשנייה היא הוכחת העמית שהוא מחזיק במפתח הפרטי המתאים במהלך IKE_AUTH. רכיבים שונים בוחרים אותן, ומותר להן להיות שונות. קריאת כל אחת מהמקום שבו היא חיה דורשת שתי פקודות וטבלה אחת.
קראו את חתימת המנפיק מהתעודה
ה-CA שם את חתימתו על קשר בין זהות למפתח. החתימה הזו מתעדת מה ה-CA עשה בהנפקה, לא מה הנושא יעשה כשיתחבר, ולכן האלגוריתם שלה מתאר את בחירת ה-hash והמפתח של ה-CA עצמו. מפתח נושא מסוג אחד יכול לשבת תחת מפתח CA מסוג אחר בלי שום סתירה, וסיבוב מפתח CA הוא שגרה ולא תקלה. קראו את שני השדות ויש לכם חצי מהמלאי:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"רשמו את שתי התוויות כרשומות נפרדות. הראשונה מתארת את ה-CA, השנייה מתארת את מפתח הנושא, ואף אחת מהן לא מנבאת את החתימה המקוונת.
קראו את החתימה המקוונת מחילופי IKE
במהלך האימות כל עמית חותם על נתוני החילוף במפתח הפרטי שלו, והצד השני בודק את ההוכחה הזו מול הזהות, שרשרת האמון והמדיניות של התעודה. ב-RSA הריפוד וה-hash שייכים לסכימה המקוונת הזו, ולכן מפתח ארוך יותר או תעודת SHA-256 חדשה לא יכולים בעצמם לבחור RSA-PSS לחתימת האימות. השיטה שנקבעה במשא ומתן מופיעה ביומן הדמון או ברשימת החיבורים שלו, ולעולם לא בתעודה. שאלו כל צד על מה הוא ניהל משא ומתן, כי שני הכיוונים יכולים להיות שונים.
ipsec statusall | grep -i "auth\|proposal"כשצד אחד מציין סכימה שהצד השני לא יכול להפיק, מצאתם את אי-ההתאמה שהכרטיס עסק בה. הוצאת ה-CA מחדש היא התיקון השגוי לכך, כי התעודה מעולם לא הייתה מה שנכשל.
מה RFC 7427 משנה, ומה לא
השיטות המקוריות ממוספרות לפי כל צירוף אלגוריתמים ב-RFC 7296. שלוחת החתימה של RFC 7427 המאוחרת מוסיפה שיטת Digital Signature כללית עם איתות תמיכה ב-hash של חתימה, כך ש-hash חדש כבר לא צריך מספר שיטה משלו. היא נקבעת במשא ומתן ולא מניחה: עמית אינו זוכה בשלוחה משום שהספרייה שלו יודעת לנתח את אותן תעודות, ועמית שמיישם רק את השיטות המקוריות מכריח את השער לשמור אחת מהן. זהו סחר מדיניות עם עלות תאימות, לא פגם.
התמיכה היא לפי כיוון ולפי חיבור, לכן בדקו את הבנייה שלפניכם ולא סמכו על טענה ברמת משפחה. מטריצת יכולות שנכתבה לפני שלוש שנים מתארת בנייות בנות שלוש.
הניחו ארבע שורות במלאי
לרשומה שמסיימת את הוויכוח יש ארבע שורות, כל אחת נקראת ממקום אחר וכל אחת משתנה בידי אדם אחר. מלאו אותה לפני שתחליטו משהו, כי דווקא השורה השגויה היא שבוחרת את התיקון.
| אובייקט | מהיכן קוראים | מי משנה |
|---|---|---|
| חתימת מנפיק התעודה | השדה Signature Algorithm של התעודה | מפעיל ה-CA, בהנפקה |
| המפתח הציבורי של הנושא | השדה Public Key Algorithm של התעודה | מי שמייצר את מפתח הנושא |
| סכימת אימות IKE | יומן הדמון או רשימת חיבורים, התראת auth ו-signature-hash | פרופיל ה-IKE בשני העמיתים |
| אלגוריתמי ההגנה של IKE ו-ESP | רשימת ההצעות של החיבור | פרופיל ה-IPsec, לפי כיוון |
כל שורה נושאת את השלכות התאימות שלה. שינוי צופן ESP לא בוחר את חתימת המנפיק, והקלה באימות ה-CA לא מוסיפה שיטה מקוונת שהעמיתים מעולם לא קבעו. ככרטיס טוען לאי-התאמה בחתימה, השורה שבאמת שגויה היא כמעט אף פעם לא הראשונה.
הכריעו את המקרה הישן בלי להחליש את ה-PKI
עמית ישן יותר עשוי להציע רק סכימה שהמדיניות שלכם כבר אינה מתירה. האפשרויות הן חריגת תאימות מוגבלת בזמן, עדכון לקוח, או הסדר אימות אחר רק לאותו עמית. בנייה מחדש של ה-PKI סביב חתימת תעודה חלשה יותר לא מתקנת מגבלה בחילוף המקוון ומחלישה כל שירות אחר שסומך על אותו CA. רשמו איזו שורה שיניתם ומתי החריגה תפוג.
אחר כך הריצו שוב את שתי הקריאות מההתחלה, כי שינוי בשורה אחת יכול להזיז את מה שנקבע באחרת. כל המלאי הוא שתי פקודות וטבלה אחת, ואותה עבודה היא בין אם העמית הוא נתב, מחשב נייד או מכשיר.