عدم تطابق شهادة 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 يخبرك استعلام خدمة الوقت ما إذا كانت الساعة تُصحح أو انحرفت فقط.

تضيف جهة إصدار داخلية شرطًا آخر: يجب أن يثق العميل بتلك الجهة. ثبّت الجذر المؤسسي عبر قناة التوزيع المعتمدة، لا من صفحة تعرض شهادة بديلة، لأن ذلك القرار هو نموذج الثقة كله في صورة مصغرة.

التحقق من الخادم ومصادقة المستخدم مرحلتان متتاليتان بفشلين مختلفين. خطأ الشهادة يعني أن العميل لم يثق بالخادم قط، بينما كلمة المرور المرفوضة تعني أنه وثق بالخادم وكانت بيانات الاعتماد خاطئة. وإيقاف التحقق من الشهادة للوصول إلى موجه كلمة المرور يزيل الضمان بدلًا من إصلاحه. ولإثبات أن بقية المسار تعمل، اختبر اسم المضيف والمنفذ نفسهما من عميل يثق بالسلسلة أصلًا، واترك الملف الشخصي المنشور كما هو.

أصلح الاسم أو الشهادة ثم أعد الاختبار

ثلاثة شروط تحدد الإصلاح. إذا كان اسم الملف الشخصي خاطئًا، فصحح الملف الشخصي أو أضف الاسم المفقود إلى الشهادة. وإذا كانت السلسلة غير مكتملة، فثبّت الشهادة الوسيطة على الخادم. وإذا كان الغرض خاطئًا، فأعد الإصدار بدلًا من الترقيع حوله.

بعد التغيير، أعد الاتصال بالعميل المدعوم وتأكد من ظهور موجه تسجيل الدخول، ثم من قيام النفق. سجّل اسم المضيف المستخدم وجهة الإصدار وتاريخ الانتهاء في التذكرة. هذا السجل هو ما يجعل التجديد التالي مهمة مجدولة بدلًا من انقطاع آخر، ويُظهر أيضًا للشخص التالي أي الشروط الثلاثة كان مكسورًا فعلًا.