PKCS12, PEM eller DER: hva en VPN-klient faktisk trenger

I sertifikatdiskusjoner går to påstander rundt. Den første er at .p12 er det sterke alternativet og .pem det løse; den andre at en tekstfil må være trygg å sende fordi du kan lese den. Ingen av dem tåler ett minutt med inspeksjon.

PKCS12, PEM og DER beskriver hvordan sertifikatobjekter pakkes og kodes. De avgjør ikke hvem motparten er, om utstederen er betrodd, eller om filen trenger et passord.

Hva klienten godtar, er et kompatibilitetsspørsmål. Hva filen inneholder, er et identitetsspørsmål. Hold dem fra hverandre, og de fleste importfeil slutter å være mystiske.

Tre beholdere, én objektmodell

Begynn med det du faktisk har. Et sertifikat er en signert erklæring om en offentlig nøkkel. Den private nøkkelen er separat materiale som beviser at du kontrollerer den nøkkelen. En kjede er settet av utstedere som binder sertifikatet ditt til en rot klienten stoler på. Alle tre finnes uavhengig av pakkingen.

En PKCS12-fil, vanligvis .p12 eller .pfx, er en beholder definert i RFC 7292 som kan bære en privat nøkkel, ett eller flere sertifikater og kjeden i én passordbeskyttet blokk, med et alias som navngir identiteten. En PEM-fil er tekstinnramming definert i RFC 7468: en base64-kropp mellom BEGIN- og END-linjer, og én fil kan holde flere blokker etter hverandre. DER er den binære kodingen av de samme ASN.1-strukturene, og PEM-kroppen er bokstavelig talt DER pakket inn i base64.

Den siste setningen er verdt å huske. Konvertering fra PEM til DER skriver om innrammingen, ikke innholdet, og tilbakekonvertering gir de opprinnelige bytene.

Koding er ikke kryptering

base64 er et transportalfabet. Det skjuler ingenting, og hvem som helst kan dekode en PEM-blokk i et skall. En DER-fil er binær og like offentlig. Ingen av egenskapene er beskyttelse, og ingen av dem antyder at det finnes et passord.

Den virkelige beskyttelsen ligger i nøkkelmaterialet. En PKCS12-pakke kan kryptere innholdet under en nøkkel utledet fra et passord. En privat PEM-nøkkel kan krypteres med en gammel toppblokk eller oppbevares i PKCS#8 EncryptedPrivateKeyInfo. Et sertifikat alene holder ingenting hemmelig, derfor etterlater en eksport som bare ga et sertifikat, klienten uten mulighet til å autentisere, uansett hvilket format du pakker det i.

Filendelsen er et hint, ikke en kontrakt. Filer som ender på .cer og .crt, forekommer i begge kodingene, og apparater eksporterer DER-sertifikater under .pem-navn ofte nok til at gjetting ut fra endelsen koster en ettermiddag. Les de første bytene i stedet: en PEM-fil åpner med en BEGIN-linje, mens DER begynner med 0x30 fordi den ytre strukturen er en SEQUENCE.

Hvorfor importen faktisk feiler

Klientens feilmeldinger presser flere ulike problemer inn i én setning om et ugyldig sertifikat, så skill dem etter årsak. Den vanligste er en koding mismatch: en klient som parser PEM, returnerer en parsefeil på en DER-fil, og løsningen er en konvertering, ikke et nytt sertifikat. Den andre er en manglende nøkkel, der sertifikatet er i orden og identiteten ikke kan bevises. Den tredje er kjeden, der en pakke uten mellomleddet ser riktig ut i importdialogen og feiler under håndtrykket.

Krypteringsparametere forårsaker en fjerde, og den ser nøyaktig ut som et feil passord. Eldre apparater eksporterte PKCS12-filer med RC2-40 og 3DES, som OpenSSL 3 avviser med mindre legacy-leverandøren er lastet. Å eksportere på nytt fra apparatet med AES-256-CBC og PBKDF2 er den varige løsningen. Å la gamle chiffre være permanent påslått på en klientmaskin for én fil er en dårlig handel.

Den femte er tvetydighet. En beholder med to nøkler og to sertifikater, eller en PEM-fil med tre CERTIFICATE-blokker, tvinger klienten til å velge, og valget er ofte bare det første elementet. Når en tunnel kommer opp med feil identitet, er det vanligvis årsaken.

Inspiser før du konverterer

Les strukturen uten å skrive ut hemmeligheter. openssl pkcs12 -in bundle.p12 -info -noout rapporterer krypteringsalgoritmene og aliasene og undertrykker nøkkel- og sertifikatutdata, og openssl-pkcs12-håndboken dokumenterer flaggene. Å fjerne -noout og legge til -nodes er for å produsere filer du vil beholde, ikke for et raskt titt, fordi det skriver den private nøkkelen i klartekst.

For et sertifikat besvarer openssl x509 -in cert.pem -noout -subject -issuer -dates det en importdialog ikke vil besvare, og med -ext subjectAltName lagt til vises navnene sertifikatet faktisk er gyldig for. Er filen DER, legg til -inform DER; det ene flagget løser de fleste unable-to-load-feil.

Å matche en nøkkel mot et sertifikat er mekanisk, og verdt å gjøre før enhver import:

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

Identiske digester betyr at paret hører sammen. Ulike digester betyr at du har feil nøkkel, og ingen formatkonvertering endrer det.

Hva formatet aldri endrer

Tillitsbeslutninger tas over beholderen. Klienten går kjeden til en rot i lageret sitt, kontrollerer gyldighetsvinduet, kontrollerer utvidet nøkkelbruk for klientautentisering, og på serversiden kontrollerer den at navnet den ringte, finnes i sertifikatet. Ingen av disse trinnene leser en filendelse.

Derfor er å gi en fil nytt navn til en feil forsvinner, en så pålitelig måte å kaste bort tid. Importen lykkes, identiteten er fortsatt feil, og feilen dukker opp igjen under håndtrykket der meldingen er mindre hjelpsom. Derfor importeres også en pakke eksportert for to år siden rent og avvises likevel: utløpsdatoen reiste inne i sertifikatet, ikke i filnavnet.

En rekkefølge som unngår omarbeid

Spør klientens dokumentasjon hvilke kodinger den godtar og hvilken beholder den forventer for en klientidentitet, og se deretter på det du fikk. Vil klienten ha én importerbar identitet og du har løse PEM-filer, bygg pakken én gang med et passord du kontrollerer, og ta vare på kildene. Vil den ha PEM, trekk ut nøkkelen og kjeden, og fjern deretter mellomfilene via prosessen for håndtering av legitimasjon som teamet ditt allerede bruker.

Etter importen, verifiser identiteten i stedet for dialogen: subjekt, utsteder, utløp og navnet klienten vil presentere. Et vennlig navn i en liste er en etikett, ikke en verifisert identitet. Hvis tunnelen deretter feiler, feilsøker du autentisering eller ruting i stedet for pakking, som er en mye kortere samtale.