Nye VPN-innlogginger feiler mens sertifikatene er gyldige: sjekk CRL-en

Sertifikater med måneder igjen og innlogginger som feiler umiddelbart peker på to forskjellige objekter med to forskjellige klokker. Serveren avviser tilkoblinger fordi listen over tilbakekalte sertifikater som den konsulterer har passert sin egen utløpsdato, ikke fordi brukernes sertifikater er blitt utdaterte. Fornyelse av et brukersertifikat gjør ingenting for den listen.

Å skille de to tidsplanene er hele diagnosen, og det endrer hva rettelsen må være.

To klokker, og bare én av dem er sertifikatet

Et sertifikat bærer et gyldighetsvindu. En sertifikatssperreliste bærer sitt eget vindu, i tillegg til en utsteder og en signatur, og verifikatorer nekter å stole på en liste der tidspunktet for neste oppdatering er passert. Når det skjer, presenterer klienten et fullstendig gyldig sertifikat, og serveren bryter likevel tilkoblingen med en melding om listen. Brukere leser den meldingen som 'sertifikatet er utløpt', noe som sender fornyelsesforespørselen til feil sted.

De to objektene har også forskjellige eiere: sertifikatet kommer fra CA-en som utstedte det, mens listen genereres etter en tidsplan av den som driver den CA-en. En bruker kan ikke oppdatere den, og utstedelse av nye sertifikater kan ikke forlenge den.

Les listen tjenesten faktisk laster inn

Start med den kjørende konfigurasjonen i stedet for filen du forventer. Banen til crl-verify kan være absolutt, relativ til profilen eller en kopi bakt inn i et image, og verifikatoren leser den kopien. Undersøk den på stedet med openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate og sammenlign datoene med serverens klokke.

Bekreft deretter at filen virkelig er den som brukes: kontroller signaturen med openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, som rapporterer et verifikasjonsresultat i stedet for å skrive ut felter i det stille. En liste signert av en annen CA, eller en utdatert kopi som er igjen i en annen mappe, feiler nøyaktig som en utløpt.

Generer på nytt fra sperredatabasen, ikke fra bunnen

Den nye listen må komme fra CA-ens gjeldende sperredatabase, gjennom den godkjente signeringsprosessen. Å generere en tom liste, eller generere på nytt fra en gammel sikkerhetskopi av indeksen, opphever i stillhet sperringen av hver identitet som er lagt til siden den sikkerhetskopien. Det gjør et innloggingsavbrudd om til en sikkerhetsregresjon, og ingen merker det fordi symptomet forsvinner.

Hold genereringstrinnet under versjonskontroll sammen med resten av CA-verktøyet, slik at intervallet og signeringsnøkkelen er dokumentert i stedet for husket. En runbook-oppføring som navngir kommandoen, undertegneren og publiseringsmålet er nok. Da kan enhver på vakt generere på nytt uten å gjette hvilken indeksfil som er autoritativ. Lagre serienummeret og tidspunktet for neste oppdatering sammen med distribusjonsposten.

Distribuer der verifikatoren ser

Kopier den nye listen til banen tjenesten leser, sett eierskap og modus slik at tjenestekontoen kan lese den men andre ikke, og last inn på nytt eller start på nytt etter den dokumenterte oppførselen. Hvis daemonen cacher listen ved oppstart, endrer det å erstatte filen uten å laste inn på nytt ingenting som den kjørende prosessen vil merke. Bekreft tidsstempelet prosessen rapporterer etter innlastingen.

Hvis flere tjenester verifiserer klienter, distribuer til hver av dem. Å oppdatere ett endepunkt og la et annet ligge med den gamle kopien gir en feil som bare vises for brukerne som lander på det andre. Hold en kort liste over disse endepunktene i samme runbook. Etter utrullingen, kontroller den rapporterte listedatoen for hver av dem i stedet for å anta at kopien kom frem.

Gjør neste frist synlig før den passerer

Et lengre publiseringsintervall reduserer frekvensen av denne hendelsen uten å skape en prosess. Velg intervallet fra operatørens policy, og varsle deretter på feltet for neste oppdatering i den distribuerte listen med nok forhåndsvarsel til å generere på nytt og distribuere. Varsle på den distribuerte kopien, ikke på CA-verten, fordi den distribuerte kopien er det som feiler.

Etter distribusjonen, verifiser begge retninger: en tillatt bruker kobler til, og en kjent sperret identitet feiler fortsatt. Den andre kontrollen er den som fanger en ufullstendig regenerering, og den krever én kommando mot en testprofil du holder nettopp til dette formålet.