Il messaggio dice che OpenVPN non riesce a caricare un certificato in linea, e il nome del file che avete in mente dice il contrario. Conta di più ciò che ha ricevuto il parser di ciò che contiene il file system, perché la direttiva cert accetta due tipi di valore del tutto diversi. Uno è un percorso che apre; l’altro è testo PEM arrivato dentro la configurazione. Finché non sapete quale forma ha ricevuto il client in esecuzione, ogni correzione è un’ipotesi.

Due forme di archiviazione, una direttiva

Le direttive cert, key e ca accettano ciascuna un percorso o un blocco in linea. Quando il valore è un percorso, OpenVPN apre quel file e legge l’oggetto dal disco. Quando la configurazione contiene un blocco delimitato da tag cert, la stessa direttiva consuma invece il contenuto tra quei tag, e nessun file separato è coinvolto.

Entrambe le forme producono alla fine lo stesso tipo di oggetto, per questo un impiego funzionante può passare dall’una all’altra senza nessun’altra modifica. Un profilo che porta un certificato client e una chiave privata incorporati è autosufficiente, e copiarlo su un’altra macchina funziona senza copiare anche una directory di certificati.

Il contrario non è vero. Lasciare client.crt accanto a un profilo che incorpora i propri dati non cambia nulla, perché nulla nella configurazione fa riferimento a quel file. È la ragione più comune per cui un file che esiste chiaramente sembra essere ignorato.

Come un blocco in linea diventa un oggetto

Il contenuto in linea viene estratto dalla configurazione e consegnato al parser PEM come testo. Quel parser si aspetta i confini abituali: una riga BEGIN, un carico base64 e una riga END corrispondente. Se il blocco è stato troncato da una copia fallita, avvolto in HTML da una pagina di download o aperto in un editor che ha normalizzato i trattini, il parser fallisce su un contenuto che sembra presente.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Per questo anche la formulazione dell’errore è fuorviante. La parola in linea descrive dove ha guardato il caricatore, non che cosa vi ha trovato. Un file nominato in una configurazione e un oggetto incorporato in essa possono produrre la stessa lamentela quando i byte sottostanti sono inutilizzabili.

Verificate quale forma usa davvero il profilo caricato, non quale file il vostro editor ha aperto per caso:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Come viene risolto un riferimento di percorso

Un valore di percorso viene aperto rispetto alla directory di lavoro del client, non alla directory che contiene la configurazione. Sotto systemd quella directory di lavoro è quella impostata dall’unità, e un’esecuzione interattiva dalla vostra shell eredita qualcosa di completamente diverso. Per questo lo stesso file di configurazione può funzionare quando lo provate a mano e fallire come servizio.

I percorsi relativi ereditano la stessa ambiguità. Quando vedete un nome di file nudo, chiedete quale sia la directory corrente del processo in produzione invece di supporre che corrisponda al vostro terminale.

Per un certificato memorizzato separatamente, un’analisi offline conferma l’oggetto prima che diate la caccia a qualcosa sopra di esso:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Quei comandi dimostrano che i file sono leggibili e strutturalmente validi. Non dimostrano che il pari si fidi dell’emittente, che il certificato sia ancora dentro la sua finestra di validità o che la chiave gli appartenga.

Che cosa l’errore del parser può e non può dirvi

Un fallimento di analisi localizza il problema su un input e una fase. Non vi dice quale delle due forme di archiviazione abbia usato il client, e non vi dice se l’oggetto sarebbe stato accettato. Sono domande separate con prove separate.

Una volta che l’analisi riesce, il fallimento successivo appartiene a una fase più tarda. Un rifiuto di fiducia, una discrepanza di scopo o una discrepanza di chiave vengono segnalati dal pari o dallo strato TLS, non dal caricatore. Sostituire più volte lo stesso file non sposterà quell’errore.

Tenete la metà sensibile fuori dai rapporti pubblici mentre indagate. Condividete i nomi delle direttive, il testo dell’errore e la struttura del blocco, con il materiale della chiave e qualsiasi carico identificativo rimossi. Il manuale openvpn(8) documenta entrambe le forme delle direttive di file e il comportamento della directory di lavoro che ne sta dietro.

Articoli correlati