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 ځواب څه لري، په شمول هغه حالت ارزښتونه چې دا ازموینه یې لولي۔