Fornying av OpenVPN-sertifikater: lever sertifikatet, ikke timeren

To fornyelsesdesign ser identiske ut i en designgjennomgang og oppfører seg helt ulikt i januar. Det første kjører en timer, utsteder sertifikater på nytt og slipper filer i en delt mappe. Det andre behandler fornyelse som et leveringsproblem: hvem som spør, hva som beviser berettigelse, hvordan materialet når enheten og hva som får klienten til å bruke det. Bare det andre overlever en frakoblet laptop, en utfaset enhet og en levering som feilet i stillhet.

Sammenlign de to designene der de faktisk er forskjellige

Timerdesignet optimaliserer serversiden. En planlagt oppgave kaller på CA-en, et nytt sertifikat dukker opp, og operatøren anser jobben som gjort. Alt som skjer etter utstedelsen er noen andres problem, helt til en enhet ikke får koblet til og utløpsdatoen forklarer hvorfor.

Arbeidsflytdesignet optimaliserer den siste milen. Det forutsetter at utstedelse er ett ledd i en kjede, og at hvert senere trinn kan feile uavhengig. Det koster mer å bygge og mye mindre å drifte, fordi feilene vises som sporede tilstander i stedet for som utløpte klienter.

En nyttig måte å holde forskjellen i sikte på er rekkefølgen hvert design må navngi eksplisitt.

detect window -> authenticate request -> authorize -> issue
-> deliver and stage -> activate -> verify fresh auth -> retire old material

Finn vinduet fra sertifikatet selv

Les gyldigheten fra sertifikatet klienten faktisk legger fram, ikke fra datoen som er bygd inn i et kopiert filnavn. Filnavn driver, og en fil som sier 2026 kan inneholde et bevis som utløper i mars.

La det være slakk i vinduet for de trege tilfellene: enheter som er frakoblet i ukevis, godkjenninger som krever en person, og leveringsveier som feiler én gang før de virker. En timer som rapporterer suksess beviser bare at timeren kjørte, ikke mer.

Autoriser forespørselen før noe utstedes

Et eksisterende sertifikat kan være del av en legitim fornyelsesmekanisme, men subjektteksten er ikke en autorisasjonsbeslutning. Spørsmålet som må besvares er om denne kontoen og denne enheten fortsatt har rett til en identitet i flåten, og svaret ligger i aktivaregistrene dine, ikke i sertifikatet.

En utfaset laptop hvis planlagte oppgave fortsatt kjører, bør ikke få en ny rettighet. RFC 7030 er verdt å lese her fordi det skiller autentisert nyregistrering fra serverside-autorisasjon og policy; det er en modell å låne, ikke en påstand om at OpenVPN eller EasyRSA leverer den protokollen.

Levering, klargjøring og aktivering som separate trinn

Utstedelse bevarer identitet, formål og utstedelsesforhold, og en erstatning generert med et nytt nøkkelpar er ubrukelig med mindre den matchende nøkkelen reiser med den. Lever paret over en kanal med et tilgangskontroll-design bak, fordi en ugjettelig URL er tilsløring og ikke kontroll.

Klargjøring er der mesteparten av automatiseringen brytes i stillhet. En importert profil kan ligge ett sted mens en administrator oppdaterer en fil et annet sted, og klienten fortsetter å legge fram det gamle sertifikatet til noen merker det. Skriv ned stien klienten leser, kontoen som har lov til å skrive i den, og hendelsen som utløser en ny innlasting. Bekreft deretter at erstatningen er filen som faktisk brukes, og ikke en kopi som kom ved siden av.

Verifisering betyr en fersk autentisering med det nye materialet og en sjekk av applikasjonen brukeren trenger. En tunnel som allerede er etablert kan fortsatt gjenspeile det forrige beviset, så en åpen forbindelse er ikke bevis på en vellykket fornyelse.

Design gjenopprettingen av det tapte vinduet først

Når en laptop bare når registreringstjenesten via VPN-en, skaper utløpet en løkke: enheten trenger et sertifikat for å komme inn i tunnelen og tunnelen for å hente sertifikatet. Bestem utenbandsordningen før den første planlagte oppgaven sendes ut, enten det er et separat autentisert registreringsendepunkt eller nyregistrering med administratorhjelp.

Uansett hva du velger, må det verifisere den som ber og den gjeldende rettigheten. Å konfigurere serveren til å godta utløpte sertifikater fra hvem som helst som spør er ikke en gjenopprettingsvei, det er en permanent svekkelse av kontrollen du forsvarte med resten av designet.

Til slutt, hold fornyelse og kompromittering i separate prosedyrer. En lekket nøkkel krever tilbakekalling og en respons på aktive sesjoner, og å forlenge utløpsdatoen inneholder ingenting av det. Ta med en frakoblet enhet, en mislykket levering og en utfaset enhet i akseptansetesten, og tidsplanen er klar til å aktiveres.