Før du konverterer den: SSH-nøkkel kontra OpenVPN-sertifikat

Importen feiler med en sertifikatfeil, så det opplagte trekket ser ut som en konvertering. Den instinkten sender folk ned en vei der filtypen endres og avvisningen blir nøyaktig den samme. En ssh-ed25519-linje i authorized_keys og et OpenVPN-klientsertifikat er atskilte legitimasjonsobjekter, med forskjellige utstedere, forskjellige kodinger og forskjellige tilbakekallingsveier. Går du gjennom disse kontrollene i rekkefølge, vet du innen ett minutt om en konvertering kan hjelpe i det hele tatt.

Hvilket objekt har du egentlig?

Det er fem ting folk kaller en nøkkel, og bare én av dem er det en TLS-profil vil ha. En offentlig SSH-nøkkel er én tekstlinje med et typeprefiks og en base64-nyttelast. Et OpenSSH-sertifikat er den nøkkelen pluss en signatur, principals og opsjoner, produsert av ssh-keygen som opptrer som sin egen lille CA. Et X.509-sertifikat er en helt annen struktur, som bærer et subjekt, et gyldighetsvindu, utvidelser og en signatur fra en sertifikatmyndighet. En privat nøkkel er den hemmelige halvdelen, og en utstedt pakke er vanligvis et sertifikat pluss kjeden pluss den private nøkkelen i én fil.

Den første testen koster én kommando. Rett openssl mot filen og be den tolke sertifikatstrukturen:

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

Hvis det feiler med en unable-to-load- eller PEM-feil, er filen ikke et X.509-sertifikat uansett hva du kalte den. En omdøping skriver ikke om ASN.1-innholdet, og det gjør heller ikke innpakking av en offentlig nøkkellinje i PEM-topptekst.

Ber profilen om et sertifikat i det hele tatt?

Klientsertifikater er én autentiseringsmetode blant flere, og mange fungerende TLS-profiler ber aldri om ett. En server kan autentisere brukere via en plugin, et brukernavn og passord eller en token-backend, mens den fortsatt krever at klienten verifiserer serverens identitet. Hvis profilen ikke inneholder et klientsertifikatdirektiv, vil det aldri bli bedt om et sertifikat, og ingen konvertering får gatewayen til å be om ett.

Eldre konfigurasjoner med statisk nøkkel er et tredje tilfelle. De går forut for TLS-håndtrykket og forventer en fil med en forhåndsdelt hemmelighet, og derfor kan det heller ikke virke å lime inn en offentlig nøkkel i det feltet. Les hva profilen faktisk ber om før du konkluderer med at legitimasjonen er feil.

Hva omkoding kan og ikke kan gjøre

Private nøkler har legitime alternative beholdere. Den samme RSA- eller EC-nøkkelen kan skrives som tradisjonell PEM, som PKCS#8 eller inne i en PKCS#12-pakke, og verktøy konverterer gjerne mellom dem. Offentlige nøkler har en lignende historie: ssh-keygen kan skrive ut RFC 4716-formen av en SSH-nøkkel, og OpenSSH forstår også sitt eget sertifikatformat. Alt dette er representasjon, og representasjon er ikke tillit.

Det en konvertering ikke kan, er å lage en signatur fra en sertifikatmyndighet som aldri har sett nøkkelen din. Et sertifikat er en utstederpåstand om at en bestemt offentlig nøkkel tilhører et bestemt subjekt for et bestemt formål. Omkoding bevarer nøkkelens bytes og lar påstanden mangle, så gatewayen har ingenting å validere mot sitt tillitslager.

Dette er trinnet der de fleste forsøk stille feiler: filen ender nå på .crt, klienten leser den uten klager, og håndtrykket avbrytes likevel fordi motparten ikke kan bygge en kjede til en klarert utsteder.

Hvor sertifikatmyndigheten kommer inn i bildet

En ekte registrering starter med et nøkkelpar du kontrollerer og en sertifikatsignaturforespørsel som bærer subjektet operatøren forventer. Operatøren verifiserer rettigheten, signerer forespørselen med CA-nøkkelen og returnerer det utstedte sertifikatet sammen med enhver mellomliggende kjede klienten må legge frem. Deretter trenger klienten CA-sertifikatet som signerte det, fordi det er det som lar den bekrefte at serveren den snakker med hører til samme utrulling.

Den siste filen er lett å glemme og umulig å erstatte. Selve CA-signeringsnøkkelen hører aldri hjemme i klientkonfigurasjonen, og ingen mengde lokal konvertering produserer kjeden du skulle ha mottatt.

Hva gjenbruk av SSH-nøkkelen koster deg

Anta at en konvertering faktisk produserte noe akseptabelt. Gjenbruk av ett nøkkelpar til både SSH-tilgang og VPN-autentisering kobler fortsatt sammen to uavhengige sikkerhetsbeslutninger. Fjerning av en authorized_keys-oppføring stopper SSH-innlogginger, og det gjør ingenting med et sertifikat som VPN-CA-en allerede har utstedt for den samme offentlige nøkkelen. VPN-siden tilbakekalles via sin egen mekanisme, altså sertifikatets tilbakekallingsliste eller operatørens registreringsoppføring.

Så sjekklisten ender med en stoppbetingelse i stedet for et triks. Hvis openssl ikke tolker filen som et sertifikat, stopp konverteringen og beskriv hva du har: SSH-nøkkel, SSH-sertifikat, X.509-sertifikat, privat nøkkel eller pakke. Hvis profilen ikke ber om et klientsertifikat, stopp og spør hvilken autentiseringsmetode serveren forventer. Bare når begge svarene peker på X.509, blir registreringen neste trinn, og den samtalen går mye raskere med det riktige substantivet i den første setningen.