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 જોડાણમાં લાગુ પડે છે એવો હોઈ શકે છે.

ઍક્સેસ સુધારીને સેવાના સંદર્ભથી ફરી તપાસો. સફળ ટર્મિનલ આદેશ ઉપયોગી સરખામણી છે, પરંતુ સેવા કઈ ફાઇલ જુએ છે અથવા ક્લાયન્ટ કયું વિશ્વાસ સેટઅપ વાપરે છે તે સાબિત નથી કરતો.