PKCS12, PEM eller DER: hvad en VPN-klient faktisk har brug for

I certifikattråde cirkulerer to påstande. Den første er, at en .p12 er den stærke mulighed og en .pem den løse; den anden, at en tekstfil må være sikker at sende, fordi man kan læse den. Ingen af dem holder en minuts inspektion.

PKCS12, PEM og DER beskriver, hvordan certifikatobjekter pakkes og kodes. De afgør ikke, hvem modparten er, om udstederen er betroet, eller om filen kræver en adgangskode.

Hvad klienten accepterer, er et kompatibilitetsspørgsmål. Hvad filen indeholder, er et identitetsspørgsmål. Hold dem adskilt, og de fleste importfejl holder op med at være mystiske.

Tre containere, én objektmodel

Begynd med det, du faktisk har. Et certifikat er en signeret erklæring om en offentlig nøgle. Den private nøgle er separat materiale, der beviser, at du kontrollerer den nøgle. En kæde er det sæt udstedere, der forbinder dit certifikat med en rod, som klienten betror sig til. Alle tre findes uanset pakningen.

En PKCS12-fil, normalt .p12 eller .pfx, er en container defineret i RFC 7292, som kan bære en privat nøgle, et eller flere certifikater og kæden i én adgangskodebeskyttet blok, med et alias, der navngiver identiteten. En PEM-fil er tekstindramning defineret i RFC 7468: en base64-krop mellem BEGIN- og END-linjer, og én fil kan rumme flere blokke efter hinanden. DER er den binære kodning af de samme ASN.1-strukturer, og PEM-kroppen er bogstaveligt talt DER pakket ind i base64.

Den sidste sætning er værd at huske. Konvertering fra PEM til DER omskriver indramningen, ikke indholdet, og tilbagekonvertering giver de oprindelige bytes.

Kodning er ikke kryptering

Base64 er et transportalfabet. Det skjuler intet, og enhver kan dekode en PEM-blok i en shell. En DER-fil er binær og lige så offentlig. Ingen af egenskaberne er beskyttelse, og ingen af dem antyder, at der findes en adgangskode.

Den egentlige beskyttelse ligger i nøglematerialet. En PKCS12-pakke kan kryptere sit indhold under en nøgle afledt af en adgangskode. En privat PEM-nøgle kan krypteres med en gammel headerblok eller opbevares i PKCS#8 EncryptedPrivateKeyInfo. Et certifikat alene rummer intet hemmeligt, og derfor efterlader en eksport, der kun gav et certifikat, klienten ude af stand til at autentificere, uanset hvilket format du pakker det i.

Filendelsen er et hint, ikke en kontrakt. Filer, der ender på .cer og .crt, optræder i begge kodninger, og apparater eksporterer DER-certifikater under .pem-navne ofte nok til, at gætteri ud fra suffikset koster en eftermiddag. Læs de første bytes i stedet: en PEM-fil åbner med en BEGIN-linje, mens DER begynder med 0x30, fordi den ydre struktur er en SEQUENCE.

Hvorfor importen faktisk fejler

Klientfejlmeddelelser presser flere forskellige problemer ind i én sætning om et ugyldigt certifikat, så skil dem ad efter årsag. Den mest almindelige er en kodningsuoverensstemmelse: en klient, der parser PEM, returnerer en parsefejl på en DER-fil, og løsningen er en konvertering, ikke et nyt certifikat. Den anden er en manglende nøgle, hvor certifikatet er i orden, og identiteten ikke kan bevises. Den tredje er kæden, hvor en pakke uden sit mellemliggende certifikat ser korrekt ud i importdialogen og fejler under håndtrykket.

Krypteringsparametre forårsager en fjerde, og den ser præcis ud som en forkert adgangskode. Ældre apparater eksporterede PKCS12-filer med RC2-40 og 3DES, som OpenSSL 3 afviser, medmindre legacy-udbyderen er indlæst. Genudlæsning fra apparatet med AES-256-CBC og PBKDF2 er den holdbare løsning. At lade gamle cifre være permanent aktiveret på en klientmaskine for at imødekomme én fil er en dårlig handel.

En femte er tvetydighed. En container med to nøgler og to certifikater, eller en PEM-fil med tre CERTIFICATE-blokke, tvinger klienten til at vælge, og dens valg er ofte bare det første element. Når en tunnel kommer op med den forkerte identitet, er det normalt årsagen.

Inspicér, før du konverterer

Læs strukturen uden at udskrive hemmeligheder. openssl pkcs12 -in bundle.p12 -info -noout rapporterer krypteringsalgoritmerne og aliaserne og undertrykker nøgle- og certifikatoutput, og openssl-pkcs12-manualen dokumenterer flagene. At fjerne -noout og tilføje -nodes er til at producere filer, du vil gemme, ikke til et hurtigt kig, fordi det skriver den private nøgle i klartekst.

For et certifikat besvarer openssl x509 -in cert.pem -noout -subject -issuer -dates det, som en importdialog ikke vil besvare, og tilføjet -ext subjectAltName viser de navne, som certifikatet faktisk er gyldigt for. Er filen DER, tilføj -inform DER; det ene flag løser de fleste unable-to-load-fejl.

At matche en nøgle til et certifikat er mekanisk og værd at gøre før enhver import:

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

Identiske digests betyder, at parret hører sammen. Forskellige digests betyder, at du har den forkerte nøgle, og ingen formatkonvertering ændrer det.

Hvad formatet aldrig ændrer

Tillidsbeslutninger træffes over containeren. Klienten går kæden til en rod i sit lager, kontrollerer gyldighedsvinduet, kontrollerer udvidet nøglebrug til klientautentificering og kontrollerer på serversiden, at det navn, den ringede til, optræder i certifikatet. Ingen af disse trin læser en filendelse.

Derfor er omdøbning af en fil, indtil en fejl forsvinder, en så pålidelig måde at spilde tid på. Importen lykkes, identiteten er stadig forkert, og fejlen dukker op igen under håndtrykket, hvor meddelelsen er mindre hjælpsom. Derfor importeres en pakke eksporteret for to år siden rent og afvises stadig: udløbsdatoen rejste inde i certifikatet, ikke i filnavnet.

En rækkefølge, der undgår omarbejde

Spørg klientens dokumentation, hvilke kodninger den accepterer, og hvilken container den forventer til en klientidentitet, og se så på det, du har fået. Vil klienten have én importerbar identitet, og har du løse PEM-filer, så byg pakken én gang med en adgangskode, du kontrollerer, og behold kilderne. Vil den have PEM, så udtræk nøglen og kæden, og fjern derefter mellemfilene via den proces til håndtering af legitimationsoplysninger, som dit team allerede bruger.

Efter importen skal du verificere identiteten frem for dialogen: subjekt, udsteder, udløb og det navn, klienten vil præsentere. Et venligt navn på en liste er en etiket, ikke en verificeret identitet. Fejler tunnelen derefter, debugger du autentificering eller routing i stedet for pakning, hvilket er en meget kortere samtale.