OCSP વિરુદ્ધ CRL: દરેક રિવોકેશન ચેક ખરેખર કેવી રીતે કામ કરે છે

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

પગલું 1: દરેક ચેક શું પરત આપે છે અને કેટલા સમય સુધી વાપરી શકાય તેવું રહે છે

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

તેથી કેશિંગ એ પહેલું નક્કી કરવાનું છે: કયો ઘટક નકલ રાખે છે, અને એ નકલ કઈ મર્યાદાનું પાલન કરે છે. ગેટવે પર મર્યાદા nextUpdate ઓછા સલામતી માર્જિન હોવી જોઈએ, ક્યારેય નહીં કે HTTP કેશ હેડર આકસ્મિક રીતે શું સૂચવે. openssl crl -in issuer.crl -noout -lastupdate -nextupdate બંને તારીખો છાપે છે, અને જેનું nextUpdate પહેલેથી ભૂતકાળમાં છે એવી યાદીને ફક્ત જૂની નહીં, ગુમ થયેલી ગણવી જોઈએ.

પગલું 2: પ્રમાણપત્ર ક્લાયન્ટને ક્યાં દોરે છે

લીફ પ્રમાણપત્ર સામાન્ય રીતે બે સંકેત ધરાવે છે: CRL વિતરણ બિંદુ એક્સ્ટેન્શન અને OCSP માટે ઓથોરિટી માહિતી ઍક્સેસ એન્ટ્રી. openssl x509 -in client.pem -noout -ext crlDistributionPoints પહેલું છાપે છે, અને બીજું openssl x509 -in client.pem -noout -text ના AIA વિભાગ હેઠળ આવેલું છે. બંનેમાંથી કોઈપણ એક્સ્ટેન્શન એ નિર્દેશક છે, બંધન નહીં. જે ક્લાયન્ટ ક્યારેય રિવોકેશન ચેકિંગ લાગુ કરતું નથી તે એવા પ્રમાણપત્ર સાથે એકદમ સારી રીતે જોડાશે જેનાં એક્સ્ટેન્શન એક વર્ષથી મૃત પ્રતિસાદકનું નામ આપે છે.

વિતરણ બિંદુઓ ઘણી વાર એવું આંતરિક હોસ્ટ નામ આપે છે જે ફક્ત એક નેટવર્ક સેગમેન્ટની અંદર જ ઉકેલાય છે, અને કેટલાક જૂના ક્લાયન્ટ ldap URL સંપૂર્ણપણે નકારી કાઢે છે. પહોંચની ક્ષમતા એ હોસ્ટ પરથી ચકાસો જે ટનલ સમાપ્ત કરે છે, તમારા પોતાના લેપટોપ પરથી નહીં, કારણ કે તે જ એકમાત્ર દૃષ્ટિકોણ છે જેની નિષ્ફળતા ખરેખર મહત્ત્વની છે.

પગલું 3: વિક્ષેપ પહેલાં fail-closed કે fail-open પસંદ કરો

પહોંચ વિનાનું પ્રતિસાદક અથવા સમાપ્ત થયેલી યાદી નિર્ણય ફરજિયાત બનાવે છે: જોડાણ નકારો, અથવા સ્વીકારો અને અંતર નોંધો. OpenSSL નો verify સબકમાન્ડ કડક પસંદગીને સ્પષ્ટ કરે છે, કારણ કે -crl_check ઉમેરવાથી ઉપલબ્ધ ન હોય તેવું CRL unable to get certificate CRL અને નિષ્ફળ ચકાસણી બની જાય છે. મોટાભાગના સ્ટેકમાં સોફ્ટ-ફેઇલ કોઈ ધ્વજ નથી જ, તે ચેકની ગેરહાજરી છે, અને એટલે જ તે આકસ્મિક રીતે શિપ થાય છે.

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

પગલું 4: ટ્રાફિક સ્વીકારાય છે ત્યાં જ ચેક ચાલે છે તે સાબિત કરો

જે પ્રક્રિયા જોડાણ સમાપ્ત કરે છે અથવા અધિકૃત કરે છે તે શોધો, પછી તેને રિવોકેશન ચેકિંગ સક્ષમ કરતી કન્ફિગરેશન લાઇન વિશે પૂછો. જે ગેટવે સાંકળને માન્ય કરે છે પણ ક્યારેય રિવોકેશન વિશે પૂછતું નથી તે તમારા દસ્તાવેજીકરણમાંની નીતિ કરતાં અલગ નીતિ લાગુ કરે છે, અને પ્રમાણપત્ર સાંકળનો કોઈ સ્ક્રીનશોટ તેનાથી વિરુદ્ધ સાબિત કરતો નથી. OpenVPN આ વિકલ્પને crl-verify લખે છે; strongSwan CRL અને OCSP શોધને CA કન્ફિગરેશન હેઠળ રાખે છે, જ્યાં crl_uris અથવા ocsp_uris સેટ થાય છે. જો તમે બંનેથી કોઈ તરફ ઇશારો પણ ન કરી શકો, તો ધારો કે ચેક ગેરહાજર છે.

OCSP પ્રતિસાદ ત્યારે જ ગણાય છે જ્યારે ઇશ્યુઇંગ CA એ સહી કરી હોય, અથવા જ્યારે તે CA દ્વારા સોંપાયેલ OCSPSigning એક્સ્ટેન્ડેડ કી યુઝેજ ધરાવતું પ્રતિસાદક સહી કરે, તેથી અસંબંધિત સેવાનો જવાબ કંઈ સાબિત કરતો નથી. જો તમે પોતે પ્રતિસાદક ચલાવો છો, તો તેને કઠોર નિર્ભરતા તરીકે દેખરેખ કરો, કારણ કે એક મૃત સેવા એકસાથે દરેક fail-closed ક્લાયન્ટ માટે વિક્ષેપ બની જાય છે.

પગલું 5: જાણી જોઈને એક પ્રમાણપત્ર રિવોક કરો

ટેસ્ટ પ્રમાણપત્ર લો, ઉત્પાદન જે ચેનલ વાપરે છે તે જ ચેનલ દ્વારા તેને રિવોક કરો, અને પ્રતિસાદકને સીધું પૂછો. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text એ રિવોકેશન સમય સાથે Cert Status: revoked ની જાણ કરવી જોઈએ, અને good જવાબનો અર્થ છે કે તમારું રિવોકેશન તમારા ક્લાયન્ટ પૂછે છે તે પ્રતિસાદક સુધી પહોંચ્યું નથી. પછી યાદીના માર્ગે એ જ નિર્ણય જોવા openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem ચલાવો. એક્ઝિટ કોડને બદલે કારણની સ્ટ્રિંગ વાંચો, કારણ કે રિવોકેશન નકાર અને સાંકળની ભૂલ બંને નિષ્ફળતામાં પૂરી થાય છે.

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