OCSP və CRL: hər ləğv yoxlaması əslində necə işləyir

Bu iki ləğv yoxlamasından biri tək bir sertifikat haqqında imzalanmış cavab qaytarır, digəri isə bütöv halda yüklədiyiniz imzalanmış siyahı qaytarır. Hər ikisi verifikatora bir etimad sənədinin hələ də etibarlı olub-olmadığını bildirmək üçündür və hər ikisi bir-birinə bənzəməyən şəkildə uğursuz olur. Aşağıdakı ardıcıllıq operatorun istehsalatda həqiqətən rastlaşdığı şeyi izləyir: naqildəki baytlardan başlayıb əlaqəni rədd edən şlüz ilə bitir. Bir addımı atlamaq, yerləşdirmənin yalnız kağızda mövcud olan ləğv siyasəti ilə yekunlaşmasının yoludur.

Addım 1: Hər yoxlama nə qaytarır və nə qədər istifadəyə yararlı qalır

CRL, buraxanın ləğv etdiyi hər sertifikatı əhatə edən tək imzalanmış obyekt kimi dərc olunur, ona görə verifikator onu bir dəfə götürür və siyahının nextUpdate-i keçənə qədər təkrar istifadə edir. OCSP cavabı daha dardır: o, dəqiq bir sertifikat üçün cavab verir və thisUpdate, producedAt və adətən nextUpdate daşıyır. Bu fərq qalan hər şeyi idarə edir. Keşlənmiş CRL səssizcə köhnəlir, çünki fayl hələ də parse olunur və imzası hələ də yoxlanılır, halbuki vaxtı keçmiş OCSP cavabı onun zaman damğalarını oxuduğunuz anda açıq şəkildə dəyərsizdir.

Buna görə keşləmə ilk dəqiqləşdirilməli şeydir: kopyanı hansı komponent saxlayır və həmin kopya hansı tavana tabedir. Şlüzdə tavan nextUpdate minus təhlükəsizlik marjası olmalıdır, heç vaxt HTTP keş başlığının təsadüfən təklif etdiyi şey deyil. openssl crl -in issuer.crl -noout -lastupdate -nextupdate hər iki tarixi çap edir və nextUpdate-i artıq keçmişdə olan siyahıya sadəcə köhnə kimi deyil, çatışmayan kimi baxılmalıdır.

Addım 2: Sertifikat müştərini hara yönəldir

Yarpaq sertifikat adətən iki işarə daşıyır: CRL paylanma nöqtəsi uzantısı və OCSP üçün səlahiyyət məlumatı girişi. openssl x509 -in client.pem -noout -ext crlDistributionPoints birincisini çap edir, ikincisi isə openssl x509 -in client.pem -noout -text çıxışının AIA bölməsi altında yerləşir. Hər hansı uzantı bir göstəricidir, öhdəlik deyil. Ləğv yoxlamasını heç vaxt tətbiq etməyən müştəri, uzantıları bir ildir ölü olan responder göstərən sertifikata tamamilə yaxşı qoşulacaq.

Paylanma nöqtələri çox vaxt yalnız bir şəbəkə seqmentinin içində həll olunan daxili host göstərir və bəzi köhnə müştərilər ldap URL-lərini tamamilə rədd edir. Əlçatanlığı tuneli sonlandıran hostdan yoxlayın, öz noutbukunuzdan deyil, çünki uğursuzluğu həqiqətən əhəmiyyət daşıyan yeganə baxış nöqtəsi budur.

Addım 3: Kəsintidən əvvəl fail-closed və ya fail-open seçin

Əlçatmayan responder və ya vaxtı keçmiş siyahı qərar məcburiyyəti yaradır: əlaqəni rədd et, ya da qəbul et və boşluğu qeyd et. OpenSSL-in verify alt əmri sərt seçimi açıq edir, çünki -crl_check əlavə etmək əlçatmaz CRL-i unable to get certificate CRL və uğursuz yoxlamaya çevirir. Əksər stack-lərdə yumşaq uğursuzluq heç bir bayraq deyil, yoxlamanın olmamasıdır və bu, onun təsadüfən göndərilməsinin dəqiq səbəbidir.

Müştərinin həqiqətən hansı davranışa sahib olduğunu görmək üçün responderı götürün və yenidən qoşulun. Tünel hələ də qalxırsa, atlanmış yoxlamanı qeyd edən log sətrini tapın, sonra soruşun ki, insident zamanı həmin sətri kimsə oxuyarmı. Eyni təchizatçı protokola görə fərqlənə bilər: bir maşındakı IKEv2 müştərisi və OpenVPN müştərisi əlaqəsiz konfiqurasiya düymələrini oxuyur.

Addım 4: Yoxlamanın trafikin qəbul edildiyi yerdə işlədiyini sübut edin

Əlaqəni sonlandıran və ya avtorizasiya edən prosesi tapın, sonra ondan ləğv yoxlamasını aktivləşdirən konfiqurasiya sətrini soruşun. Zənciri doğrulayan, lakin heç vaxt ləğv barədə soruşmayan şlüz sənədləşmənizdəki siyasətdən fərqli siyasət tətbiq edir və sertifikat zəncirinin heç bir ekran görüntüsü əksini sübut etmir. OpenVPN seçimi crl-verify kimi yazır; strongSwan CRL və OCSP axtarışlarını CA konfiqurasiyası altında saxlayır, orada crl_uris və ya ocsp_uris təyin olunur. Əgər hər ikisinə işarə edə bilmirsinizsə, yoxlamanın olmadığını qəbul edin.

OCSP cavabı yalnız buraxan CA onu imzaladıqda və ya həmin CA-nın həvalə etdiyi OCSPSigning genişləndirilmiş açar istifadəsini daşıyan responder imzaladıqda qüvvədədir, ona görə əlaqəsiz xidmətdən gələn cavab heç nə sübut etmir. Responderi özünüz işlədirsinizsə, onu sərt asılılıq kimi izləyin, çünki bir ölü xidmət birdən bütün fail-closed müştərilər üçün kəsinti olur.

Addım 5: Bir sertifikatı qəsdən ləğv edin

Test sertifikatı götürün, onu istehsalatın istifadə etdiyi kanaldan ləğv edin və responderə birbaşa sorğu göndərin. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ləğv vaxtı ilə birlikdə Cert Status: revoked bildirməlidir və good cavabı ləğvinizin müştərilərinizin sorğu göndərdiyi responderə çatmadığını göstərir. Sonra siyahı yolu ilə eyni qərarı görmək üçün openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem işlədin. Çıxış kodu yerinə səbəb sətrini oxuyun, çünki ləğv rəddi və zəncir xətası hər ikisi uğursuzluqla bitir.

Həqiqətən əhəmiyyət daşıyan addım sonuncudur: köhnə profillə real tətbiq nöqtəsinə yenidən qoşulun və rəddin ləğvdən gəldiyini təsdiqləyin. Sonra yalnız dinləyicini sındırmadığınızı sübut etmək üçün təzə, etibarlı sertifikatla yenidən qoşulun. Müştəridə profili silmək serverin qərarı barədə heç nə sübut etmir və tuneli heç vaxt sonlandırmayan maşında uğurlu openssl verify işlətməsi də sübut etmir. RFC 6960 uyğun OCSP cavabının nə ehtiva etdiyini, o cümlədən bu testin oxuduğu status dəyərlərini müəyyən edir.