Antaŭ ol konverti ĝin: SSH-ŝlosilo kontraŭ OpenVPN-atestilo

La importo malsukcesas kun atestila eraro, do la evidenta movo aspektas kiel konverto. Tiu instinkto kondukas homojn laŭ vojo, kie la dosiera etendo ŝanĝiĝas kaj la rifuzo restas precize la sama. Linio ssh-ed25519 en authorized_keys kaj klienta atestilo de OpenVPN estas apartaj legitimaj objektoj, kun malsamaj eldonintoj, malsamaj kodigoj kaj malsamaj revokaj vojoj. Trapasi ĉi tiujn kontrolojn laŭorde diras al vi en unu minuto, ĉu konverto povas entute helpi.

Kiun objekton vi fakte tenas?

Estas kvin aferoj, kiujn homoj nomas ŝlosilo, kaj nur unu el ili estas tio, kion postulas TLS-profila. Publika SSH-ŝlosilo estas unu linio da teksto kun tipa prefikso kaj base64-ŝarĝo. OpenSSH-atestilo estas tiu ŝlosilo plus subskribo, principals kaj opcioj, produktitaj de ssh-keygen aganta kiel sia propra malgranda CA. X.509-atestilo estas tute alia strukturo: ĝi portas subjekton, validecan fenestron, etendojn kaj subskribon de atestinstanco. Privata ŝlosilo estas la sekreta duono, kaj eldonita pakaĵo kutime estas atestilo plus ĝia ĉeno plus la privata ŝlosilo en unu dosiero.

La unua testo kostas unu komandon. Direktu openssl al la dosiero kaj petu ĝin analizi la atestilan strukturon:

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

Se tio malsukcesas kun eraro unable-to-load aŭ PEM, la dosiero ne estas X.509-atestilo, kiel ajn vi nomis ĝin. Renomigo ne reskribas la ASN.1 interne, kaj same ne faras volvado de publika ŝlosila linio en PEM-kapa teksto.

Ĉu la profilo entute petas atestilon?

Klientaj atestiloj estas unu aŭtentiga metodo inter pluraj, kaj multaj funkciantaj TLS-profiloj neniam petas unu. Servilo povas aŭtentigi uzantojn per kromaĵo, uzantnomo kaj pasvorto, aŭ ĵetona servilo, dum ĝi ankoraŭ postulas, ke la kliento kontrolu la identecon de la servilo. Se la profilo ne portas direktivon pri klienta atestilo, neniu atestilo iam estos petata, kaj neniu konverto igos la enirejon peti unu.

Pli malnovaj agordoj kun statika ŝlosilo estas tria kazo. Ili antaŭas la TLS-manpremon kaj atendas dosieron de antaŭe kunhavigita sekreto, kio klarigas, kial ankaŭ aliĝo de publika ŝlosilo en tiu kampo ne povas funkcii. Legu, kion la profilo fakte petas, antaŭ ol decidi, ke la legitimilo estas malĝusta.

Kion rekodigo povas kaj ne povas fari

Privataj ŝlosiloj ja havas legitimajn alternativajn ujojn. La sama RSA aŭ EC-ŝlosilo povas esti skribita kiel tradicia PEM, kiel PKCS#8, aŭ ene de PKCS#12-pakaĵo, kaj iloj volonte konvertas inter ili. Publikaj ŝlosiloj havas similan historion: ssh-keygen povas eligi la formon RFC 4716 de SSH-ŝlosilo, kaj OpenSSH ankaŭ komprenas sian propran atestilan formaton. Ĉio tio estas prezento, kaj prezento ne estas fido.

Kion konverto ne povas, estas krei subskribon de atestinstanco, kiu neniam vidis vian ŝlosilon. Atestilo estas aserto de eldoninto, ke difinita publika ŝlosilo apartenas al difinita subjekto por difinita celo. Rekodigo konservas la bajtojn de la ŝlosilo kaj lasas la aserton foresta, do la enirejo havas nenion por validigi kontraŭ sia fida konservejo.

Ĉi tio estas la paŝo, kie plej multaj provoj silente malsukcesas: la dosiero nun finiĝas per .crt, la kliento legas ĝin sen plendo, kaj la manpremo tamen ĉesas ĉar la samtavolano ne povas konstrui ĉenon al fidinda eldoninto.

Kie la atestinstanco eniras la bildon

Reala enskribiĝo komenciĝas per ŝlosilparo, kiun vi kontrolas, kaj atestila subskriba peto, kiu portas la subjekton atendatan de la funkciigisto. La funkciigisto kontrolas rajton, subskribas la peton per la CA-ŝlosilo, kaj redonas la eldonitan atestilon kune kun ajna meza ĉeno, kiun la kliento devas prezenti. Poste la kliento bezonas la CA-atestilon, kiu subskribis ĝin, ĉar ĝi estas tio, kio ebligas konfirmi, ke la servilo, kun kiu ĝi parolas, apartenas al la sama deplojo.

Tiu lasta dosiero facile forgesiĝas kaj neeble anstataŭiĝas. La subskriba ŝlosilo de la CA mem neniam apartenas al la klienta agordo, kaj nenia kvanto da loka konverto produktas la ĉenon, kiun vi devus ricevi.

Kion kostas al vi reuzi la SSH-ŝlosilon

Supozu, ke konverto ja produktis ion akcepteblan. Reuzi unu ŝlosilparon por SSH-aliro kaj VPN-aŭtentigo ankoraŭ kunligas du sendependajn sekurecajn decidojn. Forigo de authorized_keys-ero haltigas SSH-enirojn, kaj ĝi faras nenion al atestilo, kiun la VPN-CA jam eldonis por la sama publika ŝlosilo. La VPN-flanko revokiĝas per sia propra mekanismo, tio estas la atestila revoklisto aŭ la enskribiĝa registro de la funkciigisto.

Do la kontrolkonsiloj finiĝas per halta kondiĉo anstataŭ per artifiko. Se openssl ne analizos la dosieron kiel atestilon, haltigu la konvertadon kaj priskribu, kion vi havas: SSH-ŝlosilo, SSH-atestilo, X.509-atestilo, privata ŝlosilo aŭ pakaĵo. Se la profilo ne petas klientan atestilon, haltu kaj demandu, kiun aŭtentigan metodon la servilo atendas. Nur kiam ambaŭ respondoj montras al X.509, enskribiĝo fariĝas la sekva paŝo, kaj tiu konversacio iras multe pli rapide kun la ĝusta substantivo en la unua frazo.