નવીકૃત VPN પ્રમાણપત્ર: કેટલાક ક્લાયન્ટ હજી પણ તેને નકારે છે

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

એક નવીકરણ, બે વર્તન

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

નિષ્ફળ ક્લાયન્ટે કઈ પ્રોફાઇલ પસંદ કરી તે પણ તપાસો. પોતાના સ્ટોરમાં રહેતી આયાત કરેલી નકલ બદલાતી નથી જ્યારે એડમિનિસ્ટ્રેટર મૂળ ફાઇલને બીજે સંપાદિત કરે છે.

નવીકરણ ફક્ત તારીખ નહીં, ઑબ્જેક્ટ બદલે છે

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

ક્લાયન્ટ શું પિન કરે છે તે વાંચો

કેટલાક ક્લાયન્ટ તેમની પ્રોફાઇલમાં ફિંગરપ્રિન્ટ રાખે છે અને દરેક કનેક્શન પર તેની તુલના કરે છે. અન્ય તેને પ્લેટફોર્મ ટ્રસ્ટ સ્ટોરમાં સંગ્રહે છે, અને બીજા ફક્ત CA પર આધાર રાખે છે. દરેક કિસ્સામાં સમારકામ અલગ છે, તેથી પહેલાં મિકેનિઝમ ઓળખો.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

દરેક બેકએન્ડ જે પ્રમાણપત્ર આપે છે તેની તુલના કરો

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

સંચાલિત માર્ગ દ્વારા વિશ્વાસ બદલો

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

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