Nove VPN prijave ne uspijevaju dok su certifikati valjani: provjerite CRL
Valjan klijentski certifikat i istekla lista opoziva dva su različita objekta na dva različita sata. Pročitajte listu koju server učitava, pa je ponovno generirajte.
Certifikati kojima su ostali mjeseci i prijave koje odmah ne uspijevaju upućuju na dva različita objekta s dva različita sata. Server odbija veze jer je lista opozvanih certifikata koju provjerava prešla vlastiti datum isteka, a ne zato što su korisnički certifikati zastarjeli. Obnavljanje korisničkog certifikata ne čini ništa za tu listu.
Razdvajanje dva rasporeda jest cijela dijagnoza i mijenja to kakvo rješenje mora biti.
Dva sata, a samo je jedan od njih certifikat
Certifikat nosi razdoblje valjanosti. Lista opozvanih certifikata nosi vlastito razdoblje, uz izdavatelja i potpis, a provjeravatelji odbijaju vjerovati listi čije je vrijeme sljedećeg ažuriranja prošlo. Kad se to dogodi, klijent predstavlja savršeno valjan certifikat, a server ipak prekida vezu s porukom o listi. Korisnici tu poruku čitaju kao 'certifikat je istekao', što zahtjev za obnovu šalje na pogrešno mjesto.
Dva objekta imaju i različite vlasnike: certifikat dolazi od CA koji ga je izdao, dok listu prema rasporedu generira onaj tko tim CA upravlja. Korisnik je ne može osvježiti, a ponovno izdavanje certifikata ne može je produžiti.
Pročitajte listu koju usluga stvarno učitava
Pođite od konfiguracije koja je u pogonu, a ne od datoteke koju očekujete. Putanja crl-verify može biti apsolutna, relativna prema profilu ili kopija ugrađena u sliku, a provjeravatelj čita tu kopiju. Pregledajte je na mjestu s openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate i usporedite datume sa satom poslužitelja.
Zatim potvrdite da je datoteka doista ona koja se koristi: provjerite njezin potpis s openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, koji prijavljuje rezultat provjere umjesto da tiho ispisuje polja. Lista koju je potpisao drugi CA ili zastarjela kopija ostavljena u drugom direktoriju pada točno kao istekla.
Generirajte ponovno iz baze opoziva, ne od nule
Nova lista mora doći iz trenutačne baze opoziva CA-a, kroz odobreni postupak potpisivanja. Generiranje prazne liste ili ponovno generiranje iz stare sigurnosne kopije indeksa tiho ukida opoziv svakog identiteta dodanog nakon te kopije. To prekida ispad prijave u sigurnosnu regresiju i nitko to ne primijeti jer simptom nestane.
Držite korak generiranja u verzijskoj kontroli uz ostatak CA alata, tako da su interval i ključ za potpisivanje dokumentirani, a ne zapamćeni. Zapis u runbooku koji imenuje naredbu, potpisnika i cilj objave dovoljan je. Tada svatko tko je na dežurstvu može ponovno generirati bez nagađanja koja je datoteka indeksa mjerodavna. Pohranite serijski broj liste i vrijeme sljedećeg ažuriranja uz zapis o implementaciji.
Implementirajte tamo gdje provjeravatelj gleda
Kopirajte novu listu na putanju koju usluga čita, postavite vlasništvo i način tako da je servisni račun može čitati, a drugi ne, pa ponovno učitajte ili restartajte prema dokumentiranom ponašanju. Ako daemon kešira listu pri pokretanju, zamjena datoteke bez ponovnog učitavanja ne mijenja ništa što će proces u pogonu primijetiti. Potvrdite vremensku oznaku koju proces prijavi nakon ponovnog učitavanja.
Ako više usluga provjerava klijente, implementirajte kod svake od njih. Ažuriranje jedne krajnje točke i ostavljanje druge sa starom kopijom stvara kvar koji se pojavljuje samo kod korisnika koji slete na drugu. Držite kratak popis tih krajnjih točaka u istom runbooku. Nakon uvođenja provjerite prijavljeni datum liste za svaku od njih umjesto da pretpostavite da je kopija stigla.
Učinite sljedeći rok vidljivim prije nego što prođe
Dulji interval objave smanjuje učestalost ovog incidenta bez stvaranja procesa. Odaberite interval prema politici operatera, pa postavite uzbunu na polje sljedećeg ažuriranja implementirane liste s dovoljno vremena za ponovno generiranje i implementaciju. Uzbunjujte na implementiranu kopiju, a ne na CA host, jer implementirana kopija je ono što pada.
Nakon implementacije provjerite oba smjera: dopušteni korisnik se povezuje, a poznati opozvani identitet još uvijek pada. Druga provjera je ona koja hvata nepotpuno ponovno generiranje i zahtijeva jednu naredbu prema testnom profilu koji držite upravo u tu svrhu.