OpenVPN-certificaten verlengen: lever het certificaat, niet de timer

Twee verlengingsontwerpen lijken identiek in een ontwerpreview en gedragen zich in januari totaal verschillend. Het eerste laat een timer lopen, geeft certificaten opnieuw uit en dumpt bestanden in een gedeelde map. Het tweede behandelt verlenging als een leveringsprobleem: wie vraagt, wat bewijst geschiktheid, hoe bereikt het materiaal het apparaat en wat zorgt ervoor dat de client het gebruikt. Alleen het tweede overleeft een offline laptop, een uitgerangeerd asset en een levering die stil mislukte.

Vergelijk de twee ontwerpen waar ze echt verschillen

Het timerontwerp optimaliseert de serverkant. Een geplande taak roept de CA aan, er verschijnt een nieuw certificaat en de operator beschouwt het werk als gedaan. Alles wat na de uitgifte gebeurt, is andermans probleem, tot een apparaat geen verbinding kan maken en de vervaldatum uitlegt waarom.

Het workflowontwerp optimaliseert de laatste mijl. Het gaat ervan uit dat uitgifte één schakel in een keten is en dat elke latere stap onafhankelijk kan mislukken. Dat kost meer om te bouwen en veel minder om te beheren, omdat de fouten als gevolgde toestanden verschijnen in plaats van als verlopen clients.

Een nuttige manier om het verschil in het oog te houden is de volgorde die elk ontwerp expliciet moet benoemen.

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

Detecteer het venster uit het certificaat zelf

Lees de geldigheid uit het certificaat dat de client daadwerkelijk presenteert, niet uit de datum die in een gekopieerde bestandsnaam is ingebed. Bestandsnamen schuiven op, en een bestand waarop 2026 staat kan een bewijs bevatten dat in maart verloopt.

Laat speling in het venster voor de langzame gevallen: apparaten die weken offline zijn, goedkeuringen die een mens nodig hebben en leveringspaden die één keer falen voordat ze werken. Een timer die succes meldt, bewijst alleen dat de timer liep, niets meer.

Autoriseer de aanvraag voordat er iets wordt uitgegeven

Een bestaand certificaat kan deel uitmaken van een legitiem verlengingsmechanisme, maar de subjecttekst is geen autorisatiebeslissing. De vraag die beantwoord moet worden is of dit account en dit apparaat nog recht hebben op een identiteit in de vloot, en dat antwoord leeft in uw assetregistraties, niet in het certificaat.

Een uitgerangeerde laptop waarvan de geplande taak nog loopt, zou geen nieuw recht moeten krijgen. RFC 7030 is hier de moeite waard, omdat het geauthenticeerde herregistratie scheidt van serverzijdige autorisatie en beleid; het is een model om van te lenen, geen bewering dat OpenVPN of EasyRSA dat protocol levert.

Leveren, klaarzetten en activeren als afzonderlijke stappen

Uitgifte behoudt identiteit, doel en uitgevende relatie, en een vervanging die met een nieuw sleutelpaar is gemaakt is nutteloos tenzij de bijpassende sleutel meereist. Lever het paar via een kanaal met een toegangscontroleontwerp erachter, want een niet te raden URL is verberging, geen controle.

Klaarzetten is waar de meeste automatisering stilletjes breekt. Een geïmporteerd profiel kan op één plek staan terwijl een beheerder elders een bestand bijwerkt, en de client blijft het oude certificaat presenteren tot iemand het merkt. Schrijf het pad op dat de client leest, het account dat erin mag schrijven en de gebeurtenis die een herlaad afdwingt. Bevestig dan dat de vervanging het bestand is dat echt in gebruik is en niet een kopie die ernaast aankwam.

Verificatie betekent een verse authenticatie met het nieuwe materiaal en een controle van de applicatie die de gebruiker nodig heeft. Een tunnel die al is opgezet, kan nog steeds het vorige bewijs weerspiegelen, dus een open verbinding is geen bewijs van een geslaagde verlenging.

Ontwerp eerst het herstel van het gemiste venster

Wanneer een laptop de registratiedienst alleen via de VPN bereikt, veroorzaakt de vervaldatum een lus: het apparaat heeft een certificaat nodig om de tunnel in te komen en de tunnel om het certificaat te halen. Bepaal de buitenbandse regeling voordat de eerste geplande taak uitgaat, of dat nu een apart geauthenticeerd registratie-eindpunt is of herregistratie met hulp van een beheerder.

Wat u ook kiest, het moet de aanvrager en het huidige recht verifiëren. De server zo configureren dat hij verlopen certificaten van iedereen die het vraagt accepteert, is geen herstelpad, het is een blijvende verzwakking van de controle die u met de rest van het ontwerp verdedigde.

Houd ten slotte verlenging en compromittering in aparte procedures. Een gelekte sleutel vereist intrekking en een reactie op actieve sessies, en het verlengen van de vervaldatum bevat daar niets van. Neem een offline apparaat, een mislukte levering en een uitgerangeerd asset op in de acceptatietest, en het schema is klaar om te activeren.