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 সাধারণ home ডিরেক্টরির স্থান পরিষেবার নাগালের বাইরে করে। সার্টিফিকেট ফাইলের মোড বদলালে নামস্থান সীমা সরে না। নির্ধারিত রুট ডিরেক্টরি পরিষেবার ভেতর পূর্ণ পথের লক্ষ্যও বদলাতে পারে।

পরিষেবা কনফিগারেশনের উপযুক্ত জায়গা ব্যবহার করুন, যেমন /etc-এর নিচে ওই অ্যাপের ডিরেক্টরি, এবং প্রয়োজনীয় পড়ার অনুমতিটুকু দিন। ক্লায়েন্টের CA পথ সেখানে বদলান। প্রথম কপি ব্যক্তিগত home ডিরেক্টরিতে ছিল বলে সম্পর্কহীন ফাইল সিস্টেম সীমা সরাবেন না।

প্রথম কাজের ত্রুটিটি পড়ুন

«CA ফাইল লোড করা যায় না» আর «সার্টিফিকেট চেইন বিশ্বাসযোগ্য নয়» আলাদা ব্যর্থতা। প্রথমটি ক্লায়েন্ট কিছু যাচাই করার আগেই ঘটতে পারে। দ্বিতীয়টির অর্থ হতে পারে পড়া যায় এমন বান্ডলে ভুল কর্তৃপক্ষ আছে বা ভুল TLS সংযোগে প্রয়োগ হচ্ছে।

প্রবেশাধিকার ঠিক করে পরিষেবার প্রেক্ষাপট থেকে আবার পরীক্ষা করুন। সফল টার্মিনাল কমান্ড উপকারী তুলনা, কিন্তু পরিষেবা কোন ফাইল দেখে বা ক্লায়েন্ট কোন আস্থার কনফিগারেশন ব্যবহার করে তার প্রমাণ নয়।