سرویس 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 اشتباه اعمال می‌شود.

پس از اصلاح دسترسی، از محیط سرویس دوباره آزمایش کنید. فرمان موفق ترمینال همچنان مقایسهٔ مفیدی است، اما ثابت نمی‌کند سرویس چه فایل‌هایی می‌بیند یا کلاینتش چه تنظیم اعتمادی به کار می‌برد.