PKCS12, PEM o DER: què necessita realment un client VPN

En els debats sobre certificats circulen dues afirmacions. La primera és que un .p12 és l'opció forta i un .pem la fluixa; la segona, que un fitxer de text ha de ser segur d'enviar perquè el podeu llegir. Cap de les dues resisteix un minut d'inspecció.

PKCS12, PEM i DER descriuen com s'empaqueten i es codifiquen els objectes de certificat. No decideixen qui és l'igual, si l'emissor és de confiança o si el fitxer necessita contrasenya.

Què accepta el client és una qüestió de compatibilitat. Què conté el fitxer és una qüestió d'identitat. Separeu-les i la majoria d'errors d'importació deixaran de ser misteriosos.

Tres contenidors, un model d'objecte

Comenceu per allò que realment teniu. Un certificat és una declaració signada sobre una clau pública. La clau privada és material separat que demostra que controleu aquesta clau. Una cadena és el conjunt d'emissors que enllacen el certificat amb una arrel en què confia el client. Tots tres existeixen independentment de l'embalatge.

Un fitxer PKCS12, normalment .p12 o .pfx, és un contenidor definit a RFC 7292 que pot portar una clau privada, un o més certificats i la cadena en un sol bloc protegit per contrasenya, amb un àlies que anomena la identitat. Un fitxer PEM és un marc de text definit a RFC 7468: un cos base64 entre línies BEGIN i END, i un fitxer pot contenir diversos blocs en seqüència. DER és la codificació binària de les mateixes estructures ASN.1, i el cos PEM és literalment DER embolcallat amb base64.

Aquesta darrera frase val la pena retenir-la. Convertir PEM a DER reescriu l'embolcall, no el contingut, i convertir de tornada retorna els bytes originals.

Codificar no és xifrar

Base64 és un alfabet de transport. No amaga res i qualsevol pot descodificar un bloc PEM en un shell. Un fitxer DER és binari i igualment públic. Cap de les dues propietats és protecció i cap no implica que existeixi una contrasenya.

La protecció real viu en el material de la clau. Un paquet PKCS12 pot xifrar el contingut amb una clau derivada d'una contrasenya. Una clau privada PEM es pot xifrar amb un bloc de capçalera antic o guardar dins de PKCS#8 EncryptedPrivateKeyInfo. Un certificat sol no guarda res secret, per això una exportació que només va produir un certificat deixa el client incapaç d'autenticar-se, sigui quin sigui el format amb què l'emboliqueu.

L'extensió és un indici, no un contracte. Els fitxers acabats en .cer i .crt apareixen en les dues codificacions, i els aparells exporten certificats DER amb noms .pem prou sovint perquè endevinar per la terminació costi una tarda. Llegiu els primers bytes: un fitxer PEM comença amb una línia BEGIN, mentre que DER comença amb 0x30 perquè l'estructura exterior és una SEQUENCE.

Per què falla realment la importació

Els missatges d'error del client comprimeixen diversos problemes en una frase sobre un certificat no vàlid, així que separeu-los per causa. El més comú és un desajust de codificació: un client que analitza PEM retorna un error d'anàlisi en un fitxer DER, i la solució és una conversió, no un certificat nou. El segon és una clau absent, on el certificat és correcte i la identitat no es pot provar. El tercer és la cadena, on un paquet sense el seu intermedi sembla correcte al diàleg d'importació i falla durant l'establiment de la connexió.

Els paràmetres de xifratge causen un quart, i sembla exactament una contrasenya incorrecta. Els aparells antics exportaven fitxers PKCS12 amb RC2-40 i 3DES, que OpenSSL 3 refusa si no es carrega el proveïdor legacy. Reexportar des de l'aparell amb AES-256-CBC i PBKDF2 és la solució duradora. Deixar xifrats antics activats permanentment en una màquina client per encabir un fitxer és un mal negoci.

El cinquè és l'ambigüitat. Un contenidor amb dues claus i dos certificats, o un fitxer PEM amb tres blocs CERTIFICATE, obliga el client a triar, i la seva tria sovint és simplement el primer element. Quan un túnel s'aixeca amb la identitat equivocada, normalment és aquesta la raó.

Inspeccioneu abans de convertir

Llegiu l'estructura sense imprimir secrets. openssl pkcs12 -in bundle.p12 -info -noout informa dels algorismes de xifratge i dels àlies mentre suprimeix la sortida de clau i certificat, i el manual d'openssl-pkcs12 documenta els indicadors. Treure -noout i afegir -nodes serveix per produir fitxers que pensau guardar, no per a una ullada ràpida, perquè escriu la clau privada en clar.

Per a un certificat, openssl x509 -in cert.pem -noout -subject -issuer -dates respon allò que un diàleg d'importació no respondrà, i afegir -ext subjectAltName mostra els noms per als quals el certificat és realment vàlid. Si el fitxer és DER, afegiu -inform DER; aquest sol indicador resol la majoria d'errors unable-to-load.

Emparellar una clau amb un certificat és mecànic, i val la pena fer-ho abans de qualsevol importació:

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

Digerits idèntics volen dir que la parella va junta. Digerits diferents volen dir que teniu la clau equivocada, i cap conversió de format ho canviarà.

Què no canvia mai el format

Les decisions de confiança passen per sobre del contenidor. El client recorre la cadena fins a una arrel del seu magatzem, comprova la finestra de validesa, comprova l'ús estès de la clau per a l'autenticació del client i, al costat del servidor, comprova que el nom que ha marcat apareix al certificat. Cap d'aquests passos llegeix una extensió de fitxer.

Per això renombrar un fitxer fins que un error desaparegui és una manera tan fiable de perdre temps. La importació té èxit, la identitat segueix sent incorrecta i la fallada reapareix durant l'establiment de la connexió, on el missatge és menys útil. També per això un paquet exportat fa dos anys s'importa netament i tot i així es rebutja: la data de caducitat viatjava dins del certificat, no al nom del fitxer.

Un ordre que evita refer la feina

Pregunteu a la documentació del client quines codificacions accepta i quin contenidor espera per a una identitat de client, i mireu després què us han lliurat. Si el client vol una única identitat importable i teniu fitxers PEM solts, construïu el paquet un cop amb una contrasenya que controleu i guardeu les fonts. Si vol PEM, extraieu la clau i la cadena, i després elimineu els fitxers intermedis mitjançant el procés de gestió de credencials que el vostre equip ja fa servir.

Després d'importar, verifiqueu la identitat en lloc del diàleg: subjecte, emissor, caducitat i el nom que el client presentarà. Un nom amable en una llista és una etiqueta, no una identitat verificada. Si llavors el túnel falla, esteu depurant autenticació o encaminament en lloc d'embalatge, que és una conversa molt més curta.