PKCS12, PEM o DER: Ano ang Talagang Kailangan ng VPN Client

Dalawang pahayag ang umiikot sa mga usapan tungkol sa certificate. Ang una ay ang .p12 ang matibay na opsyon at ang .pem ang maluwag; ang pangalawa ay ang text file ay dapat ligtas ipadala dahil nababasa mo ito. Wala sa dalawa ang tumatagal ng isang minutong pagsusuri.

Inilalarawan ng PKCS12, PEM at DER kung paano pinapack at ini-encode ang mga certificate object. Hindi nila pinagpapasyahan kung sino ang peer, kung pinagkakatiwalaan ang issuer, o kung kailangan ng password ang file.

Ang tinatanggap ng client ay tanong ng compatibility. Ang laman ng file ay tanong ng identity. Paghiwalayin ang dalawang iyon at hindi na mahiwaga ang karamihan sa mga import error.

Tatlong container, isang object model

Magsimula sa kung ano talaga ang mayroon ka. Ang certificate ay isang pinirmahang pahayag tungkol sa isang public key. Ang private key ay hiwalay na materyal na nagpapatunay na kontrolado mo ang key na iyon. Ang chain ay ang set ng mga issuer na nag-uugnay sa certificate mo sa isang root na pinagkakatiwalaan ng client. Tatlo silang umiiral anuman ang packaging.

Ang PKCS12 file, kadalasang .p12 o .pfx, ay container na tinukoy sa RFC 7292 na kayang magdala ng private key, isa o higit pang certificate at ang chain sa isang blob na protektado ng password, may alias na nagpapangalan sa identity. Ang PEM file ay text framing na tinukoy sa RFC 7468: isang base64 body sa pagitan ng BEGIN at END na mga linya, at kayang maglaman ng ilang bloke nang sunud-sunod ang isang file. Ang DER ay ang binary encoding ng parehong ASN.1 structures, at ang PEM body ay literal na DER na binalot ng base64.

Ang huling pangungusap ang dapat tandaan. Ang pag-convert ng PEM sa DER ay nagsusulat muli ng balot, hindi ng nilalaman, at ibinabalik ng pag-convert pabalik ang orihinal na bytes.

Ang encoding ay hindi encryption

Ang Base64 ay isang transport alphabet. Wala itong itinatago, at kahit sino ay kayang i-decode ang isang PEM block sa shell. Ang DER file ay binary at parehong pampubliko. Wala sa dalawang katangiang iyon ang proteksyon, at wala ring nagpapahiwatig na may password.

Ang tunay na proteksyon ay nasa key material. Kayang i-encrypt ng PKCS12 bundle ang nilalaman nito sa ilalim ng key na nagmula sa password. Ang PEM private key ay kayang i-encrypt gamit ang legacy header block o itago sa loob ng PKCS#8 EncryptedPrivateKeyInfo. Ang certificate lang mismo ay walang anumang sekreto, kaya ang export na naglabas ng certificate lamang ay nag-iiwan sa client na hindi makapag-authenticate gaano man mo ito balutin sa anumang format.

Ang extension ay pahiwatig, hindi kontrata. Ang mga file na nagtatapos sa .cer at .crt ay lumilitaw sa parehong encoding, at madalas sapat na ini-export ng mga appliance ang DER certificate sa ilalim ng .pem na pangalan kaya ang paghula mula sa suffix ay nagsasayang ng isang hapon. Basahin ang unang bytes sa halip: ang PEM file ay nagbubukas sa BEGIN line, habang ang DER ay nagsisimula sa 0x30 dahil SEQUENCE ang panlabas na structure.

Bakit talaga nabigo ang import

Pinipiga ng mga client error message ang ilang magkaibang problema sa isang pangungusap tungkol sa invalid certificate, kaya paghiwalayin sila ayon sa dahilan. Ang pinakakaraniwan ay encoding mismatch: ang client na nagpa-parse ng PEM ay nagbabalik ng parse error sa DER file, at ang solusyon ay conversion hindi bagong certificate. Ang pangalawa ay kulang na key, kung saan maayos ang certificate at hindi mapatunayan ang identity. Ang pangatlo ay ang chain, kung saan ang bundle na walang intermediate nito ay mukhang tama sa import dialog at nabigo sa handshake.

Ang encryption parameters ang dahilan ng pang-apat, at eksaktong kamukha ito ng maling password. Ang lumang appliance ay nag-export ng PKCS12 file na may RC2-40 at 3DES, na tinatanggihan ng OpenSSL 3 maliban kung naka-load ang legacy provider. Ang muling pag-export mula sa appliance gamit ang AES-256-CBC at PBKDF2 ang matibay na solusyon. Ang pagpapabaya na nakabukas nang permanente ang legacy ciphers sa client machine para lang mapaubaya ang isang file ay masamang palitan.

Ang panglima ay kalabuan. Ang container na may dalawang key at dalawang certificate, o PEM file na may tatlong CERTIFICATE block, ay pinipilit pumili ang client, at kadalasan ang pinipili nito ay ang unang item lang. Kapag umangat ang tunnel na mali ang identity, iyon ang karaniwang dahilan.

Suriin bago mag-convert

Basahin ang structure nang hindi nagpi-print ng sekreto. openssl pkcs12 -in bundle.p12 -info -noout ay nag-uulat ng encryption algorithms at ng mga alias habang pinipigil ang key at certificate output, at ang openssl-pkcs12 manual ay nagdodokumento ng mga flag. Ang pagtanggal ng -noout at pagdagdag ng -nodes ay para sa paggawa ng file na balak mong itago, hindi para sa mabilisang sulyap, dahil isinusulat nito nang malinaw ang private key.

Para sa certificate, openssl x509 -in cert.pem -noout -subject -issuer -dates ang sumasagot sa hindi sinasagot ng import dialog, at ang pagdagdag ng -ext subjectAltName ay nagpapakita ng mga pangalang talagang valid para sa certificate. Kung DER ang file, idagdag ang -inform DER; ang nag-iisang flag na iyon ang lumulutas sa karamihan ng unable-to-load error.

Ang pagtutugma ng key sa certificate ay mekanikal, at sulit gawin bago ang anumang import:

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

Ang magkaparehong digest ay nangangahulugang magkapares ang dalawa. Ang magkaibang digest ay nangangahulugang mali ang key mo, at walang dami ng format conversion ang makakabago niyon.

Ang hindi binabago ng format

Ang mga desisyon sa tiwala ay nangyayari sa itaas ng container. Nilalakad ng client ang chain hanggang sa isang root sa store nito, sinusuri ang validity window, sinusuri ang extended key usage para sa client authentication, at sa panig ng server sinusuri na lumilitaw sa certificate ang pangalang dinial nito. Wala sa mga hakbang na iyon ang nagbabasa ng file extension.

Kaya naman ang pagpapalit ng pangalan ng file hanggang mawala ang error ay isang maaasahang paraan ng pag-aksaya ng oras. Nagtagumpay ang import, mali pa rin ang identity, at muling lumilitaw ang kabiguan sa handshake kung saan hindi gaanong nakakatulong ang mensahe. Kaya rin naman ang bundle na ini-export dalawang taon na ang nakalipas ay malinis na na-import at tinatanggihan pa rin: ang petsa ng pag-expire ay naglakbay sa loob ng certificate, hindi sa pangalan ng file.

Isang pagkakasunod-sunod na umiiwas sa rework

Itanong sa dokumentasyon ng client kung aling encoding ang tinatanggap nito at aling container ang inaasahan para sa client identity, pagkatapos tingnan ang ibinigay sa iyo. Kung gusto ng client ng isang importable identity at mayroon kang hiwa-hiwalay na PEM file, buuin ang bundle nang isang beses gamit ang password na kontrolado mo at itago ang mga source. Kung PEM ang gusto nito, kunin ang key at chain, at alisin ang mga intermediate file pagkatapos sa pamamagitan ng anumang proseso ng paghawak ng credential na ginagamit na ng team mo.

Pagkatapos ng import, i-verify ang identity hindi ang dialog: subject, issuer, expiry, at ang pangalang ipapakita ng client. Ang magiliw na pangalan sa listahan ay label, hindi verified identity. Kung mabigo ang tunnel pagkatapos, authentication o routing ang ini-debug mo sa halip na packaging, at mas maikli ang usapang iyon.