PKCS12, PEM eller DER: vad en VPN-klient faktiskt behöver

I certifikatdiskussioner cirkulerar två påståenden. Det första är att .p12 är det starka alternativet och .pem det lösa; det andra att en textfil måste vara säker att skicka eftersom du kan läsa den. Ingen av dem klarar en minuts inspektion.

PKCS12, PEM och DER beskriver hur certifikatobjekt packas och kodas. De avgör inte vem motparten är, om utfärdaren är betrodd eller om filen kräver ett lösenord.

Vad klienten accepterar är en kompatibilitetsfråga. Vad filen innehåller är en identitetsfråga. Håll dem åtskilda och de flesta importfel slutar vara mystiska.

Tre behållare, en objektmodell

Börja med det du faktiskt har. Ett certifikat är ett signerat påstående om en offentlig nyckel. Den privata nyckeln är separat material som bevisar att du kontrollerar den nyckeln. En kedja är mängden utfärdare som binder ditt certifikat till en rot som klienten litar på. Alla tre finns oberoende av packningen.

En PKCS12-fil, vanligtvis .p12 eller .pfx, är en behållare definierad i RFC 7292 som kan bära en privat nyckel, ett eller flera certifikat och kedjan i ett enda lösenordsskyddat block, med ett alias som namnger identiteten. En PEM-fil är textinramning definierad i RFC 7468: en base64-kropp mellan BEGIN- och END-rader, och en fil kan innehålla flera block efter varandra. DER är den binära kodningen av samma ASN.1-strukturer, och PEM-kroppen är bokstavligen DER insvept i base64.

Den sista meningen är värd att minnas. Konvertering från PEM till DER skriver om inramningen, inte innehållet, och tillbakakonvertering ger de ursprungliga byten.

Kodning är inte kryptering

base64 är ett transportalfabet. Det döljer ingenting, och vem som helst kan avkoda ett PEM-block i ett skal. En DER-fil är binär och lika offentlig. Ingen av egenskaperna är skydd, och ingen av dem antyder att det finns ett lösenord.

Det verkliga skyddet finns i nyckelmaterialet. Ett PKCS12-paket kan kryptera sitt innehåll under en nyckel som härleds från ett lösenord. En privat PEM-nyckel kan krypteras med ett gammalt rubrikblock eller förvaras i PKCS#8 EncryptedPrivateKeyInfo. Ett certifikat ensamt håller ingenting hemligt, därför lämnar en export som bara gav ett certifikat klienten oförmögen att autentisera, vilket format du än packar det i.

Filändelsen är en ledtråd, inte ett kontrakt. Filer som slutar på .cer och .crt förekommer i båda kodningarna, och apparater exporterar DER-certifikat under .pem-namn tillräckligt ofta för att gissande på ändelsen kostar en eftermiddag. Läs de första byten i stället: en PEM-fil öppnas med en BEGIN-rad, medan DER börjar med 0x30 eftersom den yttre strukturen är en SEQUENCE.

Varför importen faktiskt misslyckas

Klientens felmeddelanden pressar ihop flera olika problem i en mening om ett ogiltigt certifikat, så skilj dem efter orsak. Det vanligaste är en kodningsavvikelse: en klient som parsar PEM returnerar ett parsningsfel på en DER-fil, och lösningen är en konvertering, inte ett nytt certifikat. Det andra är en saknad nyckel, där certifikatet är i ordning och identiteten inte kan bevisas. Det tredje är kedjan, där ett paket utan mellanliggande certifikat ser korrekt ut i importdialogen och misslyckas under handskakningen.

Krypteringsparametrar orsakar en fjärde, och den ser exakt ut som ett felaktigt lösenord. Äldre apparater exporterade PKCS12-filer med RC2-40 och 3DES, som OpenSSL 3 vägrar om inte legacy-leverantören är laddad. Att exportera om från apparaten med AES-256-CBC och PBKDF2 är den hållbara lösningen. Att låta gamla chiffer vara permanent påslagna på en klientmaskin för en enda fils skull är en dålig affär.

Den femte är tvetydighet. En behållare med två nycklar och två certifikat, eller en PEM-fil med tre CERTIFICATE-block, tvingar klienten att välja, och dess val är ofta helt enkelt det första objektet. När en tunnel kommer upp med fel identitet är det vanligtvis orsaken.

Inspektera innan du konverterar

Läs strukturen utan att skriva ut hemligheter. openssl pkcs12 -in bundle.p12 -info -noout rapporterar krypteringsalgoritmerna och aliasen och undertrycker nyckel- och certifikatutdata, och openssl-pkcs12-handboken dokumenterar flaggorna. Att ta bort -noout och lägga till -nodes är för att producera filer du tänker behålla, inte för en snabb titt, eftersom det skriver den privata nyckeln i klartext.

För ett certifikat svarar openssl x509 -in cert.pem -noout -subject -issuer -dates på det en importdialog inte svarar på, och med -ext subjectAltName tillagt visas de namn som certifikatet faktiskt är giltigt för. Är filen DER, lägg till -inform DER; den enda flaggan löser de flesta unable-to-load-fel.

Att matcha en nyckel mot ett certifikat är mekaniskt, och värt att göra före varje import:

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

Identiska sammandrag betyder att paret hör ihop. Olika sammandrag betyder att du har fel nyckel, och ingen formatkonvertering ändrar det.

Vad formatet aldrig ändrar

Förtroendebeslut fattas ovanför behållaren. Klienten går kedjan till en rot i sitt lager, kontrollerar giltighetsfönstret, kontrollerar utökad nyckelanvändning för klientautentisering och kontrollerar på serversidan att namnet den ringde finns i certifikatet. Inget av dessa steg läser en filändelse.

Därför är att byta namn på en fil tills ett fel försvinner ett så pålitligt sätt att slösa tid. Importen lyckas, identiteten är fortfarande fel, och felet återkommer under handskakningen där meddelandet är mindre hjälpsamt. Därför importeras också ett paket som exporterades för två år sedan rent och avvisas ändå: utgångsdatumet reste inuti certifikatet, inte i filnamnet.

En ordning som undviker omarbete

Fråga klientens dokumentation vilka kodningar den accepterar och vilken behållare den förväntar sig för en klientidentitet, och titta sedan på vad du fick. Vill klienten ha en enda importerbar identitet och du har lösa PEM-filer, bygg paketet en gång med ett lösenord du kontrollerar och behåll källorna. Vill den ha PEM, extrahera nyckeln och kedjan och ta sedan bort mellanfilerna via processen för hantering av inloggningsuppgifter som ditt team redan använder.

Efter importen, verifiera identiteten i stället för dialogen: subjekt, utfärdare, utgång och namnet klienten kommer att presentera. Ett vänligt namn i en lista är en etikett, inte en verifierad identitet. Om tunneln sedan misslyckas felsöker du autentisering eller routing i stället för packning, vilket är ett mycket kortare samtal.