שגיאת תעודה בממשק הווב של Access Server: תיקון חבילת CA ריקה

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

למה שלושת המפתחות באמת מצביעים

קבוצת תעודות הווב המותאמת מתוארת על ידי cs.cert, cs.priv_key וכן cs.ca_bundle. כל אחד מהם מאחסן נתיב לקובץ, ושלושתם נצרכים יחד על ידי שירות הווב. תעודה עם מפתח שגוי, או קובץ שרשרת שהוא למעשה תעודת העלה, נכשלים באותה דרך שבה נכשל ערך ריק: המאזין אינו יכול לבנות שרשרת שהדפדפן יקבל.

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

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

למה קובץ שקיים עדיין נכשל בפענוח

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

בדוק את האובייקטים ולא את הסיומות. במארח לינוקס, openssl x509 -noout -subject -issuer -in server.pem וכן openssl pkey -noout -check -in key.pem עונים על שתי השאלות שחשובות, והשוואת המודולוס או המפתח הציבורי של שניהם מוכיחה שהם שייכים יחד. הרחק פלט של מפתח פרטי מכרטיסים ויומני צ'אט; הבדיקה צריכה טביעת אצבע, לא את המפתח.

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

אמת את הסט לפני שאתה מפעיל מחדש משהו

ממשק שורת הפקודה של Access Server כולל בדיקת אימות שמקבלת את שלושת הנתיבים כארגומנטים ומדווחת אם הסט שמיש. הנתיבים שלהלן הם להמחשה; החלף אותם במיקומים המוגנים במארח:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

חזרה מכוונת לגיבוי

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

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

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

אמת את השם שהמשתמשים באמת מקלידים

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

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