Kopiering af et VPN-certifikat kopierer ikke nøglen

Gennemgangen starter ved klientens certifikatliste, hvor posten viser et navn, en udsteder og en udløbsdato og intet andet. Eksportér den, importér den på den anden enhed, og forbindelsen afvises, fordi klienten ikke kan bevise, at den besidder den private nøgle. Filen blev kopieret fuldstændigt; fejlen er at forvente, at et certifikat bærer sin egen nøgle. Læs eksportdialogen, før du vælger format, og undersøg derefter den fil, du faktisk modtog.

To klik, to meget forskellige artefakter.

Læs eksportdialogen, ikke filendelsen

En DER- eller PEM-certifikateksport indeholder en offentlig nøgle og de signerede identitetspåstande, som er det, en server har brug for for at stole på dig, og det, en klient har brug for for at verificere en server. En PKCS#12-pakke er en beholder, der kan rumme et certifikat, dets kæde og den matchende private nøgle, beskyttet af en adgangskode, selvom den også kan oprettes uden nøglen.

PEM er kun en tekstkodning, ikke et løfte om indholdet. Den samme endelse kan beskrive et enkelt certifikat eller en fil med flere mærkede blokke, og eksportindstillingerne afgør hvilken.

Så det nyttige spørgsmål er aldrig, hvilken filtype du fik, men hvilke blokke filen indeholder. En pakke eksporteret uden sin nøgle er stadig en pakke. Kontrollér indholdet i stedet for formatets popularitet.

Undersøg, hvad du faktisk fik

Se efter mærkerne, før du importerer noget, og læs derefter certifikatets felter for at bekræfte, hvilken identitet du holder på. Kør kontrollerne på den fil, der faktisk bliver importeret. Gentag dem efter enhver genudsendelse af eksporten, fordi indstillingerne kan variere.

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 eksport med kun en certifikatblok er et offentligt objekt og kan ikke godkende. En nøgleblok uden certifikat efterlader dig uden den kæde, serveren forventer. PKCS#12-informationsoutputtet rapporterer også, om der er en nøgle, hvilket afgør spørgsmålet for det format. Det angiver også algoritmen og nøglestørrelsen, og det fejler helt, når der ikke er nogen nøgle.

Indsæt aldrig en fil med en privat nøgle i en supporttråd, en sagstracker eller en chat, selv når den ligner det certifikat, du allerede har delt. Skærmbilleder af et nøglepanel fortjener samme forsigtighed.

Nøglen kan ligge et sted, du ikke kan kopiere

På administrerede enheder kan den private nøgle ligge i styresystemets nøglering, i et hardwaretoken eller i et sikkert enclave, med en politik, der markerer den som ikke-eksporterbar. Certifikatadministratoren viser så det offentlige objekt, mens hemmeligheden bliver på plads, og ingen eksportkommando vil give en flytbar kopi. Registrering via mobilenhedsstyring fungerer ofte sådan af design.

Det er en kontrol, ikke en forhindring, der skal omgås. Det er ikke muligt at rekonstruere en privat nøgle ud fra det offentlige certifikat, og ethvert værktøj, der påstår det, laver noget andet.

Tilmeld en ny identitet i stedet for at kopiere

Den understøttede vej er normalt at tilmelde en særskilt identitet til den nye enhed og tilbagekalde den gamle, når den udfases, så hver enhed kan trækkes tilbage uafhængigt. Hvor en eksport med nøglen reelt er godkendt, skal du behandle den resulterende fil og dens adgangskode som legitimationsoplysninger: krypteret i ro, overført over en betroet kanal og slettet, når tilmeldingen er færdig.

Verificér ved at godkende med den importerede identitet, ikke ved at se importen lykkes. En klient, der accepterer et offentligt certifikat i sit lager, har ikke bevist noget om nøglen.

Afslut med at bekræfte, at serveren accepterer den nye identitet, og at den gamle stadig opfører sig, som politikken tilsigter. Det afslutter gennemgangen med bevis i stedet for med en fil, der ser rigtig ud.