PKCS12, PEM o DER: cosa serve davvero a un client VPN

Nei thread sui certificati circolano due affermazioni. La prima è che un .p12 sia l’opzione forte e un .pem quella lasca; la seconda che un file di testo debba essere sicuro da inviare perché puoi leggerlo. Nessuna delle due resiste a un minuto di ispezione.

PKCS12, PEM e DER descrivono come gli oggetti certificato vengono impacchettati e codificati. Non decidono chi sia la controparte, se l’emittente sia fidato o se il file richieda una password.

Ciò che il client accetta è una questione di compatibilità. Ciò che il file contiene è una questione di identità. Tienile separate e la maggior parte degli errori di importazione smette di essere misteriosa.

Tre contenitori, un modello a oggetti

Parti da ciò che hai davvero. Un certificato è un’affermazione firmata su una chiave pubblica. La chiave privata è materiale separato che dimostra che controlli quella chiave. Una catena è l’insieme degli emittenti che collegano il tuo certificato a una radice di cui il client si fida. Tutti e tre esistono a prescindere dall’impacchettamento.

Un file PKCS12, di solito .p12 o .pfx, è un contenitore definito nella RFC 7292 che può portare una chiave privata, uno o più certificati e la catena in un unico blocco protetto da password, con un alias che nomina l’identità. Un file PEM è un’incorniciatura testuale definita nella RFC 7468: un corpo base64 tra righe BEGIN e END, e un file può contenere più blocchi in sequenza. DER è la codifica binaria delle stesse strutture ASN.1, e il corpo PEM è letteralmente DER avvolto in base64.

L’ultima frase vale la pena di ricordarla. Convertire PEM in DER riscrive l’involucro, non il contenuto, e la conversione inversa restituisce i byte originali.

Codificare non è cifrare

Base64 è un alfabeto di trasporto. Non nasconde nulla, e chiunque può decodificare un blocco PEM in una shell. Un file DER è binario e altrettanto pubblico. Nessuna delle due proprietà è protezione, e nessuna implica che esista una password.

La vera protezione sta nel materiale della chiave. Un pacchetto PKCS12 può cifrare il contenuto con una chiave derivata da una password. Una chiave privata PEM può essere cifrata con un vecchio blocco di intestazione o conservata in PKCS#8 EncryptedPrivateKeyInfo. Un certificato da solo non custodisce nulla di segreto, per questo un’esportazione che ha prodotto solo un certificato lascia il client incapace di autenticarsi, qualunque formato gli si dia.

L’estensione è un indizio, non un contratto. I file che terminano in .cer e .crt compaiono in entrambe le codifiche, e gli apparati esportano certificati DER con nomi .pem abbastanza spesso che indovinare dal suffisso costa un pomeriggio. Leggi invece i primi byte: un file PEM si apre con una riga BEGIN, mentre DER inizia con 0x30 perché la struttura esterna è una SEQUENCE.

Perché l’importazione fallisce davvero

I messaggi di errore del client comprimono problemi diversi in una frase su un certificato non valido, quindi sepàrali per causa. Il più comune è un disallineamento di codifica: un client che analizza PEM restituisce un errore di analisi su un file DER, e la correzione è una conversione, non un certificato nuovo. Il secondo è una chiave mancante, dove il certificato è a posto e l’identità non può essere provata. Il terzo è la catena, dove un pacchetto senza il suo intermedio sembra corretto nella finestra di importazione e fallisce durante l’handshake.

I parametri di cifratura causano un quarto, e sembra esattamente una password sbagliata. Gli apparati più vecchi esportavano file PKCS12 con RC2-40 e 3DES, che OpenSSL 3 rifiuta se non è caricato il provider legacy. Riesportare dall’apparato con AES-256-CBC e PBKDF2 è la correzione duratura. Lasciare cifrari vecchi attivi in permanenza su una macchina client per un solo file è un cattivo affare.

Il quinto è l’ambiguità. Un contenitore con due chiavi e due certificati, o un file PEM con tre blocchi CERTIFICATE, costringe il client a scegliere, e la sua scelta è spesso semplicemente il primo elemento. Quando un tunnel sale con l’identità sbagliata, di solito è questa la ragione.

Ispeziona prima di convertire

Leggi la struttura senza stampare segreti. openssl pkcs12 -in bundle.p12 -info -noout riporta gli algoritmi di cifratura e gli alias sopprimendo l’output di chiave e certificato, e il manuale di openssl-pkcs12 documenta le opzioni. Togliere -noout e aggiungere -nodes serve a produrre file che pensi di conservare, non a un’occhiata veloce, perché scrive la chiave privata in chiaro.

Per un certificato, openssl x509 -in cert.pem -noout -subject -issuer -dates risponde a ciò che una finestra di importazione non risponderà, e aggiungere -ext subjectAltName mostra i nomi per cui il certificato è davvero valido. Se il file è DER, aggiungi -inform DER; quel singolo flag risolve la maggior parte degli errori unable-to-load.

Abbinare una chiave a un certificato è meccanico, e vale la pena farlo prima di qualsiasi importazione:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Digest identici significano che la coppia va insieme. Digest diversi significano che hai la chiave sbagliata, e nessuna conversione di formato lo cambierà.

Ciò che il formato non cambia mai

Le decisioni di fiducia avvengono sopra il contenitore. Il client percorre la catena fino a una radice nel suo archivio, controlla la finestra di validità, controlla l’uso esteso della chiave per l’autenticazione del client e, lato server, controlla che il nome chiamato compaia nel certificato. Nessuno di questi passi legge un’estensione del file.

Per questo rinominare un file finché un errore scompare è un modo così affidabile di perdere tempo. L’importazione riesce, l’identità è ancora sbagliata e il guasto ricompare durante l’handshake, dove il messaggio è meno utile. È anche per questo che un pacchetto esportato due anni fa si importa senza problemi e viene comunque rifiutato: la data di scadenza viaggiava dentro il certificato, non nel nome del file.

Un ordine che evita rifacimenti

Chiedi alla documentazione del client quali codifiche accetta e quale contenitore si aspetta per un’identità client, poi guarda ciò che ti è stato consegnato. Se il client vuole un’unica identità importabile e tu hai file PEM separati, costruisci il pacchetto una volta con una password che controlli e conserva le fonti. Se vuole PEM, estrai la chiave e la catena, poi rimuovi i file intermedi tramite il processo di gestione delle credenziali che il tuo team usa già.

Dopo l’importazione, verifica l’identità invece della finestra: soggetto, emittente, scadenza e il nome che il client presenterà. Un nome amichevole in un elenco è un’etichetta, non un’identità verificata. Se poi il tunnel fallisce, stai debuggando autenticazione o routing invece dell’impacchettamento, il che è una conversazione molto più breve.