Voordat jy dit omskakel: SSH-sleutel teenoor OpenVPN-sertifikaat

Die invoer misluk met 'n sertifikaatfout, so die ooglopende stap lyk soos 'n omskakeling. Daardie instink lei mense op 'n pad waar die lêeruitbreiding verander en die afkeuring presies dieselfde bly. 'n ssh-ed25519-reël in authorized_keys en 'n OpenVPN-kliëntsertifikaat is afsonderlike geloofsbriefobjekte, met verskillende uitreikers, verskillende enkoderings en verskillende herroepingspaaie. As jy hierdie kontroles in volgorde deurgaan, weet jy binne 'n minuut of omskakeling hoegenaamd kan help.

Watter objek het jy eintlik?

Daar is vyf dinge wat mense 'n sleutel noem, en net een daarvan is wat 'n TLS-profiel wil hê. 'n SSH-openbare sleutel is 'n enkele reël teks met 'n tipevoorvoegsel en base64-lading. 'n OpenSSH-sertifikaat is daardie sleutel plus 'n handtekening, prinsipale en opsies, geproduseer deur ssh-keygen wat as sy eie klein CA optree. 'n X.509-sertifikaat is heeltemal 'n ander struktuur, wat 'n subjek, geldigheidsvenster, uitbreidings en 'n handtekening van 'n sertifikaatowerheid dra. 'n Privaatsleutel is die geheime helfte, en 'n uitgereikte bondel is gewoonlik 'n sertifikaat plus sy ketting plus die privaatsleutel in een lêer.

Die eerste toets kos een opdrag. Wys openssl na die lêer en vra dit om die sertifikaatstruktuur te ontleed:

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

As dit misluk met 'n unable-to-load- of PEM-fout, is die lêer nie 'n X.509-sertifikaat nie, maak nie saak hoe jy dit genoem het nie. 'n Hernoeming herskryf nie die ASN.1 daarbinne nie, en dit doen ook nie die inpak van 'n openbare sleutelreël in PEM-koptekste nie.

Vra die profiel hoegenaamd na 'n sertifikaat?

Kliëntsertifikate is een verifikasiemetode onder verskeie, en baie werkende TLS-profiele vra nooit een nie. 'n Bediener kan gebruikers verifieer deur 'n inprop, 'n gebruikersnaam en wagwoord, of 'n token-agterkant, terwyl dit steeds van die kliënt vereis om die bediener se identiteit te verifieer. As die profiel nie 'n kliëntsertifikaat-direktief bevat nie, sal geen sertifikaat ooit aangevra word nie, en geen omskakeling sal die poort maak om een te vra nie.

Ouer statiese-sleutelkonfigurasies is weer 'n derde geval. Hulle dateer van voor die TLS-handdruk en verwag 'n voorafgedeelde geheime lêer, en daarom kan die plak van 'n openbare sleutel in daardie veld ook nie werk nie. Lees wat die profiel werklik vra voordat jy besluit die geloofsbrief is verkeerd.

Wat herkodering kan doen en nie kan doen nie

Privaatsleutels het wel wettige alternatiewe houers. Dieselfde RSA- of EC-sleutel kan as tradisionele PEM, as PKCS#8, of binne 'n PKCS#12-bondel geskryf word, en gereedskap sal graag tussen hulle omskakel. Openbare sleutels het 'n soortgelyke verhaal: ssh-keygen kan die RFC 4716-vorm van 'n SSH-sleutel lewer, en OpenSSH verstaan ook sy eie sertifikaatformaat. Dit alles is voorstelling, en voorstelling is nie vertroue nie.

Wat omskakeling nie kan doen nie, is om 'n handtekening te skep van 'n sertifikaatowerheid wat jou sleutel nog nooit gesien het nie. 'n Sertifikaat is 'n bewering deur 'n uitreiker dat 'n bepaalde openbare sleutel aan 'n bepaalde subjek vir 'n bepaalde doel behoort. Herkodering bewaar die grepe van die sleutel en laat die bewering afwesig, so die poort het niks om teen sy vertrouenswinkel te valideer nie.

Dit is die stap waar die meeste pogings stilweg misluk: die lêer eindig nou op .crt, die kliënt lees dit sonder klag, en die handdruk staak steeds omdat die eweknie nie 'n ketting na 'n vertroude uitreiker kan bou nie.

Waar die sertifikaatowerheid in die prentjie kom

Werklike inskrywing begin met 'n sleutelpaar wat jy beheer en 'n sertifikaatondertekeningsversoek wat die subjek dra wat die operateur verwag. Die operateur verifieer geregtigheid, onderteken die versoek met die CA-sleutel, en gee die uitgereikte sertifikaat terug saam met enige intermediêre ketting wat die kliënt moet voorlê. Die kliënt het dan die CA-sertifikaat nodig wat dit onderteken het, want dit is wat hom laat bevestig dat die bediener waarmee hy praat aan dieselfde ontplooiing behoort.

Daardie laaste lêer is maklik om te vergeet en onmoontlik om te vervang. Die CA se ondertekeningsleutel self hoort nooit in kliëntkonfigurasie nie, en geen hoeveelheid plaaslike omskakeling lewer die ketting wat jy veronderstel was om te ontvang nie.

Wat dit jou kos om die SSH-sleutel te hergebruik

Veronderstel 'n omskakeling het wel iets aanvaarbaars opgelewer. Die hergebruik van een sleutelpaar vir SSH-toegang en VPN-verifikasie koppel steeds twee onafhanklike sekuriteitsbesluite. Die verwydering van 'n authorized_keys-inskrywing stop SSH-aanmeldings, en dit doen niks aan 'n sertifikaat wat die VPN-CA reeds vir dieselfde openbare sleutel uitgereik het nie. Die VPN-kant word deur sy eie meganisme herroep, wat die sertifikaatherroepingslys of die operateur se inskrywingsrekord beteken.

Dus eindig die kontrolelys met 'n stopvoorwaarde eerder as 'n truuk. As openssl nie die lêer as 'n sertifikaat sal ontleed nie, stop die omskakeling en beskryf wat jy het: SSH-sleutel, SSH-sertifikaat, X.509-sertifikaat, privaatsleutel of bondel. As die profiel nie 'n kliëntsertifikaat vra nie, stop en vra watter verifikasiemetode die bediener verwag. Net wanneer beide antwoorde na X.509 wys, word inskrywing die volgende stap, en daardie gesprek gaan baie vinniger met die regte selfstandige naamwoord in die eerste sin.