לפני שממירים: מפתח SSH מול תעודת OpenVPN

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

איזה אובייקט באמת יש לכם?

יש חמישה דברים שאנשים קוראים להם מפתח, ורק אחד מהם הוא מה שפרופיל TLS רוצה. מפתח ציבורי של SSH הוא שורת טקסט אחת עם קידומת סוג ומטען base64. תעודת OpenSSH היא המפתח הזה בתוספת חתימה, principals ואפשרויות, שמיוצרים על ידי ssh-keygen שמשמש כ-CA קטן משל עצמו. תעודת X.509 היא מבנה אחר לגמרי, שנושאת נושא, חלון תוקף, הרחבות וחתימה מרשות אישורים. מפתח פרטי הוא החצי הסודי, וחבילה שהונפקה היא בדרך כלל תעודה ועוד השרשרת שלה ועוד המפתח הפרטי בקובץ אחד.

הבדיקה הראשונה עולה פקודה אחת. כוונו את openssl לקובץ ובקשו ממנו לנתח את מבנה התעודה:

openssl x509 -in client.crt -noout -subject -issuer

אם זה נכשל בשגיאת unable-to-load או PEM, הקובץ אינו תעודת X.509 לא משנה איך קראתם לו. שינוי שם אינו כותב מחדש את ה-ASN.1 שבפנים, וגם לא עטיפת שורת מפתח ציבורי בטקסט כותרת PEM.

האם הפרופיל בכלל מבקש תעודה?

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

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

מה קידוד מחדש יכול ולא יכול לעשות

למפתחות פרטיים יש אכן מיכלים חלופיים לגיטימיים. אותו מפתח RSA או EC יכול להיכתב כ-PEM מסורתי, כ-PKCS#8, או בתוך חבילת PKCS#12, וכלים ימירו ביניהם בשמחה. למפתחות ציבוריים יש סיפור דומה: ssh-keygen יכול להפיק את צורת RFC 4716 של מפתח SSH, ו-OpenSSH מבין גם את פורמט התעודה שלו עצמו. כל זה ייצוג, וייצוג אינו אמון.

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

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

איפה רשות האישורים נכנסת לתמונה

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

את הקובץ האחרון הזה קל לשכוח ואי אפשר להחליף. מפתח החתימה של ה-CA עצמו אף פעם לא שייך לתצורת הלקוח, וכל כמות של המרה מקומית לא מייצרת את השרשרת שהייתם אמורים לקבל.

מה עולה לכם שימוש חוזר במפתח SSH

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

לכן רשימת הבדיקה מסתיימת בתנאי עצירה ולא בתחבולה. אם openssl לא ינתח את הקובץ כתעודה, הפסיקו להמיר ותארו מה יש לכם: מפתח SSH, תעודת SSH, תעודת X.509, מפתח פרטי או חבילה. אם הפרופיל לא מבקש תעודת לקוח, עצרו ושאלו איזו שיטת אימות השרת מצפה לה. רק כששתי התשובות מצביעות על X.509 הרישום הופך לצעד הבא, והשיחה הזו הולכת הרבה יותר מהר עם שם העצם הנכון במשפט הראשון.