Nye VPN-logins fejler, mens certifikaterne er gyldige: kontrollér CRL’en

Certifikater med måneder tilbage og logins, der fejler med det samme, peger på to forskellige objekter med to forskellige ure. Serveren afviser forbindelser, fordi listen over spærrede certifikater, som den konsulterer, har passeret sin egen udløbsdato, ikke fordi brugernes certifikater er blevet forældede. Fornyelse af et brugercertifikat gør intet for den liste.

At skelne de to tidsplaner er hele diagnosen, og det ændrer, hvad løsningen skal være.

To ure, og kun det ene er certifikatet

Et certifikat bærer et gyldighedsvindue. En certifikatspærringsliste bærer sit eget vindue plus en udsteder og en signatur, og verifikatorer nægter at stole på en liste, hvis næste opdateringstid er passeret. Når det sker, fremviser klienten et fuldstændig gyldigt certifikat, og serveren afbryder alligevel forbindelsen med en meddelelse om listen. Brugerne læser den meddelelse som 'certifikatet er udløbet', hvilket sender fornyelsesanmodningen det forkerte sted hen.

De to objekter har også forskellige ejere: certifikatet kommer fra den CA, der udstedte det, mens listen genereres efter en tidsplan af den, der driver den CA. En bruger kan ikke forny den, og genudstedelse af certifikater kan ikke forlænge den.

Læs den liste, tjenesten faktisk indlæser

Begynd ved den kørende konfiguration i stedet for ved den fil, du forventer. Stien i crl-verify kan være absolut, relativ til profilen eller en kopi bagt ind i et image, og verifikatoren læser den kopi. Undersøg den på stedet med openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate og sammenlign datoerne med serverens ur.

Bekræft derefter, at filen virkelig er den, der bruges: kontrollér dens signatur med openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, som rapporterer et verifikationsresultat i stedet for lydløst at udskrive felter. En liste signeret af en anden CA eller en forældet kopi efterladt i en anden mappe fejler nøjagtigt som en udløbet.

Genopret fra spærringsdatabasen, ikke fra bunden

Den nye liste skal komme fra CA’ens aktuelle spærringsdatabase gennem den godkendte signeringsproces. At generere en tom liste eller genoprette fra en gammel sikkerhedskopi af indekset ophæver i stilhed spærringen af enhver identitet, der er tilføjet siden den sikkerhedskopi. Det gør et loginudfald til en sikkerhedsregression, og ingen opdager det, fordi symptomet forsvinder.

Hold genereringstrinnet under versionskontrol sammen med resten af CA-værktøjet, så intervallet og signeringsnøglen er dokumenteret i stedet for husket. Et runbook-afsnit, der navngiver kommandoen, underskriveren og publiceringsmålet, er nok. Så kan enhver på vagt genoprette uden at gætte, hvilken indeksfil der er autoritativ. Gem listens serienummer og næste opdateringstid sammen med udrulningsregistreringen.

Udrul der, hvor verifikatoren kigger

Kopiér den nye liste til den sti, tjenesten læser, sæt ejerskab og tilstand, så tjenestekontoen kan læse den, men andre ikke, og genindlæs eller genstart efter den dokumenterede adfærd. Hvis dæmonen cacher listen ved opstart, ændrer erstatning af filen uden genindlæsning intet, som den kørende proces vil bemærke. Bekræft det tidsstempel, processen rapporterer efter genindlæsningen.

Hvis flere tjenester verificerer klienter, skal du udrulle til hver af dem. Opdatering af ét endepunkt og efterladelse af et andet med den gamle kopi giver en fejl, der kun vises for de brugere, der lander på det andet. Hold en kort liste over disse endepunkter i samme runbook. Efter udrulningen skal du kontrollere hvert endepunkts rapporterede listedato i stedet for at antage, at kopien er landet.

Gør den næste frist synlig, før den passerer

Et længere publiceringsinterval sænker hyppigheden af denne hændelse uden at skabe en proces. Vælg intervallet ud fra operatørens politik, og alarmér derefter på feltet for næste opdatering i den udrullede liste med nok forspring til at genoprette og udrulle. Alarmér på den udrullede kopi, ikke på CA-værten, fordi den udrullede kopi er det, der fejler.

Efter udrulningen skal du verificere begge retninger: en tilladt bruger forbinder, og en kendt spærret identitet fejler stadig. Den anden kontrol er den, der fanger en ufuldstændig genoprettelse, og den kræver én kommando mod en testprofil, som du holder netop til dette formål.