האתר מציג את האישור הלא נכון? מצאו את המאזין

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

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

קראו את האישור שהדפדפן קיבל בפועל

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

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

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

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

זהו את התהליך הכרוך בפורט הזה

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

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

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

התאימו את המארח הווירטואלי לפני הקובץ

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

sudo apachectl -S

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

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

אמתו את התיקון בכל נתיב שאתם טוענים

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

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

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