OCSP vs 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 ప్రతిస్పందనలో ఏమి ఉంటుందో నిర్వచిస్తుంది, ఈ పరీక్ష చదివే స్థితి విలువలతో సహా.