VPN પ્રમાણપત્ર હજુ માન્ય નથી: ત્રણ કારણો, એક તપાસ ક્રમ
હજુ માન્ય નથી એટલે કે ઉપકરણની ઘડિયાળ પાછળ છે, વિન્ડો ખરેખર પછી શરૂ થાય છે, અથવા મધ્યવર્તી પ્રમાણપત્ર હજુ ખૂલ્યું નથી. તેમને આ ક્રમમાં તપાસો.
તમે ક્લાયન્ટ ખોલો છો, મહિનાઓથી વાપરી રહ્યા છો તે પ્રોફાઇલ પસંદ કરો છો, અને તે "certificate is not yet valid" સાથે અટકી જાય છે. તમારા સાઇન-ઇનમાં કંઈ બદલાયું નથી, અને ટ્રસ્ટ સ્ટોર સંભવતઃ ઠીક છે: હેન્ડશેકમાં રજૂ થયેલું પ્રમાણપત્ર એવી માન્યતા વિન્ડો ધરાવે છે જે ચકાસનાર વાપરે છે તે ક્ષણ પછી શરૂ થાય છે. ત્રણ અલગ પરિસ્થિતિઓ બરાબર એ જ સંદેશ ઉત્પન્ન કરે છે, અને તેમને અલગ પગલાં જોઈએ છે. નીચેનો ક્રમ ઘડિયાળ કે પ્રમાણપત્ર ફાઇલને સ્પર્શ કરતાં પહેલાં કહે છે કે તમારી પાસે કઈ છે.
ત્રણ કારણોમાંથી તમે કયું જોઈ રહ્યા છો
પ્રથમ કારણ સ્થાનિક છે: તપાસ કરતા ઉપકરણની ઘડિયાળ પ્રમાણપત્રની શરૂઆતની તારીખ કરતાં પહેલાંની છે. તે મૃત CMOS બેટરીવાળા હાર્ડવેર પર, જૂના સ્નેપશોટમાંથી પુનઃસ્થાપિત વર્ચ્યુઅલ મશીનો પર, સમય ગુમાવવા માટે પૂરતા સમય બંધ રહેલા ઉપકરણો પર, અને જ્યાં આઉટબાઉન્ડ NTP અવરોધિત છે અને કોઈએ ધ્યાન ન આપ્યું તેવા નેટવર્ક પર દેખાય છે. પ્રમાણપત્ર સંપૂર્ણપણે માન્ય હોઈ શકે અને તેમ છતાં આ રીતે નિષ્ફળ જાય.
બીજું કારણ ઇશ્યુઅરનું છે, કારણ કે પ્રમાણપત્ર ખરેખર ભવિષ્યમાં શરૂ થાય છે: વહેલું ઇશ્યુ થયેલું, સ્પષ્ટ શરૂઆતના સમય સાથે જનરેટ થયેલું, અથવા હજુ ન ચાલેલા એક્ટિવેશન પગલાના ભાગ રૂપે સહી કરેલું. ત્રીજું કારણ સૌથી વધુ સમય બગાડે છે, કારણ કે લીફ વર્તમાન છે જ્યારે રજૂ કરેલી ચેઇનમાંનું બીજું પ્રમાણપત્ર નથી, તેથી ભૂલ એવી સામગ્રીનું નામ આપે છે જે તમે ક્યારેય ઇન્સ્ટોલ કરી નથી.
એક પ્રશ્ન તેમને અલગ પાડે છે. નિષ્ફળતા ઉપકરણને અનુસરે છે કે સેવાને? એક જ નેટવર્ક પર અલગ રીતે વર્તતા બે મશીન ઘડિયાળો તરફ ઇશારો કરે છે. દરેક ક્લાયન્ટ એક જ રીતે નિષ્ફળ જાય તો તે પ્રમાણપત્રની વિન્ડો અને તેની પાછળની ચેઇન તરફ ઇશારો કરે છે.
ખરેખર રજૂ થયેલા પ્રમાણપત્રમાંથી વિન્ડો વાંચો
અગાઉના ડિપ્લોયમેન્ટમાંથી બચેલી PEM ફાઇલ તપાસશો નહીં; સેવાને હમણાં મોકલે છે તે ચેઇન માટે પૂછો. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts ચેઇનનું દરેક પ્રમાણપત્ર છાપે છે. તમને જરૂરી બ્લોક સાચવો અને openssl x509 -noout -subject -issuer -dates ચલાવો; છેલ્લું notBefore અને notAfter છાપે છે, અને એ બે મૂલ્યો જ નિર્ણય કરે છે. Windows પર, કનેક્શનનો પ્રમાણપત્ર સંવાદ અને નિકાસ કરેલી ફાઇલ પર certutil -dump એ જ ફીલ્ડ બતાવે છે.
વિન્ડોના બંને છેડા વાંચો, ફક્ત શરૂઆત નહીં. બે કલાકમાં ખૂલતું પ્રમાણપત્ર અને બે કલાકમાં બંધ થતું પ્રમાણપત્ર અલગ સંદેશાઓ સાથે નિષ્ફળ જાય છે અને અલગ ટીમોને સંડોવે છે. ભૂલ કયા પ્રમાણપત્રનું નામ આપે છે તે નોંધો — લીફ, મધ્યવર્તી કે રૂટ — કારણ કે તે નક્કી કરે છે કે ક્લાયન્ટ બાજુ પર કંઈ સુધારી શકાય છે કે નહીં.
તમે વિન્ડોની રાહ જોયા વિના પણ તેની કસોટી કરી શકો છો. ચકાસણી સ્પષ્ટ સમય સ્વીકારે છે: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem તે ટાઇમસ્ટેમ્પ પર ચેઇનનું મૂલ્યાંકન કરે છે. નિષ્ફળતા પુનઃઉત્પન્ન કરવા વર્તમાન સમય સાથે ચલાવો, પછી વિન્ડો ખૂલ્યા પછી એ જ ચેઇન પાસ થાય તેની પુષ્ટિ કરવા પ્રમાણપત્રના શરૂઆતના સમય સાથે ચલાવો. RFC 5280 માન્યતા ફીલ્ડ અને તેની બહાર પ્રમાણપત્રનો ઉપયોગ ન કરવાનો નિયમ વ્યાખ્યાયિત કરે છે, અને તમારા ક્લાયન્ટે હમણાં જ તે નિયમ લાગુ કર્યો છે.
તમારી ઘડિયાળ, કે તેમની
ઉપકરણની ઘડિયાળને UTCમાં પ્રમાણપત્રની શરૂઆત સાથે, તમે વિશ્વાસ કરો તેવા સ્રોતથી સરખાવો. date -u ક્ષણ આપે છે, અને systemd હોસ્ટ પર timedatectl status ઘડિયાળ સિંક્રોનાઇઝ્ડ છે કે નહીં તે પણ જણાવે છે. Windows પર, w32tm /query /status વર્તમાન સ્રોત અને છેલ્લું સફળ સિંક્રોનાઇઝેશન બતાવે છે. ટ્રેમાં દેખાતો ટાઇમ ઝોન દર્શાવવાની પસંદગી છે, ખોટી ઘડિયાળ નહીં; ચકાસનાર UTC ક્ષણોની સરખામણી કરે છે.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
ઘડિયાળ પાછળ હોય તો, કોઈપણ પ્રમાણપત્ર સામગ્રી બદલતાં પહેલાં ફરી સિંક્રોનાઇઝ કરો અને ફરી કસોટી કરો. મિનિટો કે કલાકો ખોટું હોય તેવું ઉપકરણ પોતાને મળતા દરેક તાજેતરમાં ઇશ્યુ થયેલા પ્રમાણપત્રને નકારે છે, ફક્ત એક સેવાને નહીં, તેથી એક-સેવાની સમજૂતી સામાન્ય રીતે ખોટી હોય છે. ઘડિયાળ સાચી અને સિંક્રોનાઇઝ્ડ હોય તો ઉપકરણ તરફ જોવાનું બંધ કરો: વિન્ડો ઇશ્યુઅરની છે, અને તેને પાસ કરાવવા કોઈ સ્થાનિક સેટિંગ બદલવું ન જોઈએ.
એ ટેબલ આખો નિર્ણય છે. પ્રમાણપત્ર જે ધારે છે તેના પર ઘડિયાળ ખસેડવી સમારકામ નથી, અને સમય-તપાસ બંધ કરવી પણ સમારકામ નથી, કારણ કે બંને ભૂલ ઉત્પન્ન કરનારી સ્થિતિ છુપાવે છે.
લીફ ઠીક દેખાય ત્યારે ચેઇન કેમ નિષ્ફળ જાય છે
નવીકરણ કરેલા લીફ અને બદલીના મધ્યવર્તી પ્રમાણપત્રો સામાન્ય રીતે સાથે મોકલાય છે, અને હંમેશા એક જ ક્ષણે પહોંચતા નથી. સેવા એવા મધ્યવર્તી દ્વારા સહી કરેલું નવું લીફ મોકલી શકે છે જેની પોતાની વિન્ડો પછી શરૂ થાય છે, અથવા તાજા લીફ હેઠળ જૂનું મધ્યવર્તી પરોસવાનું ચાલુ રાખી શકે છે. બંને રીતે લીફની પોતાની તારીખો વ્યાજબી દેખાય ત્યારે ચેઇન નિષ્ફળ જાય છે.
લોડ-બેલેન્સ્ડ એન્ડપોઇન્ટ આને તૂટેલાથી અસંગતમાં ફેરવે છે. ફરી પ્રયાસ સફળ થાય, અથવા એક નેટવર્ક ચાલે અને બીજું ન ચાલે, તો સેટિંગ્સ બદલતાં પહેલાં કયા પીઅરે જવાબ આપ્યો અને કઈ ચેઇન મોકલી તે નોંધો. openssl s_client કનેક્ટ થયેલું સરનામું છાપે છે, તેથી થોડા પ્રયાસો જાહેર કરે છે કે દરેક નોડ એ જ ચેઇન પરોસે છે કે નહીં.
ચકાસણી અકબંધ રાખતા સમારકામના માર્ગો
ઘડિયાળની સમસ્યા ઉપકરણ પર ચકાસણી ચાલુ રાખીને સુધારાય છે. પ્રમાણપત્રની સમસ્યા ઓપરેટર દ્વારા હવેને સમાવતી વિન્ડો માટે ઇશ્યુ થયેલી સામગ્રીથી સુધારાય છે. કોઈ ક્લાયન્ટ સેટિંગ હજુ-અમાન્ય પ્રમાણપત્રને માન્ય બનાવતું નથી; સમય-તપાસ છોડી દેતા ફ્લેગ નિદાનની પુષ્ટિ કરવા માટે છે, તેમને ઉત્પાદનમાં મોકલવા માટે નહીં.
પ્રમાણપત્ર આયોજિત એક્ટિવેશન માટે તૈયાર હોય ત્યારે કટઓવર યોજના અનુસરો. તેની વિન્ડો ખૂલે ત્યારે ઇન્સ્ટોલ કરો, અથવા પ્રદાતા દસ્તાવેજ કરે છે તે ઓવરલેપ પ્રક્રિયા વાપરો, વહેલું ઇન્સ્ટોલ કરીને વપરાશકર્તાઓને ચેતવણીઓમાંથી ક્લિક કરતાં શીખવવાને બદલે. લોકો જે ચેતવણીઓને અવગણતા શીખે છે તે ટૂંકા વિલંબ કરતાં વધુ ખર્ચ કરાવે છે.
છેલ્લે, નિષ્ફળતા જે રીતે થઈ તે રીતે ફરી કસોટી કરો: નવું સત્ર, એ જ ક્લાયન્ટ, તમને ખરેખર જરૂરી સંસાધન. TLS લાઇબ્રેરીઓ કનેક્શનના આયુષ્ય સુધી ચકાસાયેલી ચેઇન કેશ કરી શકે છે, અને ફરી શરૂ થયેલું સત્ર તેને ફરી તપાસે તે જરૂરી નથી, તેથી જૂનું સત્ર સુધારા પછી પણ નિષ્ફળ થતું રહી શકે અથવા પ્રતિગમન પછી પણ કામ કરતું રહી શકે. વ્યુઅરમાં ખૂલતી ફાઇલ ફક્ત ફાઇલ વાંચી શકાય તેવી છે તે સાબિત કરે છે; પૂર્ણ થયેલો હેન્ડશેક ચેઇન માન્ય થાય છે તે સાબિત કરે છે.
ટિકિટ બંધ કરતાં પહેલાં ચાર વસ્તુઓની પુષ્ટિ કરો: નિષ્ફળ ઉપકરણનો UTC સમય અને સિંક સ્થિતિ, રજૂ કરેલી ચેઇનના દરેક પ્રમાણપત્રનું notBefore અને notAfter, બીજા ક્લાયન્ટથી એ જ ચેઇન, અને ભૂલ પ્રમાણપત્રને જે નામ આપે છે તે. ઘડિયાળ સાચી હોય અને વિન્ડો ન ખૂલી હોય તો બાકીનું ઓપરેટરનું કામ છે, અને તમારી બાજુનું સાચું પગલું ચકાસણી નબળી કરવાને બદલે વિન્ડોની રાહ જોવાનું છે.