PKCS12, PEM eller DER: kva ein VPN-klient faktisk treng

I sertifikatdiskusjonar går to påstandar rundt. Den første er at .p12 er det sterke alternativet og .pem det lause; den andre at ei tekstfil må vere trygg å sende fordi du kan lese ho. Ingen av dei toler eitt minutt med inspeksjon.

PKCS12, PEM og DER skildrar korleis sertifikatobjekt blir pakka og koda. Dei avgjer ikkje kven motparten er, om utstødaren er betrudd, eller om fila treng eit passord.

Kva klienten godtek, er eit kompatibilitetsspørsmål. Kva fila inneheld, er eit identitetsspørsmål. Hald dei frå kvarandre, og dei fleste importfeil sluttar å vere mystiske.

Tre behaldarar, éin objektmodell

Byrja med det du faktisk har. Eit sertifikat er ei signert fråsegn om ein offentleg nøkkel. Den private nøkkelen er separat materiale som provar at du kontrollerer den nøkkelen. Ei kjede er settet av utstødarar som bind sertifikatet ditt til ei rot klienten stolar på. Alle tre finst uavhengig av pakkinga.

Ei PKCS12-fil, vanlegvis .p12 eller .pfx, er ein behaldar definert i RFC 7292 som kan bera ein privat nøkkel, eitt eller fleire sertifikat og kjeda i éin passordbeskytta blokk, med eit alias som namngir identiteten. Ei PEM-fil er tekstinnramming definert i RFC 7468: ein base64-kropp mellom BEGIN- og END-linjer, og éi fil kan halde fleire blokker etter kvarandre. DER er den binære kodinga av dei same ASN.1-strukturane, og PEM-kroppen er bokstaveleg tala DER pakka inn i base64.

Den siste setninga er verdt å hugse. Konvertering frå PEM til DER skriv om innramminga, ikkje innhaldet, og tilbakekonvertering gir dei opphavlege byta.

Koding er ikkje kryptering

base64 er eit transportalfabet. Det skjuler ingenting, og kven som helst kan dekode ein PEM-blokk i eit skal. Ei DER-fil er binær og like offentleg. Ingen av eigenskapane er vern, og ingen av dei antydar at det finst eit passord.

Det verkelege vernet ligg i nøkkelmaterialet. Ein PKCS12-pakke kan kryptere innhaldet under ein nøkkel utleidd frå eit passord. Ein privat PEM-nøkkel kan krypterast med ein gamal toppblokk eller oppbevarast i PKCS#8 EncryptedPrivateKeyInfo. Eit sertifikat åleine held ingenting hemmeleg, difor lèt ein eksport som berre gav eit sertifikat klienten utan høve til å autentisere, same kva format du pakkar det i.

Filendinga er eit hint, ikkje ein kontrakt. Filer som endar på .cer og .crt, førekjem i begge kodingane, og apparat eksporterer DER-sertifikat under .pem-namn ofte nok til at gissing ut frå endinga kostar ein ettermiddag. Les dei første byta i staden: ei PEM-fil opnar med ei BEGIN-linje, medan DER byrjar med 0x30 fordi den ytre strukturen er ein SEQUENCE.

Kvifor importen faktisk feilar

Feilmeldingane til klienten pressar fleire ulike problem inn i éi setning om eit ugyldig sertifikat, så skil dei etter årsak. Den vanlegaste er eit kodingavvik: ein klient som parsar PEM, returnerer ein parsefeil på ei DER-fil, og løysinga er ein konvertering, ikkje eit nytt sertifikat. Den andre er ein manglande nøkkel, der sertifikatet er i orden og identiteten ikkje kan provast. Den tredje er kjeda, der ein pakke utan mellomleddet ser rett ut i importdialogen og feilar under handtrykket.

Krypteringsparametrar årsakar ein fjerde, og den ser nøyaktig ut som eit feil passord. Eldre apparat eksporterte PKCS12-filer med RC2-40 og 3DES, som OpenSSL 3 avviser med mindre legacy-leverandøren er lasta. Å eksportere på nytt frå apparatet med AES-256-CBC og PBKDF2 er den varige løysinga. Å la gamle chiffre vere permanent påslått på ein klientmaskin for éi fil er ein dårleg handel.

Den femte er tvitydigheit. Ein behaldar med to nøklar og to sertifikat, eller ei PEM-fil med tre CERTIFICATE-blokker, tvingar klienten til å velje, og valet er ofte berre det første elementet. Når ein tunnel kjem opp med feil identitet, er det vanlegvis årsaka.

Inspiser før du konverterer

Les strukturen utan å skrive ut hemmelegheiter. openssl pkcs12 -in bundle.p12 -info -noout rapporterer krypteringsalgoritmane og aliasa og undertrykkjer nøkkel- og sertifikatutdata, og openssl-pkcs12-handboka dokumenterer flagga. Å fjerne -noout og leggje til -nodes er for å produsere filer du vil behalde, ikkje for eit raskt blikk, fordi det skriv den private nøkkelen i klartekst.

For eit sertifikat svarar openssl x509 -in cert.pem -noout -subject -issuer -dates på det ein importdialog ikkje vil svare på, og med -ext subjectAltName lagt til viser det namna sertifikatet faktisk er gyldig for. Er fila DER, legg til -inform DER; det eine flagget løyser dei fleste unable-to-load-feil.

Å matche ein nøkkel mot eit sertifikat er mekanisk, og verdt å gjere før kvar import:

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

Identiske digestar betyr at paret høyrer saman. Ulike digestar betyr at du har feil nøkkel, og inga formatkonvertering endrar det.

Kva formatet aldri endrar

Tillitsavgjerder blir tekne over behaldaren. Klienten går kjeda til ei rot i lageret sitt, kontrollerer gyldigheitsvindauget, kontrollerer utvida nøkkelbruk for klientautentisering, og på serversida kontrollerer han at namnet han ringde, finst i sertifikatet. Ingen av desse trinna les ei filending.

Difor er å gje ei fil nytt namn til ein feil forsvinn, ein så påliteleg måte å kaste bort tid. Importen lukkast, identiteten er framleis feil, og feilen dukkar opp att under handtrykket der meldinga er mindre hjelpsam. Difor blir òg ein pakke eksportert for to år sidan importert reint og likevel avvist: utløpsdatoen reiste inne i sertifikatet, ikkje i filnamnet.

Ein rekkjefølgje som unngår omarbeid

Spør dokumentasjonen til klienten kva kodingar han godtek og kva behaldar han ventar for ein klientidentitet, og sjå deretter på det du fekk. Vil klienten ha éin importerbar identitet og du har lause PEM-filer, bygg pakken éin gong med eit passord du kontrollerer, og ta vare på kjeldene. Vil han ha PEM, trekk ut nøkkelen og kjeda, og fjern deretter mellomfilene via prosessen for handtering av legitimasjon som teamet ditt allereie brukar.

Etter importen, verifiser identiteten i staden for dialogen: subjekt, utstødar, utløp og namnet klienten vil presentere. Eit venleg namn i ei liste er ei etikett, ikkje ein verifisert identitet. Feilar tunnelen deretter, feilsøkjer du autentisering eller ruting i staden for pakking, som er ein mykje kortare samtale.