Sospendere un client OpenVPN senza revocare il suo certificato

Quando un portatile finisce una settimana sul banco di riparazione, l'istinto abituale è rimuovere il suo certificato dalla CA. Quel record è il registro dell'emittente, non un interruttore d'accesso temporaneo. OpenVPN ha già un meccanismo per client per rifiutare una connessione, e usarlo mantiene intatta la storia della CA. I due controlli rispondono a domande diverse, e mescolarli crea lavoro quando il dispositivo torna.

Due registri, due lavori diversi

Il database della CA registra cosa ha firmato l'emittente e cosa ha revocato in seguito. Lo consultano i flussi di revoca e tutto ciò che legge la CRL o la propria copia del registro. Una regola di ammissione vive sul server e si applica alle connessioni che quel server accetta.

Eliminare un record di emissione non revoca un certificato in modo affidabile e danneggia la storia da cui dipendono la revoca o l'audit successivi. Il controllo lato server è più stretto e reversibile. Scrivete la differenza nella nota di modifica, così la persona successiva non cerca una revoca che non è mai avvenuta.

Mettete la direttiva di disattivazione nel file giusto

Per un server comunitario che usa una configurazione specifica per client, la direttiva documentata disable rifiuta un client selezionato. Appartiene al file di quel client sotto la client-config-dir attiva, non alla configurazione principale del server. Verificate la directory che il demone in esecuzione usa davvero, poi verificate l'identità che seleziona il file. Un file nominato con il common name sbagliato sembra corretto e non viene mai letto.

disable

Le scelte di mappatura contano qui. Opzioni come username-as-common-name cambiano quale identità usa la ricerca, quindi un file nominato secondo il soggetto del certificato potrebbe non essere quello applicato. Leggete la referenza di OpenVPN per la versione installata invece di dare per scontato che una direttiva sia valida in ogni contesto.

Separa la nuova ammissione dalle sessioni attive

Rifiutare il prossimo handshake non termina un tunnel già attivo. Se il dispositivo deve essere disconnesso adesso, usate anche il percorso autorizzato di gestione delle sessioni del server per quella specifica sessione. Altrimenti il client può continuare a funzionare finché non si riconnette da solo, e chiudere il coperchio del portatile o uscire dal client è un'azione lato client che non dice nulla sul server.

Verificate entrambi gli esiti: la sessione attiva si ferma quando volete, e un nuovo handshake viene negato. Una finestra del client chiusa non dimostra nulla sulla politica del server.

Se il deployment non ha un modo supportato di terminare una sessione attiva, registrate questa lacuna invece di improvvisarne uno. Una porta bloccata sul client non è la stessa cosa di una politica lato server.

Pausa e compromissione sono eventi diversi

Una chiave persa o rubata è un evento di revoca, e una pausa d'accesso locale non lo sostituisce. Gli altri server che si fidano della stessa CA non condivideranno questa regola specifica del client. Seguite il processo di revoca e sostituzione dell'emittente e mantenete il database della CA come registro autorevole. Una pausa temporanea, invece, richiede un motivo documentato e un passo di ripristino.

Quando l'accesso è ripristinato, rimuovete la restrizione tramite il componente che la possiede e confermate che una nuova connessione riesce. Annotate anche il percorso della riga disable, perché una successiva sincronizzazione della configurazione può rimetterla in silenzio. Conservate la pausa, il suo proprietario e la data nelle note di deployment, così l'amministratore successivo non trovi mesi dopo una riga disable inspiegata.