Nye VPN-innloggingar feilar medan sertifikata er gyldige: sjekk CRL-en

Sertifikat med månader att og innloggingar som feilar med ein gong peikar på to ulike objekt med to ulike klokker. Serveren avviser tilkoplingar fordi lista over tilbakekalla sertifikat som han rådfører seg med har passert sin eigen utløpsdato, ikkje fordi sertifikata til brukarane er blitt utdaterte. Fornying av eit brukarsertifikat gjer ingenting for den lista.

Å skilje dei to tidsplanane er heile diagnosen, og det endrar kva rettinga må vere.

To klokker, og berre éi av dei er sertifikatet

Eit sertifikat ber eit gyldigheitsvindauge. Ei sertifikatsperreliste ber sitt eige vindauge, i tillegg til ein utferdar og ein signatur, og verifikatorar nektar å stole på ei liste der tidspunktet for neste oppdatering er passert. Når det skjer, legg klienten fram eit fullstendig gyldig sertifikat, og serveren bryt likevel tilkoplinga med ei melding om lista. Brukarar les den meldinga som 'sertifikatet er utløpt', noko som sender fornyingsforespurnaden til feil stad.

Dei to objekta har også ulike eigarar: sertifikatet kjem frå CA-en som gav det ut, medan lista blir generert etter ein tidsplan av den som driv den CA-en. Ein brukar kan ikkje oppdatere henne, og utgiving av nye sertifikat kan ikkje forlenge henne.

Les lista tenesta faktisk lastar inn

Start med den køyrande konfigurasjonen i staden for fila du ventar. Banen til crl-verify kan vere absolutt, relativ til profilen eller ein kopi baka inn i eit image, og verifikatoren les den kopien. Undersøk henne på staden med openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate og samanlikn datoane med klokka til serveren.

Stadfest deretter at fila verkeleg er den som blir brukt: kontroller signaturen med openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, som rapporterer eit verifikasjonsresultat i staden for å skrive ut felt i det stille. Ei liste signert av ein annan CA, eller ein utdatert kopi som er att i ei anna mappe, feilar nøyaktig som ei utløpt.

Generer på nytt frå sperredatabasen, ikkje frå botnen

Den nye lista må kome frå den gjeldande sperredatabasen til CA-en, gjennom den godkjende signeringsprosessen. Å generere ei tom liste, eller generere på nytt frå ein gammal sikkerheitskopi av indeksen, opphevar i det stille sperringa av kvar identitet som er lagd til sidan den sikkerheitskopien. Det gjer eit innloggingsavbrot om til ein sikkerheitsregresjon, og ingen merkar det fordi symptomet forsvinn.

Hald genereringstrinnet under versjonskontroll saman med resten av CA-verktøya, slik at intervallet og signeringsnøkkelen er dokumentert i staden for hugsa. Ein runbook-oppføring som nemner kommandoen, underteiknaren og publiseringsmålet er nok. Då kan kven som helst på vakt generere på nytt utan å gjette kva indeksfil som er autoritativ. Lagre serienummeret og tidspunktet for neste oppdatering saman med distribusjonsposten.

Distribuer der verifikatoren ser

Kopier den nye lista til banen tenesta les, set eigarskap og modus slik at tenestekontoen kan lese henne men andre ikkje, og last inn på nytt eller start på nytt etter den dokumenterte åtferda. Viss daemonen cachar lista ved oppstart, endrar det å byte ut fila utan å laste inn på nytt ingenting som den køyrande prosessen vil merke. Stadfest tidsstempelet prosessen rapporterer etter innlastinga.

Viss fleire tenester verifiserer klientar, distribuer til kvar av dei. Å oppdatere eitt endepunkt og la eit anna ligge med den gamle kopien gir ein feil som berre syner seg for brukarane som landar på det andre. Hald ei kort liste over desse endepunkta i same runbook. Etter utrullinga, kontroller den rapporterte listedatoen for kvar av dei i staden for å anta at kopien kom fram.

Gjer neste frist synleg før han passerer

Eit lengre publiseringsintervall reduserer frekvensen av denne hendinga utan å skape ein prosess. Vel intervallet frå policyen til operatøren, og varsle deretter på feltet for neste oppdatering i den distribuerte lista med nok førehandsvarsel til å generere på nytt og distribuere. Varsle på den distribuerte kopien, ikkje på CA-verten, fordi den distribuerte kopien er det som feilar.

Etter distribusjonen, verifiser båe retningar: ein tillaten brukar koplar til, og ein kjend sperra identitet feilar framleis. Den andre kontrollen er den som fangar ein ufullstendig regenerering, og han krev éin kommando mot ein testprofil du held nettopp til dette føremålet.