Tilbakekalt VPN-sertifikat kobler fortsatt til? Kontroller CRL-håndheving

Du tilbakekalte sertifikatet, genererte en ny liste, og den gamle profilen får fortsatt opp en tunnel. Ingenting er galt med selve tilbakekallingen: en CRL er en signert erklæring om at et serienummer ikke lenger er gyldig, og den endrer tilgang først når komponenten som avslutter TLS laster den inn, for riktig utsteder, før den tar akseptbeslutningen. Det siste er der de fleste av disse sakene ligger, og derfor er tilbakekalling og avvisning to forskjellige fakta.

Gå gjennom de fem kontrollene nedenfor i rekkefølge, og stopp ved den første som ikke holder, fordi hver senere kontroll forutsetter at de tidligere er sanne.

Kontroller hvilken komponent som tar akseptbeslutningen

Navngi prosessen som validerer klientsertifikatet, fordi bare den prosessen kan håndheve en liste. På en OpenVPN-server er det daemonen selv, konfigurert med crl-verify. På ocserv er det linjen crl i ocserv.conf. På strongSwan er inndataene de innlastede CRL-ene sammen med strictcrlpolicy. En TLS-avsluttende proxy eller apparat foran VPN-en kan også være den egentlige verifikatoren, og hvis den er det, ser daemonen bak den aldri klientsertifikatet.

WireGuard hører til en annen kategori. Det har ingen sertifikater og ingen tilbakekallingsliste; en peer slipper inn via sin offentlige nøkkel i konfigurasjonen, så å avslutte tilgang betyr å fjerne den nøkkelen. Hvis du leter etter en CRL i en utrulling med bare WireGuard, finnes ikke den mekanismen.

Se også opp for fellen på klientsiden. En klient som nekter å koble til fordi den ikke liker serversertifikatet, håndhever serverens kjede og tilbakekaller ikke sin egen legitimasjon. Et brukersertifikat tilbakekalles bare der det brukersertifikatet valideres, og det er nesten alltid serversiden.

Kontroller hvilken utsteder listen ble signert for

En CRL gjelder for én utstedende CA. Med en root og en intermediate kommer bladsertifikatene fra intermediate-CA-en, så listen som betyr noe er intermediate-CA-ens CRL; rootens liste sier ingenting om de bladene. En verifikator som peker på feil fil, parser den gladelig, finner ingen samsvarende oppføring og aksepterer alt.

Bekreft paringen før du rører daemonen. Utstederen på sertifikatet må samsvare med 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 serienummeret som er trykt for sertifikatet den verdien som må stå i listen. Hvis de er uenige, holder du feil CRL eller feil kopi av den.

Gyldighet hører til samme kontroll. En nextUpdate i fortiden gjør listen utdatert, og en verifikator som feiler lukket, avviser da hver klient i stedet for bare den tilbakekalte.

Kontroller at serienummeret står i kopien daemonen lastet inn

Tilbakekalling skriver en oppføring i CA-databasen, og regenerering skriver en ny fil. Ingen av handlingene når en kjørende daemon som lastet inn den gamle kopien ved oppstart. Dump listen og se etter serienummeret:

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

Kontroller deretter hvordan implementasjonen din plukker opp filen. OpenVPN leser en sti gitt til crl-verify én gang ved oppstart, så en ny liste krever en omstart eller et omstartssignal; samme valg rettet mot en katalog leses på nytt for hver tilkobling, og det er grunnen til at katalogmodusen finnes. strongSwan må laste inn legitimasjonen på nytt, for eksempel med swanctl --load-creds. At filen på disk er korrekt, og at verifikatoren bruker den, er to forskjellige fakta.

Kontroller policyen for en manglende eller utløpt liste

Dette er beslutningen mange utrullinger aldri tar eksplisitt, og den avgjør om tilbakekalling beskytter deg eller låser alle ute. Fail-closed betyr at ingen brukbar tilbakekallingsinformasjon gir en avvisning; fail-open betyr at verifikatoren fortsetter uten den. strongSwan eksponerer valget som strictcrlpolicy. OpenVPN med crl-verify nekter å starte på en fil den ikke kan lese eller parse, og en utløpt liste vises som en TLS-verifiseringsfeil om en utløpt CRL i stedet for som en stille aksept.

Uansett hvilken retning du velger, betyr automatiseringen mer enn valget: en jobb som regenererer CRL-en før nextUpdate, og et varsel når den utrullede kopien blir eldre, holder begge policyene fra å bli en hendelse. Onlinekontroll med OCSP flytter ferskheten til en responder, men samme regel gjelder, fordi en verifikator som ikke er konfigurert til å kontrollere svaret, ikke endrer noe.

Kontroller den aktive sesjonen, og deretter kopiene av nøkkelen

Tilbakekalling vurderes under sertifikatvalidering, som skjer ved tilkobling og ved reforhandling. En etablert sesjon fortsetter til den reforhandler, og OpenVPNs standard er én gang i timen med reneg-sec 3600. Hvis personen må av nettet nå, avslutt sesjonen samtidig som listen publiseres, og bekreft deretter at gjenoppkoblingen avvises.

Skill legitimasjonen fra kopiene av den. Sletting av en profil på én bærbar maskin hindrer ikke en annen kopi av samme private nøkkel i å autentisere; tilbakekalling er det som gjør hver kopi ubrukelig, og først når de tidligere kontrollene holder. Gi en erstatningsenhet sitt eget sertifikat, slik at den ene kan tilbakekalles uten å røre den andre.

Før du kaller det ferdig: den validerende komponenten er identifisert, listens utsteder samsvarer med bladets utsteder, det tilbakekalte serienummeret sitter i kopien daemonen faktisk lastet inn, policyen for manglende eller utløpte lister er bevisst og overvåket, og den aktive sesjonen ble avsluttet i stedet for avventet. Formatene bak alt dette er spesifisert i RFC 5280.