પ્રમાણપત્રનું નામ અસંગત કે સમાપ્તિ: બંનેને અલગ કેવી રીતે ઓળખવા

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

ભૂલનું લખાણ એ નિદાન છે

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

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

જો નિષ્ફળતા પ્રયાસો વચ્ચે બદલાય, તો તમારી પાસે ત્રીજી શક્યતા છે: એક જ નામ પાછળ એક કરતાં વધુ નોડ.

નામ ચકાસણીઓ: ક્લાયન્ટ શું સરખાવે છે

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

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

સમાપ્તિ: કોની ઘડિયાળ વંચાય છે

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

કોઈ પણ નિષ્કર્ષ પર આવતા પહેલાં ક્લાયન્ટ પર પ્રમાણપત્રની તારીખોની UTC સાથે સરખામણી કરો:

openssl x509 -in cert.pem -noout -dates
date -u

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

એકને સુધારવાથી બીજું કેમ ખૂલી જાય છે

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

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

એ વિગત જ અસ્થિર ટિકિટને પુનઃઉત્પાદનયોગ્ય બનાવે છે.

નવા કનેક્શનથી તેને સાબિત કરો

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

ચોક્કસ ભૂલ તબક્કો અને પ્રમાણપત્રની વિગતો ટિકિટ સાથે રાખો.

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