Enne teisendamist: SSH-võti versus OpenVPN-sertifikaat

Import ebaõnnestub sertifikaadiveaga, nii et ilmne samm tundub teisendamisena. See instinkt viib inimesed teele, kus faililaiend muutub ja tagasilükkamine jääb täpselt samaks. Rida ssh-ed25519 failis authorized_keys ja OpenVPN kliendisertifikaat on eraldiseisvad volituste objektid, erinevate väljaandjate, erinevate kodeeringute ja erinevate tühistamisteedega. Nende kontrollide järjest läbimine ütleb teile minutiga, kas teisendamine saab üldse aidata.

Millist objekti te tegelikult hoiate?

On viis asja, mida inimesed võtmeks nimetavad, ja ainult üks neist on see, mida TLS-profiil tahab. SSH avalik võti on üks tekstirida tüübiprefiksi ja base64 kandega. OpenSSH-sertifikaat on see võti pluss allkiri, principals ja valikud, mille toodab ssh-keygen, tegutsedes oma väikese CA-na. X.509-sertifikaat on hoopis teine struktuur, mis kannab subjekti, kehtivusakent, laiendusi ja sertifitseerimisasutuse allkirja. Privaatvõti on salajane pool ja välja antud pakett on tavaliselt sertifikaat pluss selle ahel pluss privaatvõti ühes failis.

Esimene test maksab ühe käsu. Suunake openssl failile ja paluge tal sertifikaadi struktuuri parsida:

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

Kui see ebaõnnestub laadimise või PEM-veaga, ei ole fail X.509-sertifikaat, ükskõik kuidas te seda nimetasite. Ümbernimetamine ei kirjuta seesmist ASN.1-te ümber, ja seda ei tee ka avaliku võtme rea mähkimine PEM-päise tekstiks.

Kas profiil üldse küsib sertifikaati?

Kliendisertifikaadid on üks autentimismeetod paljude seas ja paljud töötavad TLS-profiilid ei küsi kunagi ühtegi. Server saab autentida kasutajaid pistikprogrammi, kasutajanime ja parooli või tokeni-tausta kaudu, nõudes samal ajal siiski, et klient kontrolliks serveri identiteeti. Kui profiil ei sisalda kliendisertifikaadi direktiivi, ei küsita kunagi ühtegi sertifikaati, ja ükski teisendamine ei pane lüüsi seda küsima.

Vanemad staatilise võtmega konfiguratsioonid on jälle kolmas juhtum. Need pärinevad enne TLS-käepigistust ja ootavad eelnevalt jagatud saladuse faili, mistõttu ei saa ka avaliku võtme kleepimine sellesse välja toimida. Lugege, mida profiil tegelikult küsib, enne kui otsustate, et volitus on vale.

Mida ümberkodeerimine suudab ja ei suuda

Privaatvõtmetel on tõesti seaduslikud alternatiivsed konteinerid. Sama RSA- või EC-võtme saab kirjutada traditsioonilise PEM-ina, PKCS#8-na või PKCS#12-paketi sees, ja tööriistad teisendavad nende vahel hea meelega. Avalikel võtmetel on sarnane lugu: ssh-keygen saab väljastada SSH-võtme RFC 4716 kuju ja OpenSSH mõistab ka omaenda sertifikaadivormingut. Kõik see on esitus ja esitus ei ole usaldus.

Mida teisendamine ei suuda, on luua allkiri sertifitseerimisasutuselt, kes pole teie võtit kunagi näinud. Sertifikaat on väljaandja väide, et kindel avalik võti kuulub kindlale subjektile kindlal eesmärgil. Ümberkodeerimine säilitab võtme baidid ja jätab väite puuduma, nii et lüüsil pole oma usaldushoidla vastu midagi valideerida.

See on samm, kus enamik katseid vaikselt läbi kukub: fail lõpeb nüüd .crt-ga, klient loeb seda nurisemata, ja käepigistus katkeb ikkagi, sest vastaspool ei suuda ehitada ahelat usaldusväärse väljaandjani.

Kus sertifitseerimisasutus mängu tuleb

Tõeline registreerimine algab võtmepaarist, mida te kontrollite, ja sertifikaadi allkirjastamise taotlusest, mis kannab operaatori oodatavat subjekti. Operaator kontrollib õigust, allkirjastab taotluse CA-võtmega ja tagastab välja antud sertifikaadi koos mis tahes vaheahelaga, mille klient peab esitama. Seejärel vajab klient CA-sertifikaati, mis selle allkirjastas, sest just see võimaldab tal kinnitada, et server, kellega ta räägib, kuulub samasse juurutusse.

Seda viimast faili on lihtne unustada ja võimatu asendada. CA allkirjastamisvõti ise ei kuulu kunagi kliendi konfiguratsiooni, ja ükski kohalik teisendus ei tooda ahelat, mille pidite saama.

Mida SSH-võtme korduskasutus teile maksab

Oletame, et teisendamine andis ikkagi midagi vastuvõetavat. Ühe võtmepaari korduskasutamine nii SSH juurdepääsuks kui ka VPN-autentimiseks seob endiselt kaks sõltumatut turvaküsimust. authorized_keys-i kirje eemaldamine peatab SSH-sisselogimised ja ei tee midagi sertifikaadile, mille VPN-CA on sama avaliku võtme jaoks juba välja andnud. VPN-pool tühistatakse oma mehhanismi kaudu, see tähendab sertifikaadi tühistamisnimekirja või operaatori registreerimiskirje kaudu.

Nii et kontrollnimekiri lõpeb peatumistingimusega, mitte nipiga. Kui openssl ei parsi faili sertifikaadina, lõpetage teisendamine ja kirjeldage, mis teil on: SSH-võti, SSH-sertifikaat, X.509-sertifikaat, privaatvõti või pakett. Kui profiil ei küsi kliendisertifikaati, peatuge ja küsige, millist autentimismeetodit server ootab. Alles siis, kui mõlemad vastused osutavad X.509-le, saab registreerimisest järgmine samm, ja see vestlus läheb palju kiiremini, kui esimeses lauses on õige nimisõna.