Nová přihlášení k VPN selhávají, i když jsou certifikáty platné: zkontrolujte CRL
Platný klientský certifikát a prošlý seznam odvolaných certifikátů jsou dva různé objekty na dvou různých hodinách. Přečtěte si seznam, který server načítá, a pak ho znovu vygenerujte.
Certifikáty se zbývajícími měsíci a přihlášení, která okamžitě selhávají, ukazují na dva různé objekty se dvěma různými hodinami. Server odmítá připojení, protože seznam odvolaných certifikátů, který kontroluje, překročil vlastní datum expirace, ne protože by certifikáty uživatelů zestárly. Obnovení uživatelského certifikátu pro tento seznam nic neudělá.
Rozdělení obou časových plánů je celá diagnóza a mění podobu nutné opravy.
Dvoje hodiny, a jen jedny z nich jsou certifikát
Certifikát nese okno platnosti. Seznam odvolaných certifikátů nese vlastní okno, navíc vydavatele a podpis, a ověřovatelé odmítají důvěřovat seznamu, jehož čas příští aktualizace už minul. Když se to stane, klient předloží naprosto platný certifikát a server přesto spojení ukončí se zprávou o seznamu. Uživatelé si tuto zprávu vyloží jako 'certifikát vypršel', což pošle žádost o obnovu na špatné místo.
Oba objekty mají také různé vlastníky: certifikát pochází od CA, která ho vydala, zatímco seznam generuje podle plánu ten, kdo danou CA provozuje. Uživatel ho nemůže obnovit a opětovné vydání certifikátů ho nemůže prodloužit.
Přečtěte si seznam, který služba skutečně načítá
Začněte u běžící konfigurace, ne u souboru, který očekáváte. Cesta crl-verify může být absolutní, relativní vůči profilu, nebo kopie zapečená do image, a ověřovatel čte tu kopii. Prohlédněte si ji na místě pomocí openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate a porovnejte data s hodinami serveru.
Potom potvrďte, že soubor je opravdu ten používaný: zkontrolujte jeho podpis pomocí openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, který hlásí výsledek ověření, místo aby tiše vypsal pole. Seznam podepsaný jinou CA nebo zastaralá kopie ponechaná v druhém adresáři selže přesně jako prošlý.
Generujte znovu z databáze odvolání, ne od nuly
Nový seznam musí pocházet z aktuální databáze odvolání CA, a to schváleným procesem podepisování. Vygenerování prázdného seznamu nebo obnovení ze staré zálohy indexu tiše zruší odvolání každé identity přidané po této záloze. Tím se z výpadku přihlášení stane bezpečnostní regrese a nikdo si toho nevšimne, protože symptom zmizí.
Držte krok generování pod verzovací kontrolou spolu se zbytkem nástrojů CA, aby byl interval a podpisový klíč zdokumentován, ne jen pamatován. Záznam v runbooku, který pojmenuje příkaz, podepisujícího a cíl publikace, stačí. Kdokoli ve službě pak může vygenerovat znovu, aniž by hádal, který indexový soubor je směrodatný. Uložte sériové číslo seznamu a čas příští aktualizace spolu se záznamem o nasazení.
Nasaďte tam, kam ověřovatel hledí
Zkopírujte nový seznam na cestu, kterou služba čte, nastavte vlastnictví a režim tak, aby ho servisní účet mohl číst a ostatní ne, a podle zdokumentovaného chování znovu načtěte nebo restartujte. Pokud démon seznam při startu kešuje, nahrazení souboru bez znovunačtení nezmění nic, čeho by si běžící proces všiml. Potvrďte časové razítko, které proces po znovunačtení hlásí.
Pokud klienty ověřuje několik služeb, nasaďte to u každé z nich. Aktualizace jednoho koncového bodu a ponechání jiného se starou kopií vytvoří selhání, které se objeví jen u uživatelů, kteří přistanou na druhém. Veďte krátký seznam těchto koncových bodů ve stejném runbooku. Po nasazení zkontrolujte hlášené datum seznamu u každého z nich, místo abyste předpokládali, že kopie dorazila.
Zviditelněte další termín, než uplyne
Delší interval publikace snižuje četnost tohoto incidentu, aniž by vytvořil proces. Zvolte interval podle politiky provozovatele a pak nastavte výstrahu na pole příští aktualizace nasazeného seznamu s dostatečným předstihem pro opětovné vygenerování a nasazení. Upozorňujte na nasazenou kopii, ne na hostitele CA, protože selhává nasazená kopie.
Po nasazení ověřte oba směry: povolený uživatel se připojí a známá odvolaná identita stále selhává. Druhá kontrola je ta, která zachytí neúplné znovuvygenerování, a vyžaduje jediný příkaz proti testovacímu profilu, který držíte právě pro tento účel.