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 ସଂଯୋଗରେ ଲାଗୁ ହେଉଛି ହୋଇପାରେ।

ପ୍ରବେଶ ସୁଧାରି ସେବାର ପରିବେଶରୁ ପୁଣି ପରୀକ୍ଷା କରନ୍ତୁ। ସଫଳ ଟର୍ମିନାଲ୍ କମାଣ୍ଡ ଉପଯୋଗୀ ତୁଳନା, କିନ୍ତୁ ସେବା କେଉଁ ଫାଇଲ୍ ଦେଖେ କିମ୍ବା କ୍ଲାଏଣ୍ଟ କେଉଁ ବିଶ୍ୱାସ ବିନ୍ୟାସ ବ୍ୟବହାର କରେ ତାହା ପ୍ରମାଣ ନୁହେଁ।