אי-התאמת תעודה ב-SSTP: השם שהשרת שלכם חייב להציג

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

שם הפרופיל קובע מה נבדק

SSTP מריץ TLS מעל TCP 443, ולכן הלקוח מתנהג כמו כל לקוח TLS אחר: הוא לוקח את שם המארח מהפרופיל, מבקש את השם הזה ומשווה את התעודה אליו. אם תקלידו כתובת IP בפרופיל, ההשוואה הופכת להשוואת כתובות IP, שרוב תעודות השרת לא מספקות.

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

מה צריכה התעודה של השרת לשאת

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

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

בדקו את השרשרת ואת השעון לפני פרטי הכניסה

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

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

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

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

תקנו את השם או את התעודה ונסו שוב

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

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