Innan du konverterar den: SSH-nyckel kontra OpenVPN-certifikat

Importen misslyckas med ett certifikatfel, så det uppenbara steget ser ut som en konvertering. Den instinkten leder människor in på en väg där filändelsen ändras och avvisandet förblir exakt detsamma. En ssh-ed25519-rad i authorized_keys och ett OpenVPN-klientcertifikat är separata autentiseringsobjekt, med olika utfärdare, olika kodningar och olika återkallningsvägar. Går du igenom dessa kontroller i ordning vet du inom en minut om en konvertering kan hjälpa överhuvudtaget.

Vilket objekt har du egentligen?

Det finns fem saker som folk kallar en nyckel, och bara en av dem är vad en TLS-profil vill ha. En offentlig SSH-nyckel är en enda textrad med ett typprefix och en base64-nyttolast. Ett OpenSSH-certifikat är den nyckeln plus en signatur, principals och optioner, producerade av ssh-keygen som agerar som sin egen lilla CA. Ett X.509-certifikat är en helt annan struktur, som bär ett subjekt, ett giltighetsfönster, tillägg och en signatur från en certifikatmyndighet. En privat nyckel är den hemliga halvan, och ett utfärdat paket är oftast ett certifikat plus dess kedja plus den privata nyckeln i en enda fil.

Det första testet kostar ett kommando. Rikta openssl mot filen och be den tolka certifikatstrukturen:

openssl x509 -in client.crt -noout -subject -issuer

Om det misslyckas med ett unable-to-load- eller PEM-fel är filen inget X.509-certifikat oavsett vad du kallade den. En omdöpning skriver inte om ASN.1-innehållet, och det gör inte heller inpackning av en offentlig nyckelrad i PEM-huvudtext.

Ber profilen ens om ett certifikat?

Klientcertifikat är en autentiseringsmetod bland flera, och många fungerande TLS-profiler ber aldrig om ett. En server kan autentisera användare via ett plugin, ett användarnamn och lösenord eller en token-backend, samtidigt som den fortfarande kräver att klienten verifierar serverns identitet. Om profilen inte innehåller någon klientcertifikatdirektiv kommer inget certifikat någonsin att begäras, och ingen konvertering får gatewayen att begära ett.

Äldre konfigurationer med statisk nyckel är ett tredje fall. De föregår TLS-handskakningen och förväntar sig en fil med en i förväg delad hemlighet, vilket är anledningen till att det inte heller kan fungera att klistra in en offentlig nyckel i det fältet. Läs vad profilen faktiskt begär innan du avgör att autentiseringsuppgiften är fel.

Vad omkodning kan och inte kan göra

Privata nycklar har legitima alternativa behållare. Samma RSA- eller EC-nyckel kan skrivas som traditionell PEM, som PKCS#8 eller inuti ett PKCS#12-paket, och verktyg konverterar gärna mellan dem. Offentliga nycklar har en liknande historia: ssh-keygen kan skriva ut RFC 4716-formen av en SSH-nyckel, och OpenSSH förstår även sitt eget certifikatformat. Allt detta är representation, och representation är inte förtroende.

Det en konvertering inte kan är att skapa en signatur från en certifikatmyndighet som aldrig har sett din nyckel. Ett certifikat är ett utfärdarpåstående om att en viss offentlig nyckel tillhör ett visst subjekt för ett visst ändamål. Omkodning bevarar nyckelns byte och låter påståendet saknas, så gatewayen har ingenting att validera mot sitt förtroendelager.

Det här är steget där de flesta försök tyst misslyckas: filen slutar nu på .crt, klienten läser den utan klagomål, och handskakningen avbryts ändå eftersom motparten inte kan bygga en kedja till en betrodd utfärdare.

Där certifikatmyndigheten kommer in i bilden

En riktig registrering börjar med ett nyckelpar som du kontrollerar och en certifikatsigneringsbegäran som bär det subjekt som operatören förväntar sig. Operatören verifierar rättigheten, signerar begäran med CA-nyckeln och returnerar det utfärdade certifikatet tillsammans med eventuell mellanliggande kedja som klienten måste visa upp. Sedan behöver klienten CA-certifikatet som signerade det, eftersom det är det som låter den bekräfta att servern den talar med hör till samma driftsättning.

Den sista filen är lätt att glömma och omöjlig att ersätta. Själva CA-signeringsnyckeln hör aldrig hemma i klientkonfigurationen, och ingen mängd lokal konvertering producerar kedjan du skulle ha fått.

Vad återanvändning av SSH-nyckeln kostar dig

Anta att en konvertering faktiskt producerade något acceptabelt. Återanvändning av ett nyckelpar för både SSH-åtkomst och VPN-autentisering kopplar fortfarande samman två oberoende säkerhetsbeslut. Att ta bort en authorized_keys-post stoppar SSH-inloggningar, och det gör ingenting mot ett certifikat som VPN-CA:n redan har utfärdat för samma offentliga nyckel. VPN-sidan återkallas via sin egen mekanism, det vill säga certifikatets återkallningslista eller operatörens registreringspost.

Så checklistan slutar med ett stoppvillkor i stället för en trick. Om openssl inte tolkar filen som ett certifikat, sluta konvertera och beskriv vad du har: SSH-nyckel, SSH-certifikat, X.509-certifikat, privat nyckel eller paket. Om profilen inte ber om ett klientcertifikat, stanna och fråga vilken autentiseringsmetod servern förväntar sig. Först när båda svaren pekar på X.509 blir registreringen nästa steg, och det samtalet går mycket snabbare med rätt substantiv i den första meningen.