રદ કરેલા VPN પ્રમાણપત્ર હજી જોડાય છે? CRL અમલીકરણ તપાસો
રદ કરેલા પ્રમાણપત્રો હજી જોડાય છે જ્યારે CRL ક્યારેય ચકાસનાર સુધી પહોંચતું નથી. આ ક્રમમાં જારીકર્તા, લોડ કરેલી ક્રમિક સંખ્યા, ફરી લોડ કરવાનું વર્તન અને સક્રિય સત્રો તપાસો.
તમે પ્રમાણપત્ર રદ કર્યું, નવી યાદી બનાવી, અને જૂની પ્રોફાઇલ હજી ટનલ ઊભી કરે છે. રદ કરવું પોતે તૂટેલું નથી: CRL એ સહી કરેલી ઘોષણા છે કે ક્રમિક સંખ્યા હવે માન્ય નથી, અને તે પ્રવેશ ત્યારે જ બદલે છે જ્યારે TLS સમાપ્ત કરતો ઘટક તેને યોગ્ય જારીકર્તા માટે લોડ કરે, સ્વીકૃતિનો નિર્ણય લેતા પહેલા. આવા મોટા ભાગના કિસ્સા ત્યાં જ છે, અને તેથી રદ કરવું અને નકારવું બે અલગ તથ્યો છે.
નીચેની પાંચ તપાસ ક્રમમાં કરો અને પહેલી નિષ્ફળ જતાં અટકો, કારણ કે દરેક પછીની તપાસ અગાઉની સાચી હોવાનું ધારે છે.
કયો ઘટક સ્વીકૃતિનો નિર્ણય લે છે તે તપાસો
જે પ્રક્રિયા ક્લાયન્ટ પ્રમાણપત્રની ચકાસણી કરે છે તેનું નામ આપો, કારણ કે ફક્ત તે જ પ્રક્રિયા યાદી અમલમાં મૂકી શકે છે. OpenVPN સર્વર પર તે ડેમન પોતે છે, crl-verify સાથે ગોઠવાયેલું. ocserv માં તે ocserv.conf માંની crl લાઇન છે. strongSwan માં ઇનપુટ લોડ કરેલા CRL છે strictcrlpolicy સાથે. VPN સામે TLS સમાપ્ત કરતો પ્રોક્સી કે ઉપકરણ પણ ખરો ચકાસનાર હોઈ શકે, અને એમ હોય તો તેની પાછળનો ડેમન ક્લાયન્ટ પ્રમાણપત્ર ક્યારેય જોતો નથી.
WireGuard બીજી શ્રેણીમાં આવે છે. તેની પાસે ન પ્રમાણપત્રો છે ન રદ કરવાની યાદી; પીઅરને રૂપરેખાંકનમાં તેની જાહેર કી દ્વારા સ્વીકારવામાં આવે છે, તેથી પ્રવેશ સમાપ્ત કરવાનો અર્થ તે કી દૂર કરવી છે. જો તમે ફક્ત WireGuard વાળી જમાવટમાં CRL શોધી રહ્યા હો, તો તે પદ્ધતિ ત્યાં નથી.
ક્લાયન્ટ બાજુના જાળમાંથી પણ સાવધ રહો. જે ક્લાયન્ટ સર્વરનું પ્રમાણપત્ર ન ગમતાં જોડાવાનો ઇનકાર કરે છે તે સર્વરની સાંકળ લાગુ કરે છે, પોતાના ઓળખપત્રો રદ કરતું નથી. વપરાશકર્તા પ્રમાણપત્ર ફક્ત ત્યાં જ રદ થાય છે જ્યાં તે વપરાશકર્તા પ્રમાણપત્ર ચકાસાય છે, અને તે લગભગ હંમેશા સર્વર બાજુ હોય છે.
યાદી કયા જારીકર્તા માટે સહી કરાઈ છે તે તપાસો
CRL એક જ જારીકર્તા CA સુધી મર્યાદિત છે. મૂળ અને મધ્યવર્તી CA સાથે પાનાંનાં પ્રમાણપત્રો મધ્યવર્તીમાંથી આવે છે, તેથી મહત્ત્વની યાદી મધ્યવર્તીની CRL છે; મૂળની યાદી તે પાનાં વિશે કંઈ કહેતી નથી. ખોટી ફાઇલ તરફ નિર્દેશ કરતો ચકાસનાર તેને આનંદથી પાર્સ કરે છે, મેળ ખાતી એન્ટ્રી મળતી નથી અને બધું સ્વીકારી લે છે.
ડેમનને સ્પર્શ કરતાં પહેલાં જોડીની પુષ્ટિ કરો. પ્રમાણપત્ર પરનો જારીકર્તા યાદીના subject સાથે મેળ ખાવો જોઈએ:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateજ્યારે બંને એક જ CA તરફથી આવે, ત્યારે પ્રમાણપત્ર માટે છાપેલી ક્રમિક સંખ્યા એ જ મૂલ્ય છે જે યાદીમાં આવવું જોઈએ. જો તે મેળ ન ખાય, તો તમારી પાસે ખોટી CRL કે તેની ખોટી નકલ છે.
માન્યતા એ જ તપાસની છે. ભૂતકાળમાંનું nextUpdate યાદીને જૂની બનાવે છે, અને બંધ રીતે નિષ્ફળ જતો ચકાસનાર ત્યારે ફક્ત રદ કરેલા જ નહીં પરંતુ દરેક ક્લાયન્ટને નકારશે.
ક્રમિક સંખ્યા ડેમને લોડ કરેલી નકલમાં છે કે નહીં તે તપાસો
રદ કરવું CA ડેટાબેઝમાં નોંધ લખે છે, અને ફરી ઉત્પાદન નવી ફાઇલ લખે છે. બંનેમાંથી કોઈ ક્રિયા શરૂ થતાં જૂની નકલ લોડ કરેલા ચાલુ ડેમન સુધી પહોંચતી નથી. યાદી ડમ્પ કરો અને ક્રમિક સંખ્યા શોધો:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlપછી તપાસો કે તમારો અમલ ફાઇલ કેવી રીતે લે છે. OpenVPN crl-verify ને આપેલો માર્ગ શરૂ થતાં એક વાર વાંચે છે, તેથી નવી યાદી માટે ફરી શરૂ કરવું કે ફરી શરૂ કરવાનો સંકેત જરૂરી છે; એ જ વિકલ્પ કોઈ ડિરેક્ટરી તરફ હોય તો દરેક જોડાણે ફરી વંચાય છે, અને તેથી ડિરેક્ટરી મોડ છે. strongSwan એ તેના ઓળખપત્રો ફરી લોડ કરવા પડે, ઉદાહરણ તરીકે swanctl --load-creds સાથે. ફાઇલ ડિસ્ક પર સાચી હોવી અને ચકાસનાર તેનો ઉપયોગ કરવો એ બે અલગ તથ્યો છે.
ખૂટતી કે સમાપ્ત થયેલી યાદીની નીતિ તપાસો
આ એ નિર્ણય છે જે ઘણી જમાવટો કદી સ્પષ્ટ રીતે લેતી નથી, અને તે નક્કી કરે છે કે રદ કરવું તમારું રક્ષણ કરે છે કે સૌને બહાર તાળું મારે છે. Fail-closed એટલે કે વાપરી શકાય તેવી રદની માહિતી વગર નકાર થાય છે; fail-open એટલે કે ચકાસનાર તેના વગર આગળ વધે છે. strongSwan પસંદગીને strictcrlpolicy તરીકે બતાવે છે. OpenVPN crl-verify સાથે એવી ફાઇલ પર શરૂ થવાનો ઇનકાર કરે છે જે તે વાંચી કે પાર્સ કરી શકતું નથી, અને સમાપ્ત થયેલી યાદી શાંત સ્વીકૃતિને બદલે સમાપ્ત CRL વિશે TLS ચકાસણી ભૂલ તરીકે દેખાય છે.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
તમે કોઈ પણ દિશા પસંદ કરો, સ્વયંકરણ પસંદગી કરતાં વધુ મહત્ત્વનું છે: CRL ને nextUpdate પહેલાં ફરી બનાવતું કાર્ય, અને જમાવેલી નકલ જૂની થાય ત્યારેની ચેતવણી, બંને નીતિઓને ઘટના બનતાં રોકે છે. OCSP સાથે ઓનલાઇન તપાસ તાજગીને ઉત્તરદાતા તરફ ખસેડે છે, પણ એ જ નિયમ લાગુ છે, કારણ કે જવાબ ચકાસવા ગોઠવાયેલો ન હોય તેવો ચકાસનાર કંઈ બદલતો નથી.
સક્રિય સત્ર તપાસો, પછી કીની નકલો
રદ કરવાનું મૂલ્યાંકન પ્રમાણપત્ર ચકાસણી દરમિયાન થાય છે, જે જોડાતી વખતે અને ફરી વાટાઘાટ થતી વખતે થાય છે. સ્થાપિત સત્ર ફરી વાટાઘાટ ન થાય ત્યાં સુધી ચાલે છે, અને OpenVPN નું મૂળભૂત મૂલ્ય reneg-sec 3600 સાથે કલાકમાં એક વાર છે. જો વ્યક્તિએ હમણાં જ નેટવર્કની બહાર જવું હોય, તો યાદી પ્રકાશિત કરવાની સાથે સત્ર પણ સમાપ્ત કરો, અને પછી ખાતરી કરો કે ફરી જોડાણ નકારાય છે.
ઓળખપત્રોને તેમની નકલોથી અલગ રાખો. એક લેપટોપ પર પ્રોફાઇલ ડિલીટ કરવાથી એ જ ખાનગી કીની બીજી નકલને પ્રમાણિત થવાથી રોકાતું નથી; રદ કરવું એ જ દરેક નકલને નકામી બનાવે છે, અને તે પણ પહેલાની તપાસ સાચી હોય ત્યારે જ. બદલીનું ઉપકરણને પોતાનું પ્રમાણપત્ર આપો જેથી એકને બીજાને સ્પર્શ કર્યા વગર રદ કરી શકાય.
આને પૂર્ણ કહેતાં પહેલાં: ચકાસનાર ઘટક ઓળખાયું છે, યાદીનો જારીકર્તા પાનાના જારીકર્તા સાથે મેળ ખાય છે, રદ કરેલી ક્રમિક સંખ્યા ડેમને ખરેખર લોડ કરેલી નકલમાં છે, ખૂટતી કે સમાપ્ત થયેલી યાદીઓની નીતિ જાણી જોઈને છે અને દેખરેખ હેઠળ છે, અને સક્રિય સત્ર રાહ જોવાને બદલે સમાપ્ત કરાયું છે. આ સૌ પાછળના ફોર્મેટ RFC 5280 માં નિર્દિષ્ટ છે.