Эдгээр хоёр хүчингүй болгох шалгалтын нэг нь нэг гэрчилгээний талаар гарын үсэгтэй хариу буцаадаг, нөгөө нь бүхэлд нь татдаг гарын үсэгтэй жагсаалт буцаадаг. Хоёулаа баталгаажуулагчид итгэмжлэл хараахан итгэлтэй эсэхийг хэлэх зорилготой бөгөөд хоёулаа огт адилгүй аргаар бүтэлгүйтдэг. Доорх дараалал нь оператор үйлдвэрлэлд бодитоор тулгардаг зүйлийг дагана: сүлжээн дэх байтуудаас эхлээд холболтыг татгалздаг гарц хүртэл. Алхамыг алгасах нь байршуулалт зөвхөн цаасан дээр орших хүчингүй болгох бодлоготой үлдэх яг тэр зам юм.

Алхам 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 хариунд юу багтахыг тодорхойлдог бөгөөд энэ туршилтын уншдаг төлөвийн утгуудыг оруулан.

Холбоотой нийтлэлүүд