Rinnovo dei certificati OpenVPN: consegnate il certificato, non il timer

Due progetti di rinnovo sembrano identici in una revisione di progetto e si comportano in modo del tutto diverso a gennaio. Il primo esegue un timer, riemette certificati e lascia file in una cartella condivisa. Il secondo tratta il rinnovo come un problema di consegna: chi lo chiede, cosa dimostra l'idoneità, come il materiale raggiunge il dispositivo e cosa spinge il client a usarlo. Solo il secondo sopravvive a un portatile offline, a un asset dismesso e a una consegna fallita in silenzio.

Confrontate i due progetti dove differiscono davvero

Il progetto con timer ottimizza il lato server. Un'attività pianificata chiama la CA, appare un nuovo certificato e l'operatore considera il lavoro fatto. Tutto ciò che accade dopo l'emissione è un problema di qualcun altro, finché un dispositivo non riesce a connettersi e la data di scadenza ne spiega il motivo.

Il progetto a flusso di lavoro ottimizza l'ultimo miglio. Presuppone che l'emissione sia un anello di una catena e che ogni passo successivo possa fallire in modo indipendente. Costa di più costruirlo e molto meno gestirlo, perché i guasti emergono come stati tracciati invece che come client scaduti.

Un modo utile per tenere la differenza sotto gli occhi è la sequenza che ogni progetto deve nominare esplicitamente.

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

Rilevate la finestra dal certificato stesso

Leggete la validità dal certificato che il client presenta davvero, non dalla data incorporata in un nome file copiato. I nomi dei file si spostano, e un file che dice 2026 può contenere una credenziale che scade a marzo.

Lasciate margine nella finestra per i casi lenti: dispositivi offline per settimane, approvazioni che richiedono una persona e percorsi di consegna che falliscono una volta prima di funzionare. Un timer che segnala successo dimostra solo che il timer è stato eseguito, nulla di più.

Autorizzate la richiesta prima che venga emesso qualsiasi cosa

Un certificato esistente può far parte di un meccanismo di rinnovo legittimo, ma il suo testo di soggetto non è una decisione di autorizzazione. La domanda a cui rispondere è se questo account e questo dispositivo abbiano ancora diritto a un'identità nella flotta, e quella risposta vive nei vostri registri degli asset, non nel certificato.

Un portatile dismesso la cui attività pianificata è ancora in esecuzione non dovrebbe ricevere un nuovo diritto. RFC 7030 vale la pena leggerlo qui perché separa la riregistrazione autenticata dall'autorizzazione e dalla politica lato server; è un modello da prendere in prestito, non un'affermazione che OpenVPN o EasyRSA forniscano quel protocollo.

Consegna, preparazione e attivazione come passi separati

L'emissione preserva identità, scopo e relazione di emissione, e una sostituzione generata con una nuova coppia di chiavi è inutile se la chiave corrispondente non viaggia con essa. Consegnate la coppia su un canale con un progetto di controllo degli accessi dietro, perché un URL impossibile da indovinare è occultamento, non controllo.

La preparazione è dove la maggior parte dell'automazione si rompe in silenzio. Un profilo importato può restare in una posizione mentre un amministratore aggiorna un file altrove, e il client continua a presentare il vecchio certificato finché qualcuno non se ne accorge. Scrivete il percorso che il client legge, l'account che può scrivervi e l'evento che innesca un ricaricamento. Poi confermate che la sostituzione è il file realmente in uso e non una copia arrivata accanto.

La verifica significa un'autenticazione nuova con il nuovo materiale e un controllo dell'applicazione di cui l'utente ha bisogno. Un tunnel già stabilito può ancora riflettere la credenziale precedente, quindi una connessione aperta non è prova di un rinnovo riuscito.

Progettate prima il recupero della finestra mancata

Quando un portatile raggiunge il servizio di registrazione solo tramite la VPN, la scadenza crea un ciclo: il dispositivo ha bisogno di un certificato per entrare nel tunnel e il tunnel per recuperare il certificato. Decidete l'accordo fuori banda prima che parta la prima attività pianificata, che sia un endpoint di registrazione autenticato a parte o una riregistrazione assistita dall'amministratore.

Qualunque cosa scegliate, deve verificare il richiedente e il diritto attuale. Configurare il server per accettare certificati scaduti da chiunque lo chieda non è un percorso di recupero, è un indebolimento permanente del controllo che avete difeso con il resto del progetto.

Infine, tenete rinnovo e compromissione in procedure separate. Una chiave divulgata richiede revoca e una risposta alle sessioni attive, e prolungare la data di scadenza non contiene nulla di tutto ciò. Includete un dispositivo offline, una consegna fallita e un asset dismesso nel test di accettazione, e il calendario è pronto per essere attivato.