Återkallat VPN-certifikat ansluter fortfarande? Kontrollera CRL-tillämpning

Du återkallade certifikatet, skapade en ny lista, och den gamla profilen får fortfarande upp en tunnel. Inget är fel på själva återkallandet: en CRL är ett signerat uttalande om att ett serienummer inte längre är giltigt, och den ändrar åtkomst först när komponenten som avslutar TLS läser in den, för rätt utfärdare, innan den fattar acceptbeslutet. Det sista är där de flesta av dessa fall finns, och därför är återkallande och avvisande två olika fakta.

Arbeta igenom de fem kontrollerna nedan i ordning, och stanna vid den första som inte håller, eftersom varje senare kontroll förutsätter att de tidigare är sanna.

Kontrollera vilken komponent som fattar acceptbeslutet

Namnge processen som validerar klientcertifikatet, för bara den processen kan upprätthålla en lista. På en OpenVPN-server är det daemonen själv, konfigurerad med crl-verify. På ocserv är det raden crl i ocserv.conf. På strongSwan är indata de inlästa CRL:erna tillsammans med strictcrlpolicy. En TLS-avslutande proxy eller apparat framför VPN:en kan också vara den egentliga verifieraren, och om den är det ser daemonen bakom den aldrig klientcertifikatet.

WireGuard hör till en annan kategori. Det har inga certifikat och ingen återkallningslista; en peer släpps in via sin publika nyckel i konfigurationen, så att avsluta åtkomst betyder att ta bort den nyckeln. Om du letar efter en CRL i en distribution med bara WireGuard finns inte den mekanismen.

Se även upp för fällan på klientsidan. En klient som vägrar ansluta eftersom den inte gillar servercertifikatet upprätthåller serverns kedja och återkallar inte sin egen behörighet. Ett användarcertifikat återkallas bara där det användarcertifikatet valideras, och det är nästan alltid serversidan.

Kontrollera vilken utfärdare listan signerades för

En CRL gäller för en utfärdande CA. Med en root och en intermediate kommer lövcertifikaten från intermediate-CA:n, så listan som spelar roll är intermediate-CA:ns CRL; rootens lista säger inget om de löven. En verifierare som pekar på fel fil tolkar den glatt, hittar ingen matchande post och accepterar allt.

Bekräfta parkopplingen innan du rör daemonen. Utfärdaren på certifikatet måste matcha listans subject:

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

När båda kommer från samma CA är serienumret som tryckts för certifikatet det värde som måste stå i listan. Om de inte stämmer överens håller du i fel CRL eller fel kopia av den.

Giltigheten hör till samma kontroll. Ett nextUpdate i det förflutna gör listan inaktuell, och en verifierare som failar stängt avvisar då varje klient i stället för bara den återkallade.

Kontrollera att serienumret finns i kopian som daemonen läste in

Återkallande skriver en post i CA-databasen, och regenerering skriver en ny fil. Ingen av åtgärderna når en körande daemon som läste in den gamla kopian vid start. Dumpa listan och leta efter serienumret:

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

Kontrollera sedan hur din implementation tar upp filen. OpenVPN läser en sökväg som getts till crl-verify en gång vid start, så en ny lista kräver en omstart eller en omstartssignal; samma alternativ riktat mot en katalog läses om för varje anslutning, och det är därför katalogläget finns. strongSwan måste läsa om sina credentials, till exempel med swanctl --load-creds. Att filen på disken är korrekt och att verifieraren använder den är två olika fakta.

Kontrollera policyn för en saknad eller utgången lista

Det här är beslutet som många distributioner aldrig fattar uttryckligen, och det avgör om återkallande skyddar dig eller låser ute alla. Fail-closed innebär att ingen användbar återkallningsinformation ger ett avvisande; fail-open innebär att verifieraren fortsätter utan den. strongSwan exponerar valet som strictcrlpolicy. OpenVPN med crl-verify vägrar starta på en fil som den inte kan läsa eller tolka, och en utgången lista visar sig som ett TLS-verifieringsfel om en utgången CRL i stället för som ett tyst accepterande.

Vilken riktning du än väljer betyder automatiseringen mer än valet: ett jobb som regenererar CRL:en före nextUpdate, och en varning när den utplacerade kopian blir äldre, hindrar båda policyerna från att bli en incident. Onlinekontroll med OCSP flyttar färskheten till en responder, men samma regel gäller, eftersom en verifierare som inte är konfigurerad att kontrollera svaret inte ändrar något.

Kontrollera den aktiva sessionen och sedan kopiorna av nyckeln

Återkallande utvärderas under certifikatvalideringen, som sker vid anslutning och vid omförhandling. En etablerad session fortsätter tills den omförhandlar, och OpenVPN:s standard är en gång i timmen med reneg-sec 3600. Om personen måste bort från nätet nu, avsluta sessionen samtidigt som du publicerar listan, och bekräfta sedan att återanslutningen avvisas.

Skilj behörigheten från dess kopior. Att radera en profil på en laptop hindrar inte en annan kopia av samma privata nyckel från att autentisera; återkallandet är det som gör varje kopia oanvändbar, och först när de tidigare kontrollerna håller. Ge en ersättningsenhet ett eget certifikat så att den ena kan återkallas utan att röra den andra.

Innan du kallar det klart: den validerande komponenten är identifierad, listans utfärdare matchar lövets utfärdare, det återkallade serienumret finns i kopian som daemonen faktiskt läste in, policyn för saknade eller utgångna listor är medveten och övervakad, och den aktiva sessionen avslutades i stället för att avvaktas. Formaten bakom allt detta anges i RFC 5280.