પ્રમાણપત્રો માન્ય હોવા છતાં નવા VPN લૉગિન નિષ્ફળ થાય છે: CRL તપાસો

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

બે સમયપત્રકોને અલગ પાડવું એ જ આખું નિદાન છે, અને તે નક્કી કરે છે કે સુધારો કેવો હોવો જોઈએ.

બે ઘડિયાળો, અને તેમાંથી ફક્ત એક જ પ્રમાણપત્ર છે

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

બંને વસ્તુઓના માલિકો પણ જુદા છે: પ્રમાણપત્ર તેને ઇશ્યુ કરનાર CA પાસેથી આવે છે, જ્યારે યાદી સમયપત્રક પ્રમાણે તે CA ચલાવનાર વ્યક્તિ દ્વારા બનાવવામાં આવે છે. વપરાશકર્તા તેને તાજી કરી શકતો નથી, અને પ્રમાણપત્રો ફરી ઇશ્યુ કરવાથી તે લંબાવી શકાતી નથી.

સેવા ખરેખર જે યાદી લોડ કરે છે તે વાંચો

તમે ધારો છો તે ફાઇલથી નહીં, ચાલુ રૂપરેખાંકનથી શરૂ કરો. crl-verify નો માર્ગ સંપૂર્ણ, પ્રોફાઇલની સાપેક્ષ, અથવા ઇમેજમાં ગોઠવાયેલી નકલ હોઈ શકે છે, અને ચકાસનાર તે નકલ વાંચે છે. તેને તેની જગ્યાએ openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate વડે તપાસો અને તારીખોને સર્વરની ઘડિયાળ સાથે સરખાવો.

પછી ખાતરી કરો કે ફાઇલ ખરેખર વપરાતી ફાઇલ જ છે: openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout વડે તેના હસ્તાક્ષર તપાસો, જે ખેતરો ચૂપચાપ છાપવાને બદલે ચકાસણીનું પરિણામ જણાવે છે. બીજા CA દ્વારા સહી કરેલી યાદી, અથવા બીજી ડિરેક્ટરીમાં પડી રહેલી જૂની નકલ, સમાપ્ત થયેલી યાદીની જેમ જ નિષ્ફળ જાય છે.

શૂન્યથી નહીં, રદ કરવાના ડેટાબેઝમાંથી ફરીથી બનાવો

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

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

ચકાસનાર જ્યાં જુએ છે ત્યાં જ તૈનાત કરો

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

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

આગલી સમયમર્યાદા પસાર થાય તે પહેલાં દૃશ્યમાન બનાવો

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

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