Ennen kuin muunnat sen: SSH-avain vai OpenVPN-varmenne

Tuonti epäonnistuu varmennevirheeseen, joten ilmeinen liike näyttää muunnokselta. Tämä vaisto vie ihmiset polulle, jolla tiedostopääte vaihtuu ja hylkäys pysyy täsmälleen samana. Rivi ssh-ed25519 tiedostossa authorized_keys ja OpenVPN-asiakasvarmenne ovat erillisiä valtuutusobjekteja, joilla on eri myöntäjät, eri koodaukset ja eri peruutuspolut. Kun käyt nämä tarkistukset läpi järjestyksessä, tiedät minuutissa, voiko muunnos ylipäätään auttaa.

Mikä objekti sinulla oikeastaan on?

On viisi asiaa, joita ihmiset kutsuvat avaimeksi, ja vain yksi niistä on se, mitä TLS-profiili haluaa. SSH-julkinen avain on yksi tekstirivi, jossa on tyyppietuliite ja base64-hyötykuorma. OpenSSH-varmenne on tuo avain sekä allekirjoitus, principals ja asetukset, jotka ssh-keygen tuottaa toimiessaan omana pienenä CA-naan. X.509-varmenne on täysin erilainen rakenne: se kantaa subjektin, voimassaoloikkunan, laajennukset ja varmenteenmyöntäjän allekirjoituksen. Yksityinen avain on salainen puolisko, ja myönnetty paketti on yleensä varmenne sekä sen ketju sekä yksityinen avain yhdessä tiedostossa.

Ensimmäinen testi maksaa yhden komennon. Kohdista openssl tiedostoon ja pyydä sitä jäsentämään varmenteen rakenne:

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

Jos se epäonnistuu unable-to-load- tai PEM-virheeseen, tiedosto ei ole X.509-varmenne riippumatta siitä, miksi sen nimesit. Uudelleennimeäminen ei kirjoita sisällä olevaa ASN.1:tä uudelleen, eikä sitä tee myöskään julkisen avaimen rivin kääriminen PEM-otsikkotekstiin.

Pyytääkö profiili ylipäätään varmennetta?

Asiakasvarmenteet ovat yksi todennusmenetelmä useiden joukossa, ja monet toimivat TLS-profiilit eivät koskaan pyydä sellaista. Palvelin voi todentaa käyttäjiä liitännäisen, käyttäjätunnuksen ja salasanan tai token-taustajärjestelmän kautta vaatien silti, että asiakas tarkistaa palvelimen identiteetin. Jos profiilissa ei ole asiakasvarmennedirektiiviä, varmennetta ei koskaan pyydetä, eikä mikään muunnos saa yhdyskäytävää pyytämään sellaista.

Vanhemmat staattisen avaimen kokoonpanot ovat jälleen kolmas tapaus. Ne ovat peräisin ennen TLS-kättelyä ja odottavat etukäteen jaetun salaisuuden tiedostoa, minkä vuoksi julkisen avaimen liittäminen siihen kenttään ei voi sekään toimia. Lue, mitä profiili todella pyytää, ennen kuin päätät, että valtuutus on väärä.

Mitä uudelleenkoodaus voi tehdä ja mitä ei

Yksityisillä avaimilla on todella laillisia vaihtoehtoisia säiliöitä. Sama RSA- tai EC-avain voidaan kirjoittaa perinteisenä PEM-muotona, PKCS#8-muotona tai PKCS#12-paketin sisään, ja työkalut muuntavat niiden välillä mielellään. Julkisilla avaimilla on samanlainen tarina: ssh-keygen voi tulostaa SSH-avaimen RFC 4716 -muodossa, ja OpenSSH ymmärtää myös oman varmennemuotonsa. Kaikki tämä on esitystapaa, eikä esitystapa ole luottamusta.

Sen, mitä muunnos ei voi tehdä, on luoda allekirjoitus varmenteenmyöntäjältä, joka ei ole koskaan nähnyt avaintasi. Varmenne on myöntäjän väite, että tietty julkinen avain kuuluu tietylle subjektille tiettyä tarkoitusta varten. Uudelleenkoodaus säilyttää avaimen tavut ja jättää väitteen puuttumaan, joten yhdyskäytävällä ei ole mitään validoitavaa luottamusvarastoaan vasten.

Tämä on se vaihe, jossa useimmat yritykset epäonnistuvat hiljaa: tiedosto päättyy nyt .crt-päätteeseen, asiakas lukee sen valittamatta, ja kättely keskeytyy silti, koska vastapuoli ei pysty rakentamaan ketjua luotettuun myöntäjään.

Missä varmenteenmyöntäjä astuu kuvaan

Todellinen rekisteröinti alkaa hallitsemastasi avainparista ja varmenteen allekirjoituspyynnöstä, joka kantaa operaattorin odottaman subjektin. Operaattori varmistaa oikeuden, allekirjoittaa pyynnön CA-avaimella ja palauttaa myönnetyn varmenteen sekä mahdollisen välitetyn ketjun, joka asiakkaan on esitettävä. Sitten asiakas tarvitsee sen allekirjoittaneen CA-varmenteen, koska juuri se antaa sille mahdollisuuden vahvistaa, että palvelin, jonka kanssa se puhuu, kuuluu samaan käyttöönottoon.

Viimeinen tiedosto on helppo unohtaa ja mahdoton korvata. CA:n allekirjoitusavain itsessään ei koskaan kuulu asiakkaan kokoonpanoon, eikä mikään paikallinen muunnos tuota ketjua, joka sinun olisi pitänyt vastaanottaa.

Mitä SSH-avaimen uudelleenkäyttö maksaa sinulle

Oletetaan, että muunnos tuotti sittenkin jotain hyväksyttävää. Yhden avainparin uudelleenkäyttö sekä SSH-kirjautumiseen että VPN-todennukseen kytkee yhä kaksi riippumatonta turvallisuuspäätöstä. authorized_keys-merkinnän poistaminen pysäyttää SSH-kirjautumiset, eikä se tee mitään varmenteelle, jonka VPN-CA on jo myöntänyt samalle julkiselle avaimelle. VPN-puoli peruutetaan omalla mekanismillaan eli varmenteen peruutusluettelolla tai operaattorin rekisteröintitietueella.

Joten tarkistuslista päättyy pysäytysehtoon eikä temppuun. Jos openssl ei jäsennä tiedostoa varmenteeksi, lopeta muuntaminen ja kuvaile, mitä sinulla on: SSH-avain, SSH-varmenne, X.509-varmenne, yksityinen avain tai paketti. Jos profiili ei pyydä asiakasvarmennetta, pysähdy ja kysy, mitä todennusmenetelmää palvelin odottaa. Vasta kun molemmat vastaukset osoittavat X.509:ään, rekisteröinnistä tulee seuraava vaihe, ja se keskustelu sujuu paljon nopeammin, kun ensimmäisessä lauseessa on oikea substantiivi.