Serve un altro certificato per un altro portatile, ma il primo tutorial nei risultati inizia con un comando che cancella la directory PKI. Quel comando appartiene alla prima configurazione, non all’iscrizione, ed eseguirlo costa la CA, la cronologia delle emissioni e ogni profilo client che si fidava del vecchio emittente. La decisione è più stretta: l’emittente ha ancora uno stato utilizzabile e il nuovo dispositivo rientra nella tua politica di iscrizione? Tre condizioni decidono, una sola giustifica una ricostruzione.

Che cosa distrugge davvero una ricostruzione

Reinizializzare una PKI sostituisce la directory con una struttura vuota: nuova chiave e nuovo certificato CA, database delle emissioni vuoto, contatore di serie nuovo. I client non seguono in silenzio; i loro profili fissano la vecchia CA, quindi ogni dispositivo deve reiscriversi, e quelli irraggiungibili a mano.

La perdita più silenziosa è la contabilità. La revoca dipende dal sapere quali numeri di serie hai emesso e a chi. Cancella l’indice e puoi ancora firmare, ma non affermare con certezza quali dei certificati in circolazione volevi revocare. Una directory CA con certificati senza lo stato dell’emittente ripristina la metà sbagliata del sistema.

Copiare la chiave privata della CA accanto al server in esecuzione è l’altra scorciatoia da rifiutare: trasforma un’autorità di firma che dovrebbe restare offline in un altro file su un host che termina traffico non fidato.

Prima condizione: lo stato dell’emittente è ancora raggiungibile?

Individua la directory di cui il server si fida davvero prima di decidere. Confronta il certificato che il server presenta come CA con quello nella directory PKI tramite impronta, non tramite nome file:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Se le impronte coincidono, l’iscrizione è incrementale e non devi ricostruire nulla. Se differiscono, firmi con una CA di cui il server non si fida: il certificato si installa pulito e falla alla stretta di mano, e quell’errore viene diagnosticato per ore come difetto del client.

Poi cerca lo stato delle emissioni: il file indice, il contatore di serie e il file del numero CRL. Se l’indice è sparito ma la chiave sopravvive, puoi emettere, ma erediti un problema di registrazione delle revoche. Annotalo nel registro delle modifiche, perché la prossima revoca lo rivelerà.

Seconda condizione: chi custodisce la nuova chiave privata?

È la decisione che gli utenti percepiscono, quindi prendila esplicitamente. Una chiave generata sul client e inviata come richiesta lascia la metà privata sul dispositivo dal primo comando e l’amministratore non la tocca mai. Una chiave generata sul server è più semplice per dispositivi senza strumenti, ma rende l’amministratore custode di ogni chiave e amplia l’impatto di una compromissione.

Con Easy-RSA 3 contro una CA esistente, importare e firmare una richiesta sono due comandi:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Scegli il tipo di certificato deliberatamente. Una richiesta firmata come certificato server invece che client produce un file che sembra corretto e che il pari rifiuta, e il messaggio di errore raramente dice perché. Con openssl ca la stessa scelta vive nelle estensioni che passi, non nella sezione predefinita.

Terza condizione: il server ha bisogno di più di un certificato?

Per un normale server OpenVPN con autenticazione a certificato, il certificato è l’iscrizione: il nome comune diventa l’identità del client, e ogni directory, rotta inviata o indirizzo statico dipende da quel nome. Aggiungi il certificato e dimentica la configurazione: il tunnel si connette ma le rotte necessarie non compaiono mai.

Le piattaforme cambiano questo. OpenVPN Access Server mantiene un proprio database utenti, quindi un certificato firmato non è un account; l’account deve esistere ed essere autorizzato. Altri gateway associano una stringa di identità a un gruppo. Iscrivere un dispositivo di solito tocca due sistemi, e il certificato è solo il primo.

La procedura incrementale e quando ricostruire

La sequenza che aggiunge un dispositivo senza danni: conferma l’emittente tramite impronta, prendi una copia fresca della directory PKI, importa e firma la richiesta per il ruolo client, consegna il certificato con la sua catena sul canale approvato, poi verifica prima che l’utente si connetta:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

La riga dello scopo deve mostrare SSL client. Chiudi aggiornando la copia della CA dopo l’emissione, perché una copia presa prima del nuovo numero di serie ripristina uno stato senza il dispositivo appena aggiunto.

Ricostruire è corretto in tre casi: la chiave della CA è compromessa, lo stato delle emissioni è irrimediabilmente perduto, oppure cambi deliberatamente algoritmo o politica. Tutti e tre sono progetti con un piano di reiscrizione per ogni client, non passi di una richiesta per un dispositivo. Se nessuno si applica, iscrivi in modo incrementale.

Articoli correlati