Odvolaný certifikát VPN se stále připojuje? Zkontroluj vynucení CRL
Odvolané certifikáty se stále připojují, když se CRL nikdy nedostane k verifikátoru. Zkontroluj v tomto pořadí vydavatele, načtené sériové číslo, chování při opětovném načtení a aktivní relace.
Odvolal jsi certifikát, vygeneroval nový seznam, a starý profil přesto sestaví tunel. Samotné odvolání není rozbité: CRL je podepsané prohlášení, že sériové číslo už není platné, a mění přístup jen tehdy, když ho komponenta ukončující TLS načte, pro správného vydavatele, než učiní rozhodnutí o přijetí. Právě tam leží většina těchto případů, a proto jsou odvolání a odmítnutí dva různé fakty.
Projdi pět níže uvedených kontrol v pořadí a zastav se u první, která neplatí, protože každá další předpokládá, že předchozí jsou pravdivé.
Zkontroluj, která komponenta rozhoduje o přijetí
Pojmenuj proces, který validuje klientský certifikát, protože jen ten proces může vynutit seznam. Na serveru OpenVPN je to sám démon, nakonfigurovaný s crl-verify. V ocserv je to řádek crl v ocserv.conf. V strongSwan jsou vstupy načtené CRL spolu s strictcrlpolicy. Proxy nebo zařízení ukončující TLS před VPN může být skutečný verifikátor, a pokud ano, démon za ním klientský certifikát nikdy nevidí.
WireGuard patří do jiné kategorie. Nemá certifikáty ani seznam odvolání; peer je přijat na základě svého veřejného klíče v konfiguraci, takže ukončení přístupu znamená odstranění toho klíče. Pokud hledáš CRL v nasazení jen s WireGuardem, ten mechanismus tam není.
Dávej pozor i na past na straně klienta. Klient, který odmítá připojení, protože mu vadí certifikát serveru, vynucuje řetězec serveru, neodvolává vlastní pověření. Uživatelský certifikát se odvolává jen tam, kde se tento uživatelský certifikát validuje, a to je téměř vždy strana serveru.
Zkontroluj, pro jakého vydavatele byl seznam podepsán
CRL je omezena na jedno vydávající CA. S kořenem a prostředním certifikáty listů pocházejí z prostředního, takže seznam, na kterém záleží, je CRL prostředního; seznam kořene o těchto listech nic neříká. Verifikátor nasměrovaný na špatný soubor ho vesele naparsuje, nenajde žádnou odpovídající položku a přijme vše.
Potvrď spárování, než se dotkneš démona. Vydavatel na certifikátu musí odpovídat subjectu seznamu:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateKdyž oba pocházejí ze stejného CA, sériové číslo vytištěné pro certifikát je hodnota, která se musí objevit v seznamu. Pokud se neshodují, držíš špatnou CRL nebo její špatnou kopii.
Platnost patří ke stejné kontrole. nextUpdate v minulosti činí seznam zastaralým, a verifikátor, který selhává zavřeně, pak odmítne každého klienta místo jen odvolaného.
Zkontroluj, že sériové číslo je v kopii, kterou démon načetl
Odvolání zapisuje položku do databáze CA a opětovné vygenerování zapisuje nový soubor. Ani jedna akce se nedostane k běžícímu démonu, který při startu načetl starou kopii. Vypiš seznam a hledej sériové číslo:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlPoté zkontroluj, jak tvoje implementace soubor přebírá. OpenVPN čte cestu předanou crl-verify jednou při startu, takže nový seznam vyžaduje restart nebo signál restartu; stejná volba namířená na adresář se znovu načítá při každém připojení, a proto existuje adresářový režim. strongSwan musí znovu načíst svá pověření, například pomocí swanctl --load-creds. To, že je soubor na disku správný, a to, že ho verifikátor používá, jsou dva různé fakty.
Zkontroluj politiku pro chybějící nebo prošlý seznam
Toto je rozhodnutí, které mnoho nasazení nikdy neučiní výslovně, a určuje, zda tě odvolání chrání, nebo všechny uzamkne venku. Fail-closed znamená, že žádná použitelná informace o odvolání nevede k odmítnutí; fail-open znamená, že verifikátor pokračuje bez ní. strongSwan vystavuje volbu jako strictcrlpolicy. OpenVPN s crl-verify odmítá nastartovat na souboru, který nedokáže přečíst nebo naparsovat, a prošlý seznam se projeví jako chyba ověření TLS týkající se prošlé CRL, nikoli jako tiché přijetí.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
Ať zvolíš kterýkoli směr, automatizace je důležitější než volba: úloha, která regeneruje CRL před nextUpdate, a upozornění, když nasazená kopie zestárne, brání oběma politikám stát se incidentem. Online kontrola přes OCSP přesouvá čerstvost na respondér, ale platí stejné pravidlo, protože verifikátor nenastavený ke kontrole odpovědi nic nemění.
Zkontroluj aktivní relaci, pak kopie klíče
Odvolání se vyhodnocuje během validace certifikátu, která probíhá při připojení a při renegociaci. Navázaná relace běží dál, dokud nevyjedná znovu, a výchozí hodnota OpenVPN je jednou za hodinu s reneg-sec 3600. Pokud musí osoba ztratit přístup k síti hned, ukonči relaci vedle zveřejnění seznamu, a potom potvrď, že opětovné připojení je odmítnuto.
Odděl pověření od jeho kopií. Smazání profilu na jednom notebooku nezabrání jiné kopii stejného soukromého klíče v autentizaci; odvolání je to, co učiní každou kopii nepoužitelnou, a jen když předchozí kontroly platí. Dej náhradnímu zařízení vlastní certifikát, aby šlo jedno odvolat bez zásahu do druhého.
Než to označíš za hotové: validační komponenta je určena, vydavatel seznamu odpovídá vydavateli listu, odvolané sériové číslo je v kopii, kterou démon skutečně načetl, politika pro chybějící nebo prošlé seznamy je záměrná a monitorovaná, a aktivní relace byla ukončena, místo aby se na ni čekalo. Formáty, které za tím vším stojí, určuje RFC 5280.