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

איזו תעודה המאמת למעשה דחה

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

מטרת תעודת הקצה ומדיניות השרשרת הם שני מבחנים

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

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

EKU חסר אינו EKU מגביל

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

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

שחזרו את הכשל במצב לא מקוון לפני הנפקה מחדש

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

תקנו את מדיניות ההנפקה, לא את קריאת האימות

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

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

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