strongSwan: કી પ્રકાર, લોડર અને ખોટો backend

ફાઇલ એક્સ્ટેન્શન કી અલ્ગોરિધમ ઓળખતા નથી, અને .pem આવરણમાં RSA અથવા ECDSA સામગ્રી હોઈ શકે છે. PEM વર્ણવે છે કે બાઇટ્સ કેવી રીતે લપેટાય છે, જ્યારે RSA અને ECDSA અલગ અલગ અલ્ગોરિધમના નામ છે, અને PKCS12 ફાઇલ ત્રીજી વસ્તુ છે. strongSwan પ્લગઇન અને કન્ફિગરેશન backend દ્વારા ઓળખપત્રો લોડ કરે છે, તેથી પ્રમાણપત્ર યાદીમાં દેખાઈ શકે છે જ્યારે ખાનગી કી ક્યારેય વાપરી શકાય તેવી બનતી નથી. કોઈપણ રહસ્ય સંપાદિત કરતા પહેલાં તે સ્તરો અલગ કરો.

એન્કોડિંગ, અલ્ગોરિધમ અને પેકેજિંગ ત્રણ સ્તર છે

કી ફાઇલમાં એન્કોડિંગ, અલ્ગોરિધમ અને ઘણી વાર કન્ટેનર હોય છે. PEM જાણીતું base64 આવરણ છે; DER તેનું બાઇનરી સમકક્ષ છે; PKCS12 પ્રમાણપત્રને તેની કી અને શૃંખલા સાથે જોડે છે. પ્રમાણપત્ર-શૃંખલા ફાઇલ બીજું કન્ટેનર છે, અને સામાન્ય રીતે તેમાં કોઈ ખાનગી કી હોતી નથી. આમાંથી કોઈ લેબલ કહેતું નથી કે અંદરની સામગ્રી RSA છે કે ECDSA.

અલ્ગોરિધમ ઑબ્જેક્ટમાંથી જ વાંચો. પ્રદાતાનું માર્કેટિંગ નામ અથવા ફાઇલ એક્સ્ટેન્શન પુરાવો નથી, કારણ કે એક જ જારીકર્તા અલગ અલગ કી પ્રકારો આપી શકે છે.

લોડરને દોષ આપતા પહેલાં જાહેર કીઓ સરખાવો

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

બીજો આદેશ તમારા મશીન પરની ખાનગી સામગ્રીને સ્પર્શે છે પણ ફક્ત જાહેર અડધો ભાગ બહાર કાઢે છે. એમ જ રાખો, અને ક્યારેય ટિકિટમાં ખાનગી કી પેસ્ટ કરશો નહીં. જો કી એન્ક્રિપ્ટ થયેલી હોય, તો સપોર્ટેડ સાધનને પાસફ્રેઝ પૂછવા દો, કમાન્ડ લાઇન પર મૂકવાને બદલે જ્યાં પ્રોસેસ સૂચિ તેને ખુલ્લું કરી શકે.

જૂની ipsec.secrets અથવા swanctl ઓળખપત્રો

strongSwan માં સામાન્ય રીતે વપરાતા બે ઓળખપત્ર માર્ગો છે. જૂનો starter સ્ટેક પ્રકાર-વિશિષ્ટ એન્ટ્રીઓ વાંચે છે ipsec.secrets, અને દરેક એન્ટ્રીએ સામગ્રી માટે સાચો પ્રકાર જણાવવો જોઈએ. swanctl અને vici સ્ટેક પોતાની ઓળખપત્ર ડિરેક્ટરીમાંથી પોતાની કન્ફિગરેશન દ્વારા કી લોડ કરે છે. જે ફાઇલ ચાલુ backend વાંચતું નથી તેને સંપાદિત કરવાથી કંઈ બદલાતું નથી.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

કયું backend ખરેખર ચાલી રહ્યું છે તે શોધો, પછી કી ત્યાં મૂકો જ્યાં તે backend જુએ છે. strongSwan 5.9 જૂનું માર્ગદર્શિકા પ્રકાર-વિશિષ્ટ રહસ્ય એન્ટ્રીઓ વ્યાખ્યાયિત કરે છે, અને તે swanctl દસ્તાવેજીકરણ નથી. બંનેને ભેળવવાથી એવું daemon બને છે જે એવી ફાઇલને અવગણે છે જેને વ્યવસ્થાપક સત્તાવાર માને છે. કોઈ ભૂલ ન જણાવતું રીલોડ ફક્ત એનો અર્થ છે કે કન્ફિગરેશન પાર્સ થયું.

લોડ ઇવેન્ટ અને પ્રમાણીકરણ પરિણામ વાંચો

નિયંત્રિત રીલોડ પછી, ચોક્કસ કી માટે daemon નું પોતાનું લોડિંગ આઉટપુટ વાંચો. સ્ટેટસ ડમ્પમાં સૂચિબદ્ધ પ્રમાણપત્ર દર્શાવતું નથી કે ખાનગી કી તેની સાથે મેળવવામાં આવી છે.

જો ક્લાઇન્ટ હજી પણ નિષ્ફળ જાય, તો સર્વર ઇવેન્ટ અને ક્લાઇન્ટ ભૂલ અલગ રાખો. શૃંખલા માન્યતા, ઓળખ મેળ અને પદ્ધતિ સુસંગતતા પોતાના પુરાવા સાથેના પછીના પ્રશ્નો છે. પરિણામ ચોક્કસ કી પાથ અને તમે સરખાવેલા ડાયજેસ્ટ સાથે લખો, કારણ કે આગલી પાળી અન્યથા એ જ રીલોડનું પુનરાવર્તન કરશે. લોડર વિસંગતિ માટે CA બદલવો પહેલો પ્રતિભાવ નથી.