PKCS12, PEM of DER: wat ’n VPN-kliënt werklik nodig het

Twee bewerings wonder in sertifikaatbesprekings rond. Die eerste is dat ’n .p12 die sterk opsie is en ’n .pem die los een; die tweede is dat ’n tekslêer veilig moet wees om te stuur omdat jy dit kan lees. Nie een oorleef ’n minuut se ondersoek nie.

PKCS12, PEM en DER beskryf hoe sertifikaatvoorwerpe verpak en geënkodeer word. Hulle besluit nie wie die eweknie is, of die uitreiker vertrou word, of die lêer ’n wagwoord nodig het nie.

Wat die kliënt aanvaar, is ’n versoenbaarheidsvraag. Wat die lêer bevat, is ’n identiteitsvraag. Hou dié twee apart en die meeste invoerfoute hou op om raaiselagtig te wees.

Drie houers, een voorwerpmodel

Begin met wat jy werklik het. ’n Sertifikaat is ’n ondertekende verklaring oor ’n publieke sleutel. Die private sleutel is aparte materiaal wat bewys jy beheer daardie sleutel. ’n Ketting is die stel uitreikers wat jou sertifikaat aan ’n wortel verbind wat die kliënt vertrou. Al drie bestaan ongeag die verpakking.

’n PKCS12-lêer, gewoonlik .p12 of .pfx, is ’n houer wat in RFC 7292 gedefinieer word en ’n private sleutel, een of meer sertifikate en die ketting in ’n enkele wagwoordbeskermde blob kan dra, met ’n alias wat die identiteit benoem. ’n PEM-lêer is teksraamwerk volgens RFC 7468: ’n base64-liggaam tussen BEGIN- en END-lyne, en een lêer kan verskeie blokke in volgorde hou. DER is die binêre enkodering van dieselfde ASN.1-strukture, en die PEM-liggaam is letterlik DER met base64 daarom.

Daardie laaste sin is die een wat werd is om te onthou. Om PEM na DER om te skakel herskryf die raamwerk, nie die inhoud nie, en terugskakeling lewer die oorspronklike grepe.

Enkodering is nie enkripsie nie

Base64 is ’n vervoeralfabet. Dit verberg niks, en enigiemand kan ’n PEM-blok in ’n dop dekodeer. ’n DER-lêer is binêr en ewe openbaar. Nie een eienskap is beskerming nie, en nie een impliseer dat ’n wagwoord bestaan nie.

Ware beskerming lê in die sleutelmateriaal. ’n PKCS12-bondel kan sy inhoud onder ’n wagwoordafgeleide sleutel enkripteer. ’n PEM private sleutel kan met ’n ou kopblok geënkripteer word of in PKCS#8 EncryptedPrivateKeyInfo gehou word. ’n Sertifikaat op sy eie hou niks geheims nie, en daarom laat ’n uitvoer wat net ’n sertifikaat opgelewer het, die kliënt nie authentiseer nie, maak nie saak in watter formaat jy dit draai nie.

Die uitbreiding is ’n wenk, nie ’n kontrak nie. Lêers wat op .cer en .crt eindig, verskyn in beide enkoderings, en toestelle voer DER-sertifikate gereeld onder .pem-name uit, soveel dat raai op grond van die agtervoegsel ’n middag mors. Lees eerder die eerste grepe: ’n PEM-lêer open met ’n BEGIN-lyn, terwyl DER met 0x30 begin omdat die buitenste struktuur ’n SEQUENCE is.

Waarom die invoer werklik misluk

Kliëntfoutboodskappe pers verskeie probleme in een sin oor ’n ongeldige sertifikaat saam, so skei hulle volgens oorsaak. Die algemeenste is ’n enkoderingsverskil: ’n kliënt wat PEM ontleed, gee ’n ontledingsfout op ’n DER-lêer, en die oplossing is ’n omskakeling eerder as ’n nuwe sertifikaat. Die tweede is ’n ontbrekende sleutel, waar die sertifikaat reg is en die identiteit nie bewys kan word nie. Die derde is die ketting, waar ’n bondel sonder sy tussen sertifikaat korrek in die invoerdialoog lyk en tydens die handskud misluk.

Enkripsieparameters veroorsaak ’n vierde, en dit lyk presies soos ’n verkeerde wagwoord. Ouer toestelle het PKCS12-lêers met RC2-40 en 3DES uitgevoer, wat OpenSSL 3 weier tensy die legacy-verskaffer gelaai is. Heruitvoer uit die toestel met AES-256-CBC en PBKDF2 is die duursame oplossing. Om ou syfers permanent op ’n kliëntmasjien aan te skakel om een lêer te akkommodeer, is ’n slegte ruil.

’n Vyfde is dubbelsinnigheid. ’n Houer met twee sleutels en twee sertifikate, of ’n PEM-lêer met drie CERTIFICATE-blokke, dwing die kliënt om te kies, en sy keuse is dikwels bloot die eerste item. Wanneer ’n tonnel met die verkeerde identiteit opkom, is dit gewoonlik die rede.

Ondersoek voordat jy omskakel

Lees die struktuur sonder om geheime te druk. openssl pkcs12 -in bundle.p12 -info -noout rapporteer die enkripsiealgoritmes en die aliasse terwyl sleutel- en sertifikaatuitvoer onderdruk word, en die openssl-pkcs12-handleiding dokumenteer die vlae. Om -noout te laat val en -nodes by te voeg, is vir lêers wat jy wil bewaar, nie vir ’n vinnige kyk nie, want dit skryf die private sleutel in die oopte.

Vir ’n sertifikaat beantwoord openssl x509 -in cert.pem -noout -subject -issuer -dates wat ’n invoerdialoog nie sal nie, en met -ext subjectAltName bygevoeg wys dit die name waarvoor die sertifikaat werklik geldig is. As die lêer DER is, voeg -inform DER by; daardie enkele vlag los die meeste unable-to-load-foute op.

’n Sleutel aan ’n sertifikaat koppel is meganies, en die moeite werd voor enige invoer:

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

Identiese verterings beteken die paar hoort saam. Verskillende verterings beteken jy het die verkeerde sleutel, en geen formaatomskakeling sal dit verander nie.

Wat die formaat nooit verander nie

Vertrouensbesluite gebeur bo die houer. Die kliënt stap die ketting na ’n wortel in sy stoor, kontroleer die geldigheidsvenster, kontroleer uitgebreide sleutelgebruik vir kliëntverifikasie, en kontroleer aan die bedienerkant dat die naam wat dit geskakel het in die sertifikaat voorkom. Nie een van daardie stappe lees ’n lêeruitbreiding nie.

Daarom is ’n lêer hernoem tot ’n fout verdwyn so ’n betroubare manier om tyd te mors. Die invoer slaag, die identiteit is steeds verkeerd, en die fout verskyn weer tydens die handskud waar die boodskap minder behulpsaam is. Dit is ook waarom ’n bondel wat twee jaar gelede uitgevoer is, skoon invoer en steeds verwerp word: die vervaldatum het in die sertifikaat gereis, nie in die lêernaam nie.

’n Volgorde wat herwerk vermy

Vra die kliënt se dokumentasie watter enkoderings dit aanvaar en watter houer dit vir ’n kliëntidentiteit verwag, en kyk dan na wat aan jou gegee is. As die kliënt een invoerbare identiteit wil en jy het los PEM-lêers, bou die bondel een keer met ’n wagwoord wat jy beheer en hou die bronne. As dit PEM wil, onttrek die sleutel en ketting, en verwyder die tussenlêers daarna deur die proses vir die hantering van geloofsbriewe wat jou span reeds gebruik.

Verifieer ná die invoer die identiteit eerder as die dialoog: onderwerp, uitreiker, vervaldatum en die naam wat die kliënt sal voorlê. ’n Vriendelike naam in ’n lys is ’n etiket, nie ’n geverifieerde identiteit nie. As die tonnel daarna misluk, ontfout jy verifikasie of roetering eerder as verpakking, wat ’n baie korter gesprek is.