حدد شكل الإصلاح الناجح
يشير خطأ مصافحة SSL في Kopano إلى عدم تمكن العميل والخادم من الاتفاق على اتصال TLS أو إتمامه. قد يكون المنفذ المخصص صحيحًا في جزء من الإعداد، وغير صحيح في جزء آخر. قبل تغيير الشهادات أو إعدادات البروتوكول، حدد الخدمة التي تمتلك المنفذ، وما إذا كان من المتوقع استخدام TLS فيه.
لضمان عمل النظام بشكل صحيح، يجب أن يقبل المنفذ المُستهدف اتصال TLS، ويُقدّم شهادة صالحة لاسم المضيف الذي يستخدمه العملاء، ويسمح بإتمام خطوة البروتوكول التالية. ينبغي أن يصل المتصفح إلى صفحة تسجيل الدخول إلى تطبيق الويب دون ظهور أي تحذير بشأن الشهادة. يجب أن يتصل عميل Kopano Core باستخدام منفذ TLS المُطابق، وشهادة العميل الموثوقة الخاصة به (إن وُجدت). لا يُعدّ نجاح اختبار TLS وحده دليلاً على أن تسجيل الدخول إلى تطبيق الويب، أو مصادقة Kopano، أو تسليم البريد الإلكتروني تعمل بشكل صحيح.
أولاً، افصل بين إعدادي المنفذين الشائعين
تم التحقق من توافق Kopano Core: يصف دليل مسؤول Kopano Core 8.0 مستمع TLS أصليًا يتم التحكم فيه بواسطة [اسم البرنامج/ المكتبة server_listen_tls]. يستخدم المثال المنفذ 237، ويشير إلى إمكانية تغيير المنفذ، ويقوم بتكوين ملفات الشهادة وCA في [اسم الملف/المكتبة /etc/kopano/server.cfg]. كما يُظهر الدليل العملاء الذين يستخدمون https://مقبس خادم مع المنفذ وشهادة العميل المتطابقين. راجع Kopano Core: اتصالات SSL والشهادات، وتكوينات Kopano Core الخاصة .
بشكل منفصل، للوصول إلى تطبيق الويب: يفتح المستخدمون عادةً عنوان URL في المتصفح يتم تقديمه بواسطة Apache أو Nginx أو Kopano Web. يمكن أن ينتهي اتصال TLS عند خادم الواجهة الأمامية أثناء إعادة توجيه الطلبات إلى خدمات Kopano. يوثق دليل Kopano عملية توجيه HTTP إلى مستمع Core على المنفذ 236، بينما يوثق دليل Kopano Web إعدادات شهادة TLS /etc/kopano/kwebd.cfg. لا يكون منفذ HTTPS الخاص بالواجهة الأمامية هو نفسه منفذ TLS الخاص بـ Core تلقائيًا. راجع مثال الوكيل العكسي لـ Core ودليل تثبيت Kopano Web .
الإجراء: دوّن عنوان URL الخاص بالعميل، والمنفذ المخصص، والعملية المتوقع أن تستمع إليه، وما إذا كان بروتوكول TLS ينتهي عند الخادم الوكيل أو عند Kopano Core. لا تُغيّر كلا المستمعين في آنٍ واحد.
1. تحقق مما يستمع على المنفذ المخصص
على جهاز Kopano المضيف، استبدل 8443ما يلي بالمنفذ الذي به المشكلة:
sudo ss -ltnp | grep ':8443'
يجب أن يُظهر الصف المطابق منفذ استماع. إذا لم يكن هناك صف، فهذا يعني أن الخدمة غير مرتبطة بهذا المنفذ، أو أنها مرتبطة بعنوان مختلف. إذا كان المنفذ تابعًا لخادم وكيل عكسي محلي، فافحص المضيف الظاهري للوكيل. إذا كان من المفترض أن يكون منفذ TLS الأصلي لـ Kopano Core، فافحصه server_listen_tlsفي [المكان المناسب /etc/kopano/server.cfg]. لا يمكن لعملية تستمع فقط على [ 127.0.0.1المنفذ] قبول الاتصالات البعيدة مباشرةً؛ وقد يكون ذلك مقصودًا عند وجود وكيل وسيط.
تحقق أيضًا من جدار حماية المضيف، وجدار حماية السحابة، وأي قاعدة لموازن الأحمال أو ترجمة عناوين الشبكة (NAT). يجب أن يصل المنفذ العام إلى المستمع الداخلي المقصود. يشير انتهاء المهلة أو رفض الاتصال إلى مشكلة في إمكانية الوصول أو إعدادات المستمع؛ ولا يدل ذلك بحد ذاته على وجود شهادة غير صالحة.
2. فحص بروتوكول TLS على اسم المضيف والمنفذ المحددين
من جهاز العميل، اختبر نقطة النهاية العامة باستخدام OpenSSL. استخدم اسم DNS الذي يظهر في الشهادة، وليس عنوان IP غير ذي صلة.
openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts
ابحث عن الشهادة المُقدَّمة، والبروتوكول المُتفاوض عليه، والتشفير، وأي أخطاء في التحقق. -servernameيُرسل هذا الخيار اسم مضيف TLS SNI؛ وهذا مهم عندما يستضيف الخادم أكثر من موقع TLS واحد. يُوثِّق OpenSSL هذه الخيارات في دليل s_client الخاص به . اضغط Ctrl+C للخروج من الفحص التفاعلي.
في حال عدم وجود الشهادة، فقد يكون الطرفية تستخدم بروتوكول HTTP عاديًا، أو قد يكون المنفذ مُستخدمًا من قِبل خدمة خاطئة، أو قد يقوم خادم وكيل بإعادة التوجيه إلى مصدر غير صحيح. إذا ظهرت الشهادة ولكن اسمها أو جهة إصدارها أو تاريخ انتهاء صلاحيتها غير صحيح، فقم بتصحيح اختيار الشهادة أو سلسلة الشهادات على طرفية TLS. لا يُصلح تغيير منفذ الاستماع في Kopano Core عدم تطابق اسم المضيف.
بالنسبة لنقطة نهاية موجهة للمتصفح، اتبع ما يلي:
curl -v https://mail.example.com:8443/webapp/
تساعد المخرجات التفصيلية في التمييز بين التحقق من بروتوكول TLS واستجابة HTTP مثل إعادة التوجيه أو الخطأ 404 أو 502. يشير الخطأ 404 بعد إتمام عملية المصافحة إلى مشكلة في المسار أو التوجيه، وليس إلى فشل في مفاوضات TLS. لأغراض التشخيص لمرة واحدة فقط، curl -vkيمكن لهذه المخرجات أن توضح ما إذا كان تجاوز التحقق من الشهادة يُغير النتيجة. لا تترك عمليات التحقق من الشهادات معطلة في المتصفح أو العميل أو الخادم الوكيل.
ملاحظة هامة: يمكن لبروتوكول TLS الأصلي في Kopano Core استخدام شهادات العميل. s_clientقد يُرفض اختبار أساسي بدون شهادة عميل حتى لو كان مستمع TLS يعمل بشكل صحيح. إذا طلب الخادم مصادقة العميل، فأعد الاختبار باستخدام شهادة ومفتاح العميل المعتمدين، أو اختبر باستخدام عميل خدمة Kopano المُهيأ. لا تُفصح أبدًا عن مفتاح خاص في سجل الأوامر أو تذكرة الدعم.
3. مطابقة البروتوكول مع المستمع
من الأخطاء الشائعة في استخدام المنافذ المخصصة، تهيئة عميل HTTPS للاتصال بمستمع HTTP عادي، أو توجيه حركة مرور HTTPS إلى خادم يتوقع HTTP. يجب أن يصف كل من البروتوكول والمنفذ نفس نقطة النهاية.
https://mail.example.com:8443/webapp/هذا يعني أن المتصفح يتوقع استخدام بروتوكول TLS على المنفذ 8443.
- يُرسل المثال الموثق في Kopano Core بروتوكول HTTP عبر وكيل إلى
127.0.0.1:236. إذا كان النشر الخاص بك يستخدم هذا النمط، فيجب على الوكيل في المصدر استخدام http://، حتى لو كان اتصال المتصفح العام يستخدم HTTPS.
- بالنسبة لبروتوكول TLS الأصلي في Kopano Core، يستخدم المثال الوارد في الدليل
server_listen_tls = *:237عنوان URL للعميل يبدأ بـ https://. إذا قمت بتغيير 237 إلى منفذ مخصص، فقم بتحديث كل عميل أو وكيل تابع إلى نفس القيمة.
تحقق من وجود أسطر تكوين منسوخة تختلف بشأن المنفذ أو البروتوكول. في بيئة متعددة الخوادم، راجع أيضًا عنوان URL للخادم أو الوكيل المنشور: فقد يُكمل العميل اتصالًا أوليًا ثم يفشل بعد أن يُعيد Kopano توجيهه إلى اسم مضيف أو منفذ قديم.
4. إصلاح إعدادات المستمع والشهادة
إذا كان هذا هو مستمع TLS الأصلي لـ Kopano Core، فقم بتعديل الإعدادات الحالية بدلاً من إضافة توجيهات مكررة. فيما يلي مثال مبسط لمنفذ مخصص؛ احتفظ بمسارات الشهادات وهيئة التصديق (CA) المناسبة لتثبيتك:
server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase
يُحدد دليل Kopano إعدادات المُستمع، وشهادة المرجع المصدق، ومفتاح الخادم، وكلمة المرور، ويتطلب إعادة التشغيل kopano-serverبعد هذا التغيير في المُستمع الأصلي. تأكد من أن الإصدار المُثبت يدعم الخيارات الموضحة؛ فقد تختلف هياكل الحزم والتوجيهات. احمِ دليل المفتاح وتأكد من أن حساب خدمة Kopano لديه صلاحية قراءة الملفات المطلوبة.
تأكد من أن الشهادة مخصصة لاسم المضيف الذي يستخدمه العملاء فعليًا، وأنها ضمن فترة صلاحيتها، وأنها تتضمن أي شهادات وسيطة مطلوبة. يشير دليل Kopano إلى أن مكوناته تتحقق من الاسم الشائع للشهادة والأسماء البديلة للموضوع. في بيئة TLS متعددة الخوادم، يجب أن يثق الخادم أيضًا في جهة إصدار الشهادات التي وقّعت شهادات العملاء، ويجب تكوين شهادات العملاء المعتمدة. لا تستبدل الشهادة بشهادة موقعة ذاتيًا كاختصار لخدمة متصفح عامة.
إذا انتهى اتصال TLS عند Apache أو Nginx أو Kopano Web، فقم بتكوين الشهادة والمنفذ المخصص listenعند تلك الواجهة الأمامية. ثم اضبط بروتوكول ومنفذ المصدر وفقًا للمستمع الفعلي للخادم الخلفي. لا تُفعّل TLS المصدر لمجرد أن الجانب العام يستخدم HTTPS؛ تأكد أولًا من أن منفذ الخادم الخلفي يدعم TLS أيضًا.
5. التحقق من صحة الخدمة وإعادة تحميلها
قبل إعادة تشغيل خادم الويب، قم بتشغيل فحص التكوين الخاص به، مثلاً sudo nginx -tلـ Nginx أو sudo apachectl configtestApache. إذا أظهر الفحص خطأً، فقم بتصحيحه قبل إعادة التشغيل. استخدم اسم الخدمة المثبتة على توزيعتك؛ على سبيل المثال:
sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager
أعد تشغيل Kopano Core فقط عند تغيير إعداداته. في حالة تغيير منفذ أو شهادة خاصة بالواجهة الأمامية فقط، تحقق من صحة خدمة الواجهة الأمامية وأعد تحميلها. راجع سجل النظام أو سجل الأخطاء مباشرةً بعد التغيير، وكرر عملية فحص OpenSSL نفسها من شبكة العميل. يجب أن تُظهر عملية المصافحة الآن الشهادة المتوقعة. ثم اختبر عنوان URL الفعلي لتطبيق الويب أو اتصال عميل Kopano، لأن نجاح TLS وحده لا يكفي للتحقق من صحة مسار التطبيق أو المصادقة.
اقرأ النتيجة قبل إجراء المزيد من التغييرات
- لا يوجد منفذ استماع: تحقق من المستمع المُكوّن، وحالة الخدمة، وعنوان الربط.
- تم رفض الاتصال أو انقضى وقت الانتظار: تحقق من جدار الحماية، وNAT، وموازن الأحمال، وما إذا كان المنفذ المستهدف قابلاً للوصول.
- شهادة خاطئة: افحص الشهادة المُكوّنة على نقطة النهاية التي تستجيب لهذا المنفذ، بما في ذلك اختيار SNI وسلسلة الشهادات.
- يعمل بروتوكول TLS محليًا ولكن ليس عن بعد: قارن مسار الوكيل العام أو موازن التحميل مع المستمع المحلي وراجع قيم المضيف والمنفذ المعاد توجيهها.
- نجحت عملية المصافحة، لكن تطبيق الويب فشل: افحص حالة HTTP، ومسار الوكيل، وسجلات PHP/تطبيق الويب، واتصال Kopano Core. تابع على مستوى التطبيق.
- العملاء الأساسيون فقط هم من يفشلون: تحقق من إعداداتهم
server_socket، بما في ذلك المنفذ المخصص، وشهادة المرجع المصدق الموثوقة، وشهادة العميل. قد يتطلب مسار TLS الأساسي مصادقة الشهادة المتبادلة.
لا يُغيّر الحل الموثوق سوى نقطة النهاية المسؤولة عن عملية المصافحة الفاشلة. يتوفر دليل مسؤول Kopano Core لهذا الإجراء بإصدار 8.0.0، ويجب التحقق من أمثلته ومقارنتها بالحزم المثبتة وصفحات الدليل المحلية. إذا كان نظامك يستخدم إصدارًا مختلفًا من Kopano، أو حاوية، أو خادم وكيل عكسي مُدار، فتأكد من التكوين الحالي لهذا المكون قبل تطبيق التوجيهات النموذجية.