PKCS12, PEM sau DER: de ce are nevoie de fapt un client VPN

În discuțiile despre certificate circulă două afirmații. Prima este că un .p12 este opțiunea solidă și un .pem cea laxă; a doua, că un fișier text trebuie să fie sigur de trimis pentru că îl puteți citi. Niciuna nu rezistă un minut de inspecție.

PKCS12, PEM și DER descriu cum obiectele certificat sunt ambalate și codificate. Nu decid cine este partenerul, dacă emitentul este de încredere sau dacă fișierul necesită o parolă.

Ce acceptă clientul este o chestiune de compatibilitate. Ce conține fișierul este o chestiune de identitate. Țineți-le separate și majoritatea erorilor de import încetează să mai fie misterioase.

Trei containere, un singur model de obiect

Începeți cu ce aveți cu adevărat. Un certificat este o declarație semnată despre o cheie publică. Cheia privată este material separat care dovedește că controlați acea cheie. Un lanț este mulțimea emitenților care leagă certificatul dumneavoastră de o rădăcină în care clientul are încredere. Toate trei există indiferent de ambalare.

Un fișier PKCS12, de obicei .p12 sau .pfx, este un container definit în RFC 7292 care poate purta o cheie privată, unul sau mai multe certificate și lanțul într-un singur bloc protejat de parolă, cu un alias care numește identitatea. Un fișier PEM este o încadrare text definită în RFC 7468: un corp base64 între liniile BEGIN și END, iar un fișier poate conține mai multe blocuri la rând. DER este codificarea binară a acelorași structuri ASN.1, iar corpul PEM este literalmente DER învelit în base64.

Ultima propoziție merită reținută. Conversia PEM în DER rescrie încadrarea, nu conținutul, iar conversia inversă returnează octeții originali.

Codificarea nu este criptare

Base64 este un alfabet de transport. Nu ascunde nimic și oricine poate decoda un bloc PEM într-un shell. Un fișier DER este binar și la fel de public. Niciuna dintre proprietăți nu este protecție și niciuna nu implică existența unei parole.

Protecția reală stă în materialul cheii. Un pachet PKCS12 poate cripta conținutul cu o cheie derivată dintr-o parolă. O cheie privată PEM poate fi criptată cu un bloc vechi de antet sau păstrată în PKCS#8 EncryptedPrivateKeyInfo. Un certificat singur nu păstrează nimic secret, de aceea un export care a produs doar un certificat lasă clientul incapabil să se autentifice, indiferent de formatul în care îl înveliți.

Extensia este un indiciu, nu un contract. Fișierele care se termină în .cer și .crt apar în ambele codificări, iar aparatele exportă certificate DER cu nume .pem suficient de des încât ghicitul după sufix să coste o după-amiază. Citiți primii octeți: un fișier PEM începe cu o linie BEGIN, în timp ce DER începe cu 0x30 pentru că structura exterioară este un SEQUENCE.

De ce eșuează de fapt importul

Mesajele de eroare ale clientului comprimă mai multe probleme diferite într-o propoziție despre un certificat invalid, așa că separați-le după cauză. Cea mai frecventă este nepotrivirea de codificare: un client care parsează PEM returnează o eroare de parsare pe un fișier DER, iar soluția este o conversie, nu un certificat nou. A doua este o cheie lipsă, când certificatul este în regulă și identitatea nu poate fi dovedită. A treia este lanțul, când un pachet fără intermediarul său pare corect în dialogul de import și eșuează în timpul handshake-ului.

Parametrii de criptare provoacă un al patrulea, și arată exact ca o parolă greșită. Aparatele mai vechi exportau fișiere PKCS12 cu RC2-40 și 3DES, pe care OpenSSL 3 le refuză dacă furnizorul legacy nu este încărcat. Reexportarea din aparat cu AES-256-CBC și PBKDF2 este corectarea durabilă. A lăsa cifruri vechi activate permanent pe un calculator client pentru un singur fișier este o afacere proastă.

Al cincilea este ambiguitatea. Un container cu două chei și două certificate, sau un fișier PEM cu trei blocuri CERTIFICATE, forțează clientul să aleagă, iar alegerea este adesea pur și simplu primul element. Când un tunel urcă cu identitatea greșită, de obicei acesta este motivul.

Inspectați înainte de a converti

Citiți structura fără a tipări secrete. openssl pkcs12 -in bundle.p12 -info -noout raportează algoritmii de criptare și aliasurile, suprimând ieșirea cheii și a certificatului, iar manualul openssl-pkcs12 documentează opțiunile. Eliminarea -noout și adăugarea -nodes este pentru a produce fișiere pe care intenționați să le păstrați, nu pentru o privire rapidă, pentru că scrie cheia privată în clar.

Pentru un certificat, openssl x509 -in cert.pem -noout -subject -issuer -dates răspunde la ce nu va răspunde un dialog de import, iar adăugarea -ext subjectAltName arată numele pentru care certificatul este cu adevărat valid. Dacă fișierul este DER, adăugați -inform DER; acel singur indicator rezolvă majoritatea erorilor unable-to-load.

Potrivirea unei chei cu un certificat este mecanică și merită făcută înainte de orice import:

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

Amprentele identice înseamnă că perechea merge împreună. Amprentele diferite înseamnă că aveți cheia greșită, iar nicio conversie de format nu va schimba asta.

Ce nu schimbă niciodată formatul

Deciziile de încredere se iau deasupra containerului. Clientul parcurge lanțul până la o rădăcină din depozitul său, verifică fereastra de valabilitate, verifică utilizarea extinsă a cheii pentru autentificarea clientului și, pe partea de server, verifică dacă numele apelat apare în certificat. Niciunul dintre acești pași nu citește o extensie de fișier.

De aceea redenumirea unui fișier până când o eroare dispare este o modalitate atât de sigură de a pierde timp. Importul reușește, identitatea este în continuare greșită, iar eșecul reapare în timpul handshake-ului, unde mesajul este mai puțin util. De aceea și un pachet exportat acum doi ani se importă curat și totuși este respins: data de expirare călătorea în certificat, nu în numele fișierului.

O ordine care evită reluarea muncii

Întrebați documentația clientului ce codificări acceptă și ce container așteaptă pentru o identitate de client, apoi priviți ce vi s-a dat. Dacă clientul vrea o singură identitate importabilă și aveți fișiere PEM separate, construiți pachetul o dată cu o parolă pe care o controlați și păstrați sursele. Dacă vrea PEM, extrageți cheia și lanțul, apoi eliminați fișierele intermediare prin procesul de gestionare a acreditărilor pe care echipa dumneavoastră îl folosește deja.

După import, verificați identitatea, nu dialogul: subiect, emitent, expirare și numele pe care clientul îl va prezenta. Un nume prietenos într-o listă este o etichetă, nu o identitate verificată. Dacă apoi tunelul eșuează, depanați autentificarea sau rutarea în loc de ambalare, ceea ce este o conversație mult mai scurtă.