Å kopiere et VPN-sertifikat kopierer ikke nøkkelen

Gjennomgangen starter i klientens sertifikatliste, der oppføringen viser et navn, en utsteder og en utløpsdato og ingenting annet. Eksporter den, importer den på den andre enheten, og tilkoblingen avvises fordi klienten ikke kan bevise at den besitter den private nøkkelen. Filen ble kopiert i sin helhet; feilen er å forvente at et sertifikat bærer sin egen nøkkel. Les eksportdialogen før du velger format, og undersøk deretter filen du faktisk mottok.

To klikk, to svært forskjellige artefakter.

Les eksportdialogen, ikke filendelsen

En DER- eller PEM-sertifikateksport inneholder en offentlig nøkkel og de signerte identitetspåstandene, som er det en server trenger for å stole på deg og det en klient trenger for å verifisere en server. En PKCS#12-pakke er en beholder som kan holde et sertifikat, kjeden og den tilhørende private nøkkelen, beskyttet av et passord, selv om den også kan opprettes uten nøkkelen.

PEM er bare en tekstkoding, ikke et løfte om innholdet. Den samme endelsen kan beskrive ett enkelt sertifikat eller en fil med flere merkede blokker, og eksportvalgene avgjør hvilken.

Så det nyttige spørsmålet er aldri hvilken utvidelse du fikk, men hvilke blokker filen inneholder. En pakke eksportert uten nøkkelen er fortsatt en pakke. Kontroller innholdet framfor populariteten til formatet.

Undersøk hva du faktisk fikk

Se etter etikettene før du importerer noe, og les deretter sertifikatfeltene for å bekrefte hvilken identitet du holder. Kjør kontrollene på filen som faktisk skal importeres. Gjenta dem etter enhver ny eksport, fordi valgene 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 bare en sertifikatblokk er et offentlig objekt og kan ikke autentisere. En nøkkelblokk uten sertifikat lar deg stå uten kjeden serveren forventer. PKCS#12-informasjonsutskriften rapporterer også om det finnes en nøkkel, noe som avgjør spørsmålet for det formatet. Den navngir også algoritmen og nøkkelstørrelsen, og den feiler helt når det ikke finnes noen nøkkel.

Lim aldri inn en fil med en privat nøkkel i en støttetråd, en sakssporer eller en chat, selv når den ser ut som sertifikatet du allerede delte. Skjermbilder av et nøkkelpanel fortjener samme forsiktighet.

Nøkkelen kan ligge et sted du ikke kan kopiere

På administrerte enheter kan den private nøkkelen ligge i operativsystemets nøkkelring, i et maskinvaretoken eller i en sikker enklave, med en policy som markerer den som ikke-eksporterbar. Sertifikatbehandleren viser da det offentlige objektet mens hemmeligheten blir liggende, og ingen eksportkommando vil gi en flyttbar kopi. Registrering via enhetsadministrasjon for mobil fungerer ofte slik av design.

Det er en kontroll, ikke en hindring å omgå. Det er ikke mulig å rekonstruere en privat nøkkel fra det offentlige sertifikatet, og ethvert verktøy som påstår det, gjør noe annet.

Registrer en ny identitet i stedet for å kopiere

Den støttede veien er vanligvis å registrere en egen identitet for den nye enheten og tilbakekalle den gamle når den fases ut, slik at hver enhet kan trekkes tilbake uavhengig. Der en eksport med nøkkelen faktisk er godkjent, behandler du filen og passordet som legitimasjon: kryptert i ro, overført over en betrodd kanal og slettet når registreringen er ferdig.

Verifiser ved å autentisere med den importerte identiteten, ikke ved å se at importen lykkes. En klient som godtar et offentlig sertifikat i lageret sitt, har ikke bevist noe om nøkkelen.

Avslutt med å bekrefte at serveren godtar den nye identiteten og at den gamle fortsatt oppfører seg som policyen forutsetter. Da avsluttes gjennomgangen med bevis, i stedet for med en fil som ser riktig ut.