Før du konverterer den: SSH-nøgle kontra OpenVPN-certifikat

Importen fejler med en certifikatfejl, så det oplagte træk ligner en konvertering. Det instinkt sender folk ned ad en vej, hvor filtypen ændres, og afvisningen forbliver præcis den samme. En ssh-ed25519-linje i authorized_keys og et OpenVPN-klientcertifikat er adskilte legitimationsobjekter med forskellige udstedere, forskellige kodninger og forskellige tilbagekaldelsesveje. Går du disse kontroller igennem i rækkefølge, ved du inden for et minut, om konvertering overhovedet kan hjælpe.

Hvilket objekt har du egentlig?

Der er fem ting, som folk kalder en nøgle, og kun én af dem er det, en TLS-profil vil have. En offentlig SSH-nøgle er én linje tekst med et typepræfiks og en base64-nyttelast. Et OpenSSH-certifikat er den nøgle plus en signatur, principals og valgmuligheder, produceret af ssh-keygen, der optræder som sin egen lille CA. Et X.509-certifikat er en helt anden struktur, som bærer et subjekt, et gyldighedsvindue, udvidelser og en signatur fra en certifikatmyndighed. En privat nøgle er den hemmelige halvdel, og en udstedt pakke er normalt et certifikat plus dets kæde plus den private nøgle i én fil.

Den første test koster én kommando. Ret openssl mod filen, og bed den om at parse certifikatstrukturen:

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

Hvis det fejler med en unable-to-load- eller PEM-fejl, er filen ikke et X.509-certifikat, uanset hvad du kaldte den. En omdøbning omskriver ikke ASN.1 indeni, og det gør indpakning af en offentlig nøglelinje i PEM-headertekst heller ikke.

Beder profilen overhovedet om et certifikat?

Klientcertifikater er én godkendelsesmetode blandt flere, og mange fungerende TLS-profiler beder aldrig om et. En server kan godkende brugere via et plugin, et brugernavn og en adgangskode eller en token-backend, mens den stadig kræver, at klienten verificerer serverens identitet. Hvis profilen ikke indeholder en klientcertifikatdirektiv, vil der aldrig blive efterspurgt et certifikat, og ingen konvertering får gatewayen til at efterspørge et.

Ældre konfigurationer med statisk nøgle er et tredje tilfælde. De går forud for TLS-håndtrykket og forventer en fil med en på forhånd delt hemmelighed, og derfor kan det heller ikke virke at indsætte en offentlig nøgle i det felt. Læs, hvad profilen faktisk beder om, før du beslutter, at legitimationsoplysningen er forkert.

Hvad omkodning kan og ikke kan

Private nøgler har legitime alternative beholdere. Den samme RSA- eller EC-nøgle kan skrives som traditionel PEM, som PKCS#8 eller inde i en PKCS#12-pakke, og værktøjer konverterer gerne mellem dem. Offentlige nøgler har en lignende historie: ssh-keygen kan udskrive RFC 4716-formen af en SSH-nøgle, og OpenSSH forstår også sit eget certifikatformat. Alt dette er repræsentation, og repræsentation er ikke tillid.

Det, konvertering ikke kan, er at skabe en signatur fra en certifikatmyndighed, der aldrig har set din nøgle. Et certifikat er en udstederens erklæring om, at en bestemt offentlig nøgle tilhører et bestemt subjekt til et bestemt formål. Omkodning bevarer nøglens bytes og efterlader erklæringen fraværende, så gatewayen har intet at validere mod sit tillidslager.

Det er det trin, hvor de fleste forsøg stille fejler: filen ender nu på .crt, klienten læser den uden klager, og håndtrykket afbrydes stadig, fordi modparten ikke kan bygge en kæde til en betroet udsteder.

Hvor certifikatmyndigheden kommer ind i billedet

En rigtig tilmelding starter med et nøglepar, du kontrollerer, og en certifikatsignaturanmodning med det subjekt, som operatøren forventer. Operatøren verificerer rettigheden, signerer anmodningen med CA-nøglen og returnerer det udstedte certifikat sammen med enhver mellemliggende kæde, som klienten skal fremvise. Derefter har klienten brug for det CA-certifikat, der signerede det, fordi det er det, der lader den bekræfte, at den server, den taler med, hører til samme udrulning.

Den sidste fil er let at glemme og umulig at erstatte. CA’ens signeringsnøgle selv hører aldrig til i klientkonfiguration, og ingen mængde lokal konvertering frembringer den kæde, du skulle have modtaget.

Hvad det koster dig at genbruge SSH-nøglen

Antag, at en konvertering faktisk frembragte noget acceptabelt. Genbrug af ét nøglepar til SSH-adgang og VPN-godkendelse kobler stadig to uafhængige sikkerhedsbeslutninger sammen. Fjernelse af en authorized_keys-linje stopper SSH-logins, og det gør intet ved et certifikat, som VPN-CA’en allerede har udstedt for den samme offentlige nøgle. VPN-siden tilbagekaldes via sin egen mekanisme, altså certifikatets tilbagekaldelsesliste eller operatørens tilmeldingsregistrering.

Så tjeklisten slutter med en stopbetingelse i stedet for et trick. Hvis openssl ikke vil parse filen som et certifikat, stop konverteringen og beskriv, hvad du har: SSH-nøgle, SSH-certifikat, X.509-certifikat, privat nøgle eller pakke. Hvis profilen ikke beder om et klientcertifikat, stop og spørg, hvilken godkendelsesmetode serveren forventer. Kun når begge svar peger på X.509, bliver tilmelding det næste skridt, og den samtale går meget hurtigere med det rigtige navneord i den første sætning.