Nové prihlásenia cez VPN zlyhávajú, hoci certifikáty sú platné: skontrolujte CRL

Certifikáty, ktorým zostávajú mesiace, a prihlásenia, ktoré okamžite zlyhávajú, ukazujú na dva rôzne objekty s dvoma rôznymi hodinami. Server odmieta spojenia, pretože zoznam odvolaných certifikátov, ktorý konzultuje, prekročil vlastný dátum expirácie, nie preto, že by certifikáty používateľov prestali platiť. Obnovenie používateľského certifikátu tomuto zoznamu nijako nepomôže.

Oddelenie týchto dvoch harmonogramov je celou diagnózou a mení to, akú podobu má mať riešenie.

Dve hodiny, z ktorých iba jedny patria certifikátu

Certifikát nesie okno platnosti. Zoznam odvolaných certifikátov nesie vlastné okno a navyše vydavateľa a podpis, pričom overovatelia odmietnu dôverovať zoznamu, ktorého čas ďalšej aktualizácie už uplynul. Keď sa to stane, klient predloží dokonale platný certifikát a server napriek tomu spojenie preruší so správou o zozname. Používatelia túto správu čítajú ako „certifikát expiroval“, čím sa žiadosť o obnovenie posiela na nesprávne miesto.

Tieto dva objekty majú aj rôznych vlastníkov: certifikát pochádza od CA, ktorá ho vydala, zatiaľ čo zoznam generuje podľa harmonogramu ten, kto túto CA prevádzkuje. Používateľ ho nemôže obnoviť a opätovné vydanie certifikátov ho nemôže predĺžiť.

Prečítajte si zoznam, ktorý služba skutočne načítava

Začnite od bežiacej konfigurácie, nie od súboru, ktorý očakávate. Cesta crl-verify môže byť absolútna, relatívna k profilu alebo to môže byť kópia zapečená do obrazu a overovateľ číta práve túto kópiu. Preskúmajte ju priamo na mieste pomocou openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate a porovnajte dátumy s hodinami servera.

Potom overte, že tento súbor je naozaj ten používaný: skontrolujte jeho podpis pomocou openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, ktorý hlási výsledok overenia namiesto tichého vypísania polí. Zoznam podpísaný inou CA alebo zastaraná kópia ponechaná v druhom adresári zlyhá presne ako expirovaný.

Regenerujte z databázy odvolaní, nie od nuly

Nový zoznam musí pochádzať z aktuálnej databázy odvolaní CA, a to schváleným procesom podpisovania. Vygenerovanie prázdneho zoznamu alebo regenerácia zo starej zálohy indexu potichu zruší odvolanie každej identity pridanej od času tejto zálohy. Tým sa výpadok prihlásenia zmení na bezpečnostnú regresiu a nikto si to nevšimne, pretože príznak zmizne.

Krok generovania udržujte vo verzovacom systéme spolu so zvyškom nástrojov CA, aby bol interval a podpisový kľúč zdokumentovaný, a nie zapamätaný. Stačí záznam v prevádzkovej príručke, ktorý uvádza príkaz, podpisujúceho a cieľ publikovania. Ktokoľvek v pohotovosti potom môže zoznam regenerovať bez hádania, ktorý indexový súbor je autoritatívny. Sériové číslo zoznamu a čas ďalšej aktualizácie uložte spolu so záznamom o nasadení.

Nasaďte tam, kde overovateľ hľadá

Skopírujte nový zoznam na cestu, ktorú služba číta, nastavte vlastníctvo a režim tak, aby ho servisný účet mohol čítať, ale ostatní nie, a podľa zdokumentovaného správania ho znova načítajte alebo reštartujte. Ak démon zoznam pri štarte ukladá do vyrovnávacej pamäte, výmena súboru bez opätovného načítania nezmení nič, čo bežiaci proces zaznamená. Potvrďte časovú značku, ktorú proces po opätovnom načítaní hlási.

Ak klientov overuje viacero služieb, nasaďte zoznam na každú z nich. Aktualizácia jedného koncového bodu a ponechanie starého zoznamu na druhom spôsobí zlyhanie, ktoré sa prejaví len používateľom pristávajúcim na druhom z nich. Krátky zoznam týchto koncových bodov udržujte v tej istej prevádzkovej príručke. Po zavedení skontrolujte dátum zoznamu hlásený každým z nich, namiesto toho, aby ste predpokladali, že kópia dorazila.

Urobte ďalší termín viditeľným skôr, ako uplynie

Dlhší interval publikovania znižuje frekvenciu tohto incidentu bez toho, aby vytváral proces. Vyberte interval podľa politiky prevádzkovateľa a potom nastavte upozornenia na pole ďalšej aktualizácie nasadeného zoznamu s dostatočným predstihom na regeneráciu a nasadenie. Upozorňujte na nasadenú kópiu, nie na hostiteľa CA, pretože zlyháva práve nasadená kópia.

Po nasadení overte oba smery: povolený používateľ sa pripojí a známa odvolaná identita stále zlyhá. Druhá kontrola zachytáva neúplnú regeneráciu a vyžaduje jeden príkaz proti testovaciemu profilu, ktorý si presne na tento účel ponechávate.