Nya VPN-inloggningar misslyckas medan certifikaten är giltiga: kontrollera CRL

Certifikat med månader kvar och inloggningar som misslyckas direkt pekar på två olika objekt med två olika klockor. Servern avvisar anslutningar eftersom listan över återkallade certifikat som den rådfrågar har passerat sitt eget utgångsdatum, inte för att användarnas certifikat har blivit inaktuella. Att förnya ett användarcertifikat gör ingenting för den listan.

Att skilja de två schemana åt är hela diagnosen, och det ändrar vad åtgärden måste vara.

Två klockor, och bara en av dem är certifikatet

Ett certifikat bär ett giltighetsfönster. En lista över återkallade certifikat bär sitt eget fönster, plus en utfärdare och en signatur, och verifierare vägrar lita på en lista vars tid för nästa uppdatering har passerat. När det händer presenterar klienten ett fullt giltigt certifikat och servern bryter ändå anslutningen med ett meddelande om listan. Användare läser det meddelandet som ”certifikatet har gått ut”, vilket skickar förnyelsebegäran till fel plats.

De två objekten har också olika ägare: certifikatet kommer från den CA som utfärdade det, medan listan genereras enligt ett schema av den som driver den CA:n. En användare kan inte uppdatera den, och att utfärda certifikat på nytt kan inte förlänga den.

Läs listan som tjänsten faktiskt läser in

Börja från den körande konfigurationen i stället för från filen du förväntar dig. Sökvägen crl-verify kan vara absolut, relativ till profilen eller en kopia inbakad i en avbildning, och verifieraren läser den kopian. Granska den på plats med openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate och jämför datumen med serverns klocka.

Bekräfta sedan att filen verkligen är den som används: kontrollera dess signatur med openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, som rapporterar ett verifieringsresultat i stället för att tyst skriva ut fält. En lista som signerats av en annan CA, eller en gammal kopia kvar i en andra katalog, misslyckas precis som en utgången.

Generera om från återkallningsdatabasen, inte från grunden

Den nya listan måste komma från CA:ns aktuella återkallningsdatabas, via den godkända signeringsprocessen. Att generera en tom lista, eller att generera om från en gammal säkerhetskopia av indexet, återkallar tyst varje identitet som lagts till sedan den säkerhetskopian. Det förvandlar ett inloggningsavbrott till en säkerhetsregression, och ingen märker det eftersom symptomet försvinner.

Håll genereringssteget i versionskontroll tillsammans med resten av CA-verktygen, så att intervallet och signeringsnyckeln dokumenteras i stället för att kommas ihåg. En post i driftmanualen som anger kommandot, undertecknaren och publiceringsmålet räcker. Vem som helst i beredskap kan då generera om utan att gissa vilken indexfil som är auktoritativ. Spara listans serienummer och tid för nästa uppdatering med distributionsposten.

Distribuera där verifieraren tittar

Kopiera den nya listan till den sökväg som tjänsten läser, ställ in ägarskap och behörighetsläge så att tjänstekontot kan läsa den men andra inte, och läs in den igen eller starta om enligt det dokumenterade beteendet. Om demon cachar listan vid start ändrar en ersatt fil utan omläsning ingenting som den körande processen märker. Bekräfta tidsstämpeln som processen rapporterar efter omläsningen.

Om flera tjänster verifierar klienter, distribuera till var och en av dem. Att uppdatera en slutpunkt och lämna en annan med den gamla kopian ger ett fel som bara syns för de användare som hamnar på den andra. Håll en kort lista över dessa slutpunkter i samma driftmanual. Efter utrullningen, kontrollera varje slutpunkts rapporterade listdatum i stället för att anta att kopian landade.

Gör nästa deadline synlig innan den passerar

Ett längre publiceringsintervall minskar frekvensen av denna incident utan att skapa en process. Välj intervallet utifrån operatörens policy och larma sedan på den distribuerade listans fält för nästa uppdatering med tillräcklig framförhållning för att generera om och distribuera. Larma på den distribuerade kopian, inte på CA-värden, eftersom det är den distribuerade kopian som misslyckas.

Efter distributionen, verifiera båda riktningarna: en tillåten användare ansluter och en känd återkallad identitet misslyckas fortfarande. Den andra kontrollen är den som fångar en ofullständig omgenerering, och den kräver ett enda kommando mot en testprofil som du håller just för detta ändamål.