خدمة systemd تصل إلى البروكسي، لكن لا تصل إلى ملف CA

ثبّتَّ حزمة CA المعتمدة ويعمل الطلب في الطرفية. ما زالت الخدمة تبلغ عن خطأ في تحميل الشهادة. قبل استبدال عنوان IP البروكسي، تحقّق هل تستطيع هذه العملية فتح الملف نفسه.

قد تعمل الخدمة كمستخدم Unix آخر، أو تبدأ من دليل مختلف، أو ترى نظام ملفات مقيّدًا. المسار الصالح لجلسة دخولك لا يكون صالحًا لها تلقائيًا.

ابدأ بمسار مطلق

افحص المسار المضبوط في العميل الفعلي. في curl مثلًا، يختار --cacert حزمة CA للوجهة؛ وللبروكسي HTTPS خيارات CA منفصلة للبروكسي. تستخدم التطبيقات الأخرى مفاتيح إعداد أو متغيرات بيئة خاصة بها.

افحص الملف والأدلة التي تقود إليه معًا:

namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory

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

قد لا تكون الأذونات كل المشكلة

مع ProtectHome=yes، يجعل systemd مواقع الأدلة المنزلية القياسية غير متاحة للخدمة. تغيير نمط ملف الشهادة لا يلغي قيد مساحة الأسماء. وقد يغيّر دليل جذر مضبوط ما يشير إليه المسار المطلق داخل الخدمة.

استخدم موقعًا مناسبًا لإعداد الخدمة، مثل دليل تحت /etc مخصّص للتطبيق، وامنح القراءة المطلوبة فقط. حدّث مسار CA في العميل إلى ذلك الموقع. لا تزل قيود ملفات أخرى لمجرد أن النسخة الأولى حُفظت في دليلك المنزلي الشخصي.

اقرأ أول خطأ مفيد

«لا يمكن تحميل ملف CA» و«سلسلة الشهادات غير موثوقة» فشلان مختلفان. قد يحدث الأول قبل أن يتمكن العميل من التحقق من أي شيء. وقد يعني الثاني أن الحزمة المقروءة تتضمن جهة تصديق خاطئة أو تُطبَّق على اتصال TLS خاطئ.

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