ખોટું VPN પ્રમાણપત્ર રદ કર્યું? પુનઃપ્રાપ્તિ વિકલ્પો અને મર્યાદાઓ

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

પ્રમાણપત્ર ઓળખો, વ્યક્તિ નહીં

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

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

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

ઝડપી વર્તન તપાસ કંઈપણ બદલ્યા વિના સ્થિતિની પુષ્ટિ કરે છે:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

જો તે પ્રમાણપત્રને રદ તરીકે જણાવે, તો CRL અને ક્લાયન્ટ સંમત છે; જો તે સ્વચ્છ રીતે ચકાસાય, તો તમારા હાથમાંનો ક્લાયન્ટ રદ કરેલો નથી, અને શોધ ચાલુ રહે છે.

CA એ હોલ્ડ કે કાયમી રદ કરવાનો ઉપયોગ કર્યો છે તે તપાસો

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

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

OpenSSL-આધારિત CA આ મર્યાદા દર્શાવે છે. ca આદેશ -crl_reason મૂલ્યો સ્વીકારે છે, જેમાં certificateHold અને removeFromCRL નો સમાવેશ થાય છે, પરંતુ તે ડેલ્ટા CRL બનાવતો નથી — OpenSSL CA દસ્તાવેજીકરણ તેના CRL આઉટપુટ માટે આ મર્યાદા જણાવે છે. સીરીયલ નંબર સરળ રીતે છોડી દેતું સંપૂર્ણ CRL "આ એન્ટ્રી મુક્ત કરવામાં આવી" કહેતા ડેલ્ટા કરતાં અલગ પ્રકાશન મોડેલ છે, તેથી OpenSSL-આધારિત VPN CAમાં removeFromCRL પેસ્ટ કરવાથી ધોરણો દ્વારા વ્યાખ્યાયિત મુક્તિ થતી નથી.

જો કી ખુલ્લી પડી હોઈ શકે, તો તેને બદલો

રદ કરેલું પ્રમાણપત્ર એ નિવેદન છે કે આ કી પર હવે ભરોસો કરી શકાય નહીં. જો રદ કરવું સારાંશમાં સાચું હતું — લેપટોપ ખોવાઈ ગયું, કી શેર કરેલી ડિસ્ક પર કૉપી થઈ, ખાનગી કી ટિકિટમાં પેસ્ટ થઈ — તો એ જ પ્રમાણપત્ર પુનઃસ્થાપિત કરવું એ સુરક્ષા નિર્ણયને ઉલટાવે છે જે યોગ્ય રીતે કામ કરી રહ્યો હતો.

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

જૂનું પુનઃસ્થાપિત કરવાની સુવિધાની દલીલ વાસ્તવિક છે, પરંતુ તેનો જવાબ સ્પષ્ટ રીતે આપવો જોઈએ, ચૂપચાપ નહીં. "વપરાશકર્તાને આજે ઍક્સેસની જરૂર છે" એ ઇશ્યુને ઝડપી બનાવવાનું કારણ છે, તમે જવાબદારી ન આપી શકો તેવી કીનું રદ ઉલટાવવાનું કારણ નહીં.

જો તે વહીવટી ભૂલ હતી, તો નિયંત્રણ હેઠળ બદલો

જ્યારે રદ કરવું ખાલી ખોટું હતું અને કી ક્યારેય ખુલ્લી પડી ન હતી, ત્યારે સુધારણા હજી પણ સંપાદનના બદલે નિયંત્રિત રિપ્લેસમેન્ટ છે. ઇશ્યુઅરની સમર્થિત પ્રક્રિયા વાપરો, સીરીયલ નંબર અને ઇશ્યુ ઇતિહાસ અકબંધ રાખો, અને બે લલચાવનારા શોર્ટકટ ટાળો: index.txt ની અંદર સ્થિતિ અક્ષરને R માંથી પાછો V બનાવવો, અને ઇશ્યુ પંક્તિ ડિલીટ કરવી જેથી નવું પ્રમાણપત્ર સીરીયલ નંબર ફરી વાપરી શકે.

OpenSSL CAમાં ડેટાબેઝ ટૅબ-વિભાજિત છે અને ખોટી રીતે વાંચવો સરળ છે, જે હાથથી સંપાદનને આકર્ષક બનાવે છે:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

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

રિપ્લેસમેન્ટ ઇશ્યુ કર્યા પછી, સામાન્ય મેકેનિઝમ દ્વારા નવું CRL પ્રકાશિત કરો અને ક્લાયન્ટને તે લેવા દો. CRL દૂર કરવું, તેનું આયુષ્ય શૂન્ય કરવું અથવા ક્લાયન્ટ પ્રોફાઇલમાં રદ તપાસ નિષ્ક્રિય કરવી એ CAએ ક્યારેય પ્રકાશિત કરેલા દરેક બીજા રદને નબળા પાડીને એક વપરાશકર્તાને ઠીક કરે છે.

નવી પ્રવેશની પુષ્ટિ કરો અને રેકોર્ડ રાખો

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

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

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