Uued VPN-sisselogimised nurjuvad, kuigi sertifikaadid on kehtivad: kontrollige CRL-i

Sertifikaadid, millel on veel kuid järel, ja sisselogimised, mis nurjuvad kohe, viitavad kahele erinevale objektile kahe erineva kellaga. Server keeldub ühendustest, sest tühistatud sertifikaatide nimekiri, millega ta konsulteerib, on ületanud omaenda aegumiskuupäeva, mitte sellepärast, et kasutajate sertifikaadid on vananenuks muutunud. Kasutaja sertifikaadi uuendamine ei tee selle nimekirja jaoks midagi.

Kahe ajakava eraldamine on kogu diagnoos ja see muudab seda, milline peab parandus olema.

Kaks kella, ja ainult üks neist on sertifikaat

Sertifikaadil on kehtivusaken. Sertifikaatide tühistamisnimekirjal on oma aken, lisaks väljastaja ja allkiri, ning kontrollijad keelduvad usaldamast nimekirja, mille järgmise uuendamise aeg on möödunud. Kui see juhtub, esitab klient täiesti kehtiva sertifikaadi ja server katkestab ikkagi ühenduse nimekirja puudutava teatega. Kasutajad loevad seda teadet kui 'sertifikaat aegus', mis saadab uuendustaotluse valesse kohta.

Kahel objektil on ka erinevad omanikud: sertifikaat pärineb CA-lt, kes selle väljastas, samas kui nimekirja genereerib ajakava järgi see, kes seda CA-d haldab. Kasutaja ei saa seda värskendada ja sertifikaatide uuesti väljastamine ei saa seda pikendada.

Lugege nimekirja, mille teenus tegelikult laadib

Alustage jooksvast konfiguratsioonist, mitte failist, mida te ootate. crl-verify tee võib olla absoluutne, profiili suhtes suhteline või kujutisse sisse küpsetatud koopia, ja kontrollija loeb just seda koopiat. Vaadake seda kohapeal üle käsuga openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate ja võrrelge kuupäevi serveri kellaga.

Seejärel kinnitage, et fail on tõesti see, mida kasutatakse: kontrollige selle allkirja käsuga openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, mis teatab kontrollitulemuse, selle asemel et välju vaikselt välja printida. Teise CA poolt allkirjastatud nimekiri või teise kataloogi jäetud vananenud koopia nurjub täpselt nagu aegunud nimekiri.

Genereerige tühistamisandmebaasist uuesti, mitte nullist

Uus nimekiri peab pärinema CA praegusest tühistamisandmebaasist heakskiidetud allkirjastamisprotsessi kaudu. Tühja nimekirja genereerimine või indeksi vanast varukoopiast uuesti genereerimine tühistab vaikselt iga identiteedi tühistamise, mis on pärast seda varukoopiat lisatud. See muudab sisselogimiskatkestuse turvaregressiooniks ja keegi ei märka seda, sest sümptom kaob.

Hoidke genereerimisetapp versioonihalduses koos ülejäänud CA tööriistadega, et intervall ja allkirjastamisvõti oleksid dokumenteeritud, mitte meeles peetud. Runbooki kirje, mis nimetab käsu, allkirjastaja ja avaldamise sihtmärgi, on piisav. Siis saab iga valvekorras olev inimene uuesti genereerida ilma arvamata, milline indeksifail on autoriteetne. Salvestage nimekirja seerianumber ja järgmise uuendamise aeg juurutuskirjega.

Juurutage sinna, kuhu kontrollija vaatab

Kopeerige uus nimekiri teele, mida teenus loeb, määrake omanik ja režiim nii, et teenusekonto saab seda lugeda, teised aga mitte, ning laadige uuesti või taaskäivitage vastavalt dokumenteeritud käitumisele. Kui deemon puhverdab nimekirja käivitamisel, ei muuda faili asendamine ilma uuestilaadimiseta midagi, mida töötav protsess märkaks. Kinnitage ajatempel, mille protsess pärast uuestilaadimist teatab.

Kui mitmed teenused kontrollivad kliente, juurutage igas neist. Ühe lõpp-punkti uuendamine ja teise vana koopiaga jätmine tekitab tõrke, mis ilmneb ainult neile kasutajatele, kes satuvad teisele. Hoidke nende lõpp-punktide lühike nimekiri samas runbookis. Pärast juurutamist kontrollige igaühe teatatud nimekirja kuupäeva, selle asemel et eeldada, et koopia kohale jõudis.

Tehke järgmine tähtaeg nähtavaks enne selle möödumist

Pikem avaldamisintervall vähendab selle juhtumi sagedust ilma protsessi loomata. Valige intervall operaatori poliitikast ja seadke seejärel häire juurutatud nimekirja järgmise uuendamise väljale piisava ettemääratud ajaga uuesti genereerimiseks ja juurutamiseks. Häire peab olema juurutatud koopial, mitte CA hostil, sest juurutatud koopia on see, mis nurjub.

Pärast juurutamist kontrollige mõlemas suunas: lubatud kasutaja ühendub ja teadaolev tühistatud identiteet nurjub endiselt. Teine kontroll on see, mis püüab kinni puuduliku uuesti genereerimise, ja see nõuab ühte käsku testprofiili vastu, mida hoiate täpselt selleks otstarbeks.