Tilbakekalla VPN-sertifikat koplar framleis til? Kontroller CRL-handheving

Du kalla tilbake sertifikatet, laga ei ny liste, og den gamle profilen får framleis opp ein tunnel. Ingenting er gale med sjølve tilbakekallinga: ein CRL er ei signert fråsegn om at eit serienummer ikkje lenger er gyldig, og ho endrar tilgang først når komponenten som avsluttar TLS lastar henne inn, for rett utferdar, før han tek akseptavgjerda. Det siste er der dei fleste av desse sakene ligg, og difor er tilbakekalling og avvising to ulike fakta.

Gå gjennom dei fem kontrollane nedanfor i rekkjefølgje, og stopp ved den første som ikkje held, fordi kvar seinare kontroll føreset at dei tidlegare er sanne.

Kontroller kva komponent som tek akseptavgjerda

Namngje prosessen som validerer klientsertifikatet, fordi berre den prosessen kan handheve ei liste. På ein OpenVPN-tenar er det daemonen sjølv, konfigurert med crl-verify. På ocserv er det linja crl i ocserv.conf. På strongSwan er inndataa dei innlasta CRL-ane saman med strictcrlpolicy. Ein TLS-avsluttande proxy eller eining framfor VPN-en kan også vere den eigentlege verifikatoren, og om han er det, ser daemonen bak han aldri klientsertifikatet.

WireGuard høyrer til ein annan kategori. Det har ingen sertifikat og inga tilbakekallingsliste; ein peer slepp inn via sin offentlege nøkkel i konfigurasjonen, så å avslutte tilgang tyder å fjerne den nøkkelen. Om du leitar etter ein CRL i ei utrulling med berre WireGuard, finst ikkje den mekanismen.

Sjå også opp for fella på klientsida. Ein klient som nektar å kople til fordi han ikkje likar tenaren sitt sertifikat, handhevar kjeda til tenaren og tilbakekallar ikkje sin eigen legitimasjon. Eit brukarsertifikat blir berre tilbakekalla der det brukarsertifikatet blir validert, og det er nesten alltid tenarsida.

Kontroller kva utferdar lista vart signert for

Ein CRL gjeld for éin utferdande CA. Med ein rot og ein intermediate kjem bladsertifikata frå intermediate-CA-en, så lista som betyr noko er intermediate-CA-en sin CRL; rota si liste seier ingenting om dei blada. Ein verifikator som peikar på feil fil, parsa henne gladlynt, finn ingen samsvarande oppføring og godtek alt.

Stadfest parkoplinga før du rører daemonen. Utferdaren på sertifikatet må samsvare med subject på lista:

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

Når begge kjem frå same CA, er serienummeret som er trykt for sertifikatet den verdien som må stå i lista. Om dei er usamde, held du feil CRL eller feil kopi av henne.

Gyldigheit høyrer til same kontrollen. Ein nextUpdate i fortida gjer lista utdatert, og ein verifikator som feilar lukka, avviser då kvar klient i staden for berre den tilbakekalla.

Kontroller at serienummeret står i kopien daemonen lasta inn

Tilbakekalling skriv ei oppføring i CA-databasen, og regenerering skriv ei ny fil. Ingen av handlingane når ein køyrande daemon som lasta inn den gamle kopien ved oppstart. Dump lista og leit 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 korleis implementasjonen din plukkar opp fila. OpenVPN les ein sti gitt til crl-verify éin gong ved oppstart, så ei ny liste krev ein omstart eller eit omstartssignal; same val retta mot ein katalog blir lesen på nytt for kvar tilkopling, og det er grunnen til at katalogmodusen finst. strongSwan må laste inn legitimasjonen på nytt, til dømes med swanctl --load-creds. At fila på disk er korrekt, og at verifikatoren brukar henne, er to ulike fakta.

Kontroller policyen for ei manglande eller utløpt liste

Dette er avgjerda mange utrullingar aldri tek eksplisitt, og ho avgjer om tilbakekalling verner deg eller låser alle ute. Fail-closed tyder at inga brukbar tilbakekallingsinformasjon gir ei avvising; fail-open tyder at verifikatoren held fram utan henne. strongSwan syner valet som strictcrlpolicy. OpenVPN med crl-verify nektar å starte på ei fil han ikkje kan lese eller parse, og ei utløpt liste viser seg som ein TLS-verifiseringsfeil om ein utløpt CRL i staden for som ein stille aksept.

Kva retning du enn vel, tyder automatiseringa meir enn valet: ein jobb som regenererer CRL-en før nextUpdate, og eit varsel når den utrulla kopien blir eldre, held begge policyane frå å bli ei hending. Onlinekontroll med OCSP flyttar ferskleiken til ein responder, men same regel gjeld, fordi ein verifikator som ikkje er konfigurert til å kontrollere svaret, ikkje endrar noko.

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

Tilbakekalling blir vurdert under sertifikatvalideringa, som skjer ved tilkopling og ved reforhandling. Ein etablert sesjon held fram til han reforhandlar, og standarden til OpenVPN er éin gong i timen med reneg-sec 3600. Om personen må av nettet no, avslutt sesjonen samstundes som du publiserer lista, og stadfest deretter at gjenoppkoplinga blir avvist.

Skil legitimasjonen frå kopiane av han. Sletting av ein profil på éin berbar maskin hindrar ikkje ein annan kopi av same private nøkkel i å autentisere; tilbakekalling er det som gjer kvar kopi ubrukeleg, og først når dei tidlegare kontrollane held. Gi ei erstatningseining sitt eige sertifikat, slik at den eine kan tilbakekallast utan å røre den andre.

Før du kallar det ferdig: den validerande komponenten er identifisert, utferdaren til lista samsvarar med utferdaren til bladet, det tilbakekalla serienummeret sit i kopien daemonen faktisk lasta inn, policyen for manglande eller utløpte lister er medviten og overvaka, og den aktive sesjonen vart avslutta i staden for avventa. Formata bak alt dette er spesifiserte i RFC 5280.