Att kopiera ett VPN-certifikat kopierar inte nyckeln

Genomgången börjar i klientens certifikatlista, där posten visar ett namn, en utfärdare och ett utgångsdatum och inget annat. Exportera den, importera den på den andra enheten, och anslutningen nekas eftersom klienten inte kan bevisa att den har den privata nyckeln. Filen kopierades i sin helhet; felet är att förvänta sig att ett certifikat bär sin egen nyckel. Läs exportdialogen innan du väljer format och granska sedan filen du faktiskt fick.

Två klick, två mycket olika artefakter.

Läs exportdialogen, inte filändelsen

En DER- eller PEM-certifikatexport innehåller en offentlig nyckel och de signerade identitetspåståendena, vilket är det en server behöver för att lita på dig och det en klient behöver för att verifiera en server. Ett PKCS#12-paket är en behållare som kan hålla ett certifikat, dess kedja och den matchande privata nyckeln, skyddad av ett lösenord, även om det också kan skapas utan nyckeln.

PEM är bara en textkodning, inte ett löfte om innehållet. Samma ändelse kan beskriva ett enda certifikat eller en fil med flera märkta block, och exportalternativen avgör vilket.

Så den användbara frågan är aldrig vilken filändelse du fick, utan vilka block filen innehåller. Ett paket som exporterats utan sin nyckel är fortfarande ett paket. Kontrollera innehållet i stället för formatets popularitet.

Granska vad du faktiskt fick

Leta efter etiketterna innan du importerar något, och läs sedan certifikatfälten för att bekräfta vilken identitet du håller i handen. Kör kontrollerna på filen som faktiskt ska importeras. Upprepa dem efter varje ny export, eftersom alternativen kan skilja sig.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

En export med bara ett certifikatblock är ett offentligt objekt och kan inte autentisera. Ett nyckelblock utan certifikat lämnar dig utan den kedja som servern förväntar sig. PKCS#12-informationsutskriften rapporterar också om det finns en nyckel, vilket avgör frågan för det formatet. Den anger även algoritmen och nyckelstorleken, och den misslyckas helt när det inte finns någon nyckel.

Klistra aldrig in en fil med en privat nyckel i en supporttråd, en ärendehanterare eller en chatt, även när den ser ut som certifikatet du redan delade. Skärmbilder av en nyckelpanel förtjänar samma försiktighet.

Nyckeln kan ligga någonstans där du inte kan kopiera den

På hanterade enheter kan den privata nyckeln ligga i operativsystemets nyckelring, i en hårdvarutoken eller i en säker enklav, med en policy som markerar den som icke-exporterbar. Certifikathanteraren visar då det offentliga objektet medan hemligheten stannar på plats, och inget exportkommando ger en flyttbar kopia. Registrering via hantering av mobila enheter fungerar ofta just så av design.

Det är en kontroll, inte ett hinder att kringgå. Det går inte att rekonstruera en privat nyckel från det offentliga certifikatet, och varje verktyg som påstår det gör något annat.

Registrera en ny identitet i stället för att kopiera

Den stödda vägen är vanligen att registrera en egen identitet för den nya enheten och återkalla den gamla när den fasas ut, så att varje enhet kan dras tillbaka oberoende av de andra. Där en export med nyckeln verkligen är godkänd, behandla den resulterande filen och dess lösenord som inloggningsuppgifter: krypterade i vila, överförda över en betrodd kanal och borttagna när registreringen är klar.

Verifiera genom att autentisera med den importerade identiteten, inte genom att se att importen lyckas. En klient som tar emot ett offentligt certifikat i sitt lager har inte bevisat något om nyckeln.

Avsluta med att bekräfta att servern accepterar den nya identiteten och att den gamla fortfarande beter sig som policyn avser. Då avslutas genomgången med bevis, i stället för med en fil som ser korrekt ut.