CA בחתימה צולבת: המפתח תואם, קישור ה-AKI לא

שתי תעודות CA יכולות לשאת את אותו מפתח ציבורי ואת אותו נושא ובכל זאת לא להיות ניתנות להחלפה. אחת חתומה עצמית, השנייה חתומה צולבת בידי השורש הישן, ושמות המנפיק, המספרים הסידוריים והחתימות שלהן שונים. עלה יכול להיקשר באופן ספציפי לאחת מהן דרך ה-Authority Key Identifier שלו. הקישור הזה נשאר בלתי נראה עד שלקוח בוחר בשרשרת הלא נכונה וה-handshake נכשל בלי סיבה ברורה.

בצעו את חמשת הבדיקות האלה לפי הסדר: כל אחת שוללת כשל אחר.

בדיקה 1: שרטטו את שתי השרשראות לפני שנוגעים בתבנית

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

העותק החתום צולבת חייב להיות גם תעודת CA אמיתית, עם basic constraints ו-key usage שמתירים חתימה.

בדיקה 2: השוו את שדות ה-AKI, לא רק את המפתח

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

בדקו את העלה במקום לנחש: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

לאחר מכן השוו את שני המועמדים עם openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", ואותה פקודה מול העותק החתום עצמית.

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

בדיקה 3: שנו את מדיניות ההנפקה, לעולם לא את הבתים החתומים

הרחבות חיות בתוך החתימה. הוספה, הסרה או עריכה של אחת מהן על עלה קיים אינה תיקון, זו תעודה אחרת, והיא מחייבת הנפקה מחדש. השינוי שייך למדיניות ההנפקה: authorityKeyIdentifier = keyid,issuer:always גורם לעלים חדשים לשאת את הקישור הספציפי לתעודה, בעוד ש-keyid לבדו שומר על הצורה הרופפת יותר שמתאימה למעבר חתימה צולבת מכוון. החליטו מה ה-PKI שלכם רוצה לפני שהמנה הבאה תיחתם.

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

בדיקה 4: אמתו כל אוכלוסיית אמון בנפרד

בדקו את המסלול הישן ואת המסלול החדש כהרצות נפרדות. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem מתרגל את המסלול החתום צולבת, ואותה פקודה עם השורש החדש ובלי קובץ untrusted מתרגלת את המסלול החתום עצמית. ערבוב שני השורשים בחבילה אחת מסתיר איזו שרשרת נבחרה. חזרו על כך אחר כך עם לקוחות אמיתיים, מפני ש-backend של VPN יכול להעדיף שרשרת או להצמיד תעודה בדרכים ש-openssl לא עושה.

מסרו את התעודה הביניימית דרך תצורת השירות שהלקוח באמת קורא, לא דרך דף ויקי.

בדיקה 5: החזיקו את המסלול הישן על שעון הוצאה משימוש

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

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