strongSwan: סוג מפתח, טוען וה-backend הלא נכון

סיומות קבצים אינן מזהות אלגוריתמי מפתח, ומעטפת .pem יכולה להכיל חומר RSA או ECDSA. PEM מתאר כיצד בתים נעטפים, בעוד RSA ו-ECDSA מציינים אלגוריתמים שונים, וקובץ PKCS12 הוא דבר שלישי. strongSwan טוען אישורים דרך תוספים ו-backend תצורה, כך שתעודה יכולה להופיע ברשימה בעוד המפתח הפרטי לעולם אינו הופך לשימושי. הפרידו בין השכבות האלה לפני עריכת סוד כלשהו.

קידוד, אלגוריתם ואריזה הם שלוש שכבות

לקובץ מפתח יש קידוד, אלגוריתם ולעיתים קרובות מכל. PEM הוא מעטפת ה-base64 המוכרת; DER הוא המקבילה הבינארית שלו; PKCS12 אוסף תעודה עם המפתח והשרשרת שלה. קובץ שרשרת תעודות הוא מכל נוסף, והוא בדרך כלל אינו מכיל מפתח פרטי כלל. אף אחד מהתוויות האלה לא אומר אם החומר שבפנים הוא RSA או ECDSA.

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

השוו מפתחות ציבוריים לפני שאתם מאשימים את הטוען

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

ipsec.secrets ישן או אישורי swanctl

ל-strongSwan יש שני נתיבי אישורים נפוצים. מחסנית ה-starter הישנה קוראת רשומות ספציפיות לסוג מתוך ipsec.secrets, וכל רשומה חייבת לציין את הסוג הנכון עבור החומר. מחסנית swanctl ו-vici טוענת מפתחות מתיקיית האישורים שלה באמצעות התצורה שלה. עריכת הקובץ שה-backend הרץ אינו קורא אינה משנה דבר.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

גלו איזה backend באמת רץ, ואז הניחו את המפתח במקום שבו אותו backend מסתכל. המדריך הישן של strongSwan 5.9 מגדיר את רשומות הסוד הספציפיות לסוג, וזה אינו תיעוד swanctl. ערבוב השניים יוצר דימון שמתעלם מקובץ שהמנהל מחשיב כסמכותי. טעינה מחדש שאינה מדווחת על שגיאה רק אומרת שהתצורה נותחה.

קראו את אירוע הטעינה ואת תוצאת האימות

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

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