Prima di convertirlo: chiave SSH o certificato OpenVPN

L’importazione fallisce con un errore di certificato, quindi la mossa ovvia sembra una conversione. Quell’istinto porta le persone su un percorso in cui l’estensione del file cambia e il rifiuto resta esattamente lo stesso. Una riga ssh-ed25519 in authorized_keys e un certificato client OpenVPN sono oggetti di credenziali separati, con emittenti diversi, codifiche diverse e percorsi di revoca diversi. Percorrere questi controlli in ordine vi dice in un minuto se la conversione può aiutare davvero.

Quale oggetto avete in realtà?

Ci sono cinque cose che la gente chiama chiave, e solo una di queste è ciò che un profilo TLS vuole. Una chiave pubblica SSH è una singola riga di testo con un prefisso di tipo e un payload base64. Un certificato OpenSSH è quella chiave più una firma, principals e opzioni, prodotti da ssh-keygen che agisce come la propria piccola CA. Un certificato X.509 è una struttura del tutto diversa, che porta un soggetto, una finestra di validità, estensioni e una firma di un’autorità di certificazione. Una chiave privata è la metà segreta, e un pacchetto emesso è di solito un certificato più la sua catena più la chiave privata in un solo file.

Il primo test costa un comando. Puntate openssl sul file e chiedetegli di analizzare la struttura del certificato:

openssl x509 -in client.crt -noout -subject -issuer

Se questo fallisce con un errore di impossibile caricamento o PEM, il file non è un certificato X.509 qualunque nome gli abbiate dato. Un cambio di nome non riscrive l’ASN.1 all’interno, e nemmeno lo fa avvolgere una riga di chiave pubblica in un’intestazione PEM.

Il profilo chiede davvero un certificato?

I certificati client sono un metodo di autenticazione fra diversi, e molti profili TLS funzionanti non ne chiedono mai uno. Un server può autenticare gli utenti tramite un plugin, un nome utente e una password, o un backend a token, continuando comunque a richiedere che il client verifichi l’identità del server. Se il profilo non porta una direttiva di certificato client, nessun certificato verrà mai richiesto, e nessuna conversione farà chiedere un certificato al gateway.

Le vecchie configurazioni a chiave statica sono un terzo caso. Precedono l’handshake TLS e si aspettano un file di segreto pre-condiviso, ed è per questo che incollare una chiave pubblica in quel campo non può funzionare nemmeno lì. Leggete ciò che il profilo chiede davvero prima di decidere che la credenziale è sbagliata.

Cosa può e cosa non può fare la ricodifica

Le chiavi private hanno contenitori alternativi legittimi. La stessa chiave RSA o EC può essere scritta come PEM tradizionale, come PKCS#8, o dentro un pacchetto PKCS#12, e gli strumenti convertono volentieri fra loro. Le chiavi pubbliche hanno una storia simile: ssh-keygen può emettere la forma RFC 4716 di una chiave SSH, e OpenSSH comprende anche il proprio formato di certificato. Tutto questo è rappresentazione, e la rappresentazione non è fiducia.

Ciò che la conversione non può fare è creare una firma di un’autorità di certificazione che non ha mai visto la vostra chiave. Un certificato è un’asserzione di un emittente secondo cui una certa chiave pubblica appartiene a un certo soggetto per uno scopo certo. La ricodifica conserva i byte della chiave e lascia assente l’asserzione, così il gateway non ha nulla da validare contro il proprio archivio di fiducia.

Questo è il passo in cui la maggior parte dei tentativi fallisce in silenzio: il file ora termina in .crt, il client lo legge senza lamentarsi, e l’handshake abortisce comunque perché la controparte non riesce a costruire una catena fino a un emittente fidato.

Dove entra in gioco l’autorità di certificazione

Una vera registrazione inizia con una coppia di chiavi che controllate e una richiesta di firma di certificato che porta il soggetto atteso dall’operatore. L’operatore verifica il diritto, firma la richiesta con la chiave della CA e restituisce il certificato emesso insieme a qualsiasi catena intermedia che il client deve presentare. Poi il client ha bisogno del certificato della CA che l’ha firmato, perché è ciò che gli permette di confermare che il server con cui parla appartiene allo stesso deployment.

Quell’ultimo file è facile da dimenticare e impossibile da sostituire. La chiave di firma della CA stessa non appartiene mai alla configurazione del client, e nessuna quantità di conversione locale produce la catena che avreste dovuto ricevere.

Quanto vi costa riutilizzare la chiave SSH

Supponete che una conversione abbia davvero prodotto qualcosa di accettabile. Riutilizzare una coppia di chiavi per l’accesso SSH e l’autenticazione VPN accoppia comunque due decisioni di sicurezza indipendenti. Rimuovere una voce da authorized_keys ferma gli accessi SSH, e non fa nulla a un certificato che la CA della VPN ha già emesso per la stessa chiave pubblica. Il lato VPN viene revocato dal suo meccanismo, cioè la lista di revoca dei certificati o il registro di registrazione dell’operatore.

Quindi la lista di controllo termina con una condizione di arresto invece che con un trucco. Se openssl non analizza il file come certificato, smettete di convertire e descrivete ciò che avete: chiave SSH, certificato SSH, certificato X.509, chiave privata o pacchetto. Se il profilo non chiede un certificato client, fermatevi e chiedete quale metodo di autenticazione si aspetta il server. Solo quando entrambe le risposte puntano a X.509 la registrazione diventa il passo successivo, e quella conversazione va molto più veloce con il nome giusto nella prima frase.