Nieuwe VPN-aanmeldingen mislukken terwijl certificaten geldig zijn: controleer de CRL

Certificaten met nog maanden te gaan en aanmeldingen die meteen mislukken, wijzen op twee verschillende objecten met twee verschillende klokken. De server weigert verbindingen omdat de lijst met ingetrokken certificaten die hij raadpleegt zijn eigen vervaldatum is gepasseerd, niet omdat de certificaten van de gebruikers verlopen zijn. Het vernieuwen van een gebruikerscertificaat doet niets voor die lijst.

Het scheiden van de twee schema’s is de hele diagnose, en het verandert wat de oplossing moet zijn.

Twee klokken, en slechts één daarvan is het certificaat

Een certificaat heeft een geldigheidsperiode. Een certificaatintrekkingslijst heeft zijn eigen periode, plus een uitgever en een handtekening, en verificateurs weigeren een lijst te vertrouwen waarvan de tijd van de volgende update is verstreken. Wanneer dat gebeurt, toont de client een volkomen geldig certificaat en gooit de server de verbinding toch weg met een melding over de lijst. Gebruikers lezen die melding als 'het certificaat is verlopen', waardoor de vernieuwingsaanvraag op de verkeerde plek terechtkomt.

De twee objecten hebben ook verschillende eigenaren: het certificaat komt van de CA die het heeft uitgegeven, terwijl de lijst volgens een schema wordt gegenereerd door wie die CA beheert. Een gebruiker kan die niet verversen, en het opnieuw uitgeven van certificaten kan die niet verlengen.

Lees de lijst die de dienst daadwerkelijk laadt

Begin bij de draaiende configuratie in plaats van bij het bestand dat je verwacht. Het pad van crl-verify kan absoluut zijn, relatief ten opzichte van het profiel, of een kopie die in een image is ingebakken, en de verificateur leest die kopie. Inspecteer het ter plaatse met openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate en vergelijk de datums met de klok van de server.

Bevestig daarna dat het bestand echt het bestand is dat in gebruik is: controleer de handtekening met openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, dat een verificatieresultaat meldt in plaats van stil de velden af te drukken. Een lijst die door een andere CA is ondertekend, of een oude kopie die in een tweede map is achtergebleven, faalt precies zoals een verlopen lijst.

Genereer opnieuw uit de intrekkingsdatabase, niet vanaf nul

De nieuwe lijst moet uit de huidige intrekkingsdatabase van de CA komen, via het goedgekeurde ondertekeningsproces. Een lege lijst genereren, of opnieuw genereren uit een oude back-up van de index, maakt stilzwijgend elke identiteit die sinds die back-up is toegevoegd weer geldig. Dat verandert een aanmeldingsstoring in een beveiligingsregressie, en niemand merkt het omdat het symptoom verdwijnt.

Houd de generatiestap in versiebeheer bij de rest van de CA-tooling, zodat het interval en de ondertekeningssleutel gedocumenteerd zijn in plaats van onthouden. Een runbook-regel die het commando, de ondertekenaar en het publicatiedoel noemt, is genoeg. Iedereen die dienst heeft, kan dan opnieuw genereren zonder te raden welk indexbestand gezaghebbend is. Leg het serienummer en de tijd van de volgende update van de lijst vast bij de uitrolregistratie.

Publiceer waar de verificateur kijkt

Kopieer de nieuwe lijst naar het pad dat de dienst leest, stel eigenaar en modus in zodat het serviceaccount die kan lezen maar anderen niet, en herlaad of herstart volgens het gedocumenteerde gedrag. Als de daemon de lijst bij het starten cachet, verandert het vervangen van het bestand zonder herladen niets dat het draaiende proces opmerkt. Controleer de tijdstempel die het proces na de herlaadbeurt meldt.

Als meerdere diensten clients verifiëren, publiceer dan bij elk van hen. Eén endpoint bijwerken en een ander met de oude kopie achterlaten levert een storing op die alleen verschijnt bij de gebruikers die op het tweede terechtkomen. Houd een korte lijst van die endpoints bij in hetzelfde runbook. Controleer na de uitrol de gemelde lijstdatum van elk endpoint in plaats van aan te nemen dat de kopie is aangekomen.

Maak de volgende deadline zichtbaar voordat die verstrijkt

Een langer publicatie-interval verlaagt de frequentie van dit incident zonder een proces te creëren. Kies het interval op basis van het beleid van de beheerder en waarschuw dan op het veld voor de volgende update van de gepubliceerde lijst, met genoeg voorlooptijd om opnieuw te genereren en te publiceren. Waarschuw op de gepubliceerde kopie, niet op de CA-host, want de gepubliceerde kopie is wat faalt.

Controleer na de uitrol beide richtingen: een toegestane gebruiker verbindt, en een bekende ingetrokken identiteit faalt nog steeds. De tweede controle is degene die een onvolledige hergeneratie opvangt, en die kost één commando tegen een testprofiel dat je precies hiervoor aanhoudt.