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 కనెక్షన్‌కు వర్తింపజేస్తున్నారు అని సూచించవచ్చు.

యాక్సెస్ సరిచేసిన తర్వాత సేవ కాంటెక్స్ట్ నుంచి మళ్లీ పరీక్షించండి. విజయవంతమైన టెర్మినల్ కమాండ్ ఉపయోగకర పోలికే, కానీ సేవ ఏ ఫైళ్లు చూస్తుందో లేదా క్లయింట్ ఏ నమ్మకపు అమరిక వాడుతుందో నిరూపించదు.