Nauji VPN prisijungimai nepavyksta, nors sertifikatai galioja: patikrinkite CRL

Sertifikatai, kuriems likę mėnesiai, ir prisijungimai, kurie nepavyksta iškart, rodo du skirtingus objektus su dviem skirtingais laikrodžiais. Serveris atmeta ryšius todėl, kad atšauktų sertifikatų sąrašas, į kurį jis kreipiasi, peržengė savo paties galiojimo pabaigos datą, o ne todėl, kad vartotojų sertifikatai paseno. Vartotojo sertifikato atnaujinimas tam sąrašui nieko neduoda.

Dviejų grafikų atskyrimas yra visa diagnozė, ir ji keičia tai, koks turi būti pataisymas.

Du laikrodžiai, ir tik vienas jų yra sertifikatas

Sertifikatas turi galiojimo langą. Sertifikatų atšaukimo sąrašas turi savo langą, be to, išdavėją ir parašą, o tikrintuvai atsisako pasitikėti sąrašu, kurio kito atnaujinimo laikas praėjo. Kai taip nutinka, klientas pateikia visiškai galiojantį sertifikatą, o serveris vis tiek nutraukia ryšį su pranešimu apie sąrašą. Vartotojai tą pranešimą perskaito kaip „sertifikatas pasibaigė“, ir atnaujinimo užklausa nukeliauja ne ten.

Du objektai turi ir skirtingus savininkus: sertifikatas ateina iš CA, kuri jį išdavė, o sąrašas generuojamas pagal grafiką to, kas valdo tą CA. Vartotojas negali jo atnaujinti, o pakartotinis sertifikatų išdavimas negali jo prailginti.

Perskaitykite sąrašą, kurį paslauga iš tikrųjų įkelia

Pradėkite nuo veikiančios konfigūracijos, o ne nuo failo, kurio tikitės. crl-verify kelias gali būti absoliutus, santykinis su profiliu arba į atvaizdą įkepta kopija, ir tikrintuvas skaito tą kopiją. Patikrinkite ją vietoje su openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate ir palyginkite datas su serverio laikrodžiu.

Tada patvirtinkite, kad failas iš tikrųjų yra naudojamas: patikrinkite jo parašą su openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, kuris praneša patikros rezultatą, o ne tyliai išspausdina laukus. Sąrašas, pasirašytas kitos CA, arba pasenusi kopija, palikta antrame kataloge, nepavyksta lygiai taip pat kaip pasibaigęs.

Generuokite iš naujo iš atšaukimo duomenų bazės, ne nuo nulio

Naujas sąrašas turi ateiti iš dabartinės CA atšaukimo duomenų bazės per patvirtintą pasirašymo procesą. Tuščio sąrašo generavimas arba generavimas iš senos indekso atsarginės kopijos tyliai panaikina kiekvienos tapatybės, pridėtos po tos kopijos, atšaukimą. Tai paverčia prisijungimo sutrikimą saugumo regresija, ir niekas to nepastebi, nes simptomas išnyksta.

Laikykite generavimo žingsnį versijų kontrolėje kartu su kitais CA įrankiais, kad intervalas ir pasirašymo raktas būtų dokumentuoti, o ne atsimenami. Pakanka runbook įrašo, kuriame nurodoma komanda, pasirašantysis ir publikavimo tikslas. Tada bet kas budėdamas gali sugeneruoti iš naujo nespėliodamas, kuris indekso failas yra pagrindinis. Saugokite sąrašo serijos numerį ir kito atnaujinimo laiką kartu su diegimo įrašu.

Diegkite ten, kur žiūri tikrintuvas

Nukopijuokite naują sąrašą į kelią, kurį skaito paslauga, nustatykite nuosavybę ir režimą taip, kad paslaugos paskyra galėtų jį skaityti, o kiti ne, ir įkelkite iš naujo arba paleiskite iš naujo pagal dokumentuotą elgseną. Jei demonas saugo sąrašą paleidimo metu, failo pakeitimas be pakartotinio įkėlimo nepakeis nieko, ką pastebėtų veikiantis procesas. Patvirtinkite laiko žymą, kurią procesas praneša po pakartotinio įkėlimo.

Jei kelių paslaugų klientai tikrinami, diegkite kiekvienoje iš jų. Vieno galinio taško atnaujinimas ir kito palikimas su sena kopija sukuria gedimą, kuris pasirodo tik tiems vartotojams, kurie patenka į antrąjį. Laikykite trumpą tų galinių taškų sąrašą tame pačiame runbook. Po diegimo patikrinkite kiekvieno praneštą sąrašo datą, o ne manykite, kad kopija atkeliavo.

Padarykite kitą terminą matomą, kol jis nepraėjo

Ilgesnis publikavimo intervalas sumažina šio įvykio dažnį nesukurdamas proceso. Pasirinkite intervalą pagal operatoriaus politiką, tada nustatykite įspėjimą apie įdiegto sąrašo kito atnaujinimo lauką su pakankamu rezervu, kad būtų galima iš naujo sugeneruoti ir įdiegti. Įspėkite apie įdiegtą kopiją, o ne apie CA serverį, nes nepavyksta būtent įdiegta kopija.

Po diegimo patikrinkite abi kryptis: leidžiamas vartotojas prisijungia, o žinoma atšaukta tapatybė vis tiek nepavyksta. Antroji patikra yra ta, kuri pagauna nepilną generavimą, ir jai reikia vienos komandos su testiniu profiliu, kurį laikote būtent šiam tikslui.