Tilbagekaldt VPN-certifikat forbinder stadig? Kontrollér håndhævelse af CRL

Du har tilbagekaldt certifikatet, genereret en ny liste, og den gamle profil opretter stadig en tunnel. Der er intet i vejen med selve tilbagekaldelsen: En CRL er en underskrevet erklæring om, at et serienummer ikke længere er gyldigt, og den ændrer først adgang, når komponenten, der afslutter TLS, indlæser den, for den rigtige udsteder, før den træffer acceptbeslutningen. Det sidste er, hvor de fleste af disse sager ligger, og derfor er tilbagekaldelse og afvisning to forskellige fakta.

Gå de fem kontroller nedenfor igennem i rækkefølge, og stop ved den første, der ikke holder, fordi hver senere kontrol forudsætter, at de tidligere er sande.

Kontrollér, hvilken komponent der træffer acceptbeslutningen

Navngiv den proces, der validerer klientcertifikatet, fordi kun den proces kan håndhæve en liste. På en OpenVPN-server er det daemonen selv, konfigureret med crl-verify. På ocserv er det linjen crl i ocserv.conf. På strongSwan er input de indlæste CRL'er sammen med strictcrlpolicy. En TLS-afsluttende proxy eller appliance foran VPN'en kan også være den egentlige verifikator, og hvis den er det, ser daemonen bagved aldrig klientcertifikatet.

WireGuard hører i en anden kategori. Det har ingen certifikater og ingen tilbagekaldelsesliste; en peer optages via sin offentlige nøgle i konfigurationen, så at afslutte adgang betyder at fjerne den nøgle. Hvis du leder efter en CRL i en udrulning med kun WireGuard, findes den mekanisme ikke.

Pas også på fælden på klientsiden. En klient, der nægter at forbinde, fordi den ikke kan lide servercertifikatet, håndhæver serverens kæde og tilbagekalder ikke sin egen legitimation. Et brugercertifikat tilbagekaldes kun der, hvor det brugercertifikat valideres, og det er næsten altid serversiden.

Kontrollér, hvilken udsteder listen er underskrevet for

En CRL er begrænset til én udstedende CA. Med en root og en intermediate kommer bladcertifikaterne fra intermediate-CA'en, så den liste, der betyder noget, er intermediate-CA'ens CRL; rootens liste siger intet om de blade. En verifikator, der peger på den forkerte fil, parser den gladeligt, finder ingen matchende post og accepterer alt.

Bekræft parringen, før du rører daemonen. Udstederen på certifikatet skal matche listens subject:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Når begge kommer fra samme CA, er det serienummer, der er trykt for certifikatet, den værdi, der skal stå på listen. Hvis de er uenige, har du den forkerte CRL eller den forkerte kopi af den.

Gyldighed hører til den samme kontrol. Et nextUpdate i fortiden gør listen forældet, og en verifikator, der fejler lukket, afviser så hver klient i stedet for kun den tilbagekaldte.

Kontrollér, at serienummeret står i den kopi, daemonen indlæste

Tilbagekaldelse skriver en post i CA-databasen, og regenerering skriver en ny fil. Ingen af de to handlinger når en kørende daemon, der indlæste den gamle kopi ved opstart. Dump listen og led efter serienummeret:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Kontrollér derefter, hvordan din implementering samler filen op. OpenVPN læser en sti, der er givet til crl-verify, én gang ved opstart, så en ny liste kræver en genstart eller et genstartssignal; den samme indstilling rettet mod en mappe genlæses for hver forbindelse, og det er grunden til, at mappetilstanden findes. strongSwan skal genindlæse sine credentials, for eksempel med swanctl --load-creds. At filen på disken er korrekt, og at verifikatoren bruger den, er to forskellige fakta.

Kontrollér politikken for en manglende eller udløbet liste

Det er den beslutning, som mange udrulninger aldrig træffer eksplicit, og den afgør, om tilbagekaldelse beskytter dig eller låser alle ude. Fail-closed betyder, at ingen brugbar tilbagekaldelsesinformation fører til en afvisning; fail-open betyder, at verifikatoren fortsætter uden den. strongSwan eksponerer valget som strictcrlpolicy. OpenVPN med crl-verify nægter at starte på en fil, den ikke kan læse eller parse, og en udløbet liste vises som en TLS-verifikationsfejl om en udløbet CRL i stedet for som en tavs accept.

Uanset hvilken retning du vælger, betyder automatiseringen mere end valget: Et job, der regenererer CRL'en før nextUpdate, og en advarsel, når den udrullede kopi bliver ældre, holder begge politikker fra at blive en hændelse. Onlinekontrol med OCSP flytter friskheden til en responder, men den samme regel gælder, fordi en verifikator, der ikke er konfigureret til at kontrollere svaret, ikke ændrer noget.

Kontrollér den aktive session, og derefter kopierne af nøglen

Tilbagekaldelse vurderes under certifikatvalidering, som sker ved forbindelse og ved renegotiering. En etableret session kører videre, indtil den renegotierer, og OpenVPNs standard er én gang i timen med reneg-sec 3600. Hvis personen skal af nettet nu, afslut sessionen samtidig med at listen offentliggøres, og bekræft derefter, at genforbindelsen afvises.

Adskil legitimationen fra dens kopier. Sletning af en profil på én bærbar computer forhindrer ikke en anden kopi af den samme private nøgle i at autentificere; tilbagekaldelse er det, der gør hver kopi ubrugelig, og først når de tidligere kontroller holder. Giv en erstatningsenhed sit eget certifikat, så den ene kan tilbagekaldes uden at røre den anden.

Før du kalder det færdigt: Den validerende komponent er identificeret, listens udsteder matcher bladets udsteder, det tilbagekaldte serienummer sidder i den kopi, daemonen faktisk indlæste, politikken for manglende eller udløbne lister er bevidst og overvåget, og den aktive session blev afsluttet i stedet for afventet. Formaterne bag det hele er specificeret i RFC 5280.