Prije nego što ga pretvorite: SSH ključ nasuprot OpenVPN certifikatu

Uvoz pada s greškom certifikata, pa očigledan potez izgleda kao pretvaranje. Taj instinkt vodi ljude putem na kojem se ekstenzija datoteke mijenja, a odbijanje ostaje potpuno isto. Linija ssh-ed25519 u authorized_keys i klijentski certifikat OpenVPN odvojeni su objekti vjerodajnica, s različitim izdavaocima, različitim kodiranjima i različitim putevima opoziva. Ako ove provjere prođete po redu, za minutu ćete znati može li pretvaranje uopće pomoći.

Koji objekt zapravo imate?

Postoji pet stvari koje ljudi nazivaju ključem, a samo jedna od njih je ono što TLS profil traži. SSH javni ključ je jedan red teksta s prefiksom tipa i base64 sadržajem. OpenSSH certifikat je taj ključ plus potpis, principali i opcije, koje proizvodi ssh-keygen nastupajući kao vlastiti mali CA. X.509 certifikat je posve druga struktura: nosi subjekt, prozor valjanosti, ekstenzije i potpis od certifikacijskog tijela. Privatni ključ je tajna polovina, a izdani paket obično je certifikat plus njegov lanac plus privatni ključ u jednoj datoteci.

Prvi test košta jednu komandu. Usmjerite openssl na datoteku i zamolite ga da raščlani strukturu certifikata:

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

Ako to padne s greškom nemogućnosti učitavanja ili PEM greškom, datoteka nije X.509 certifikat kako god je nazvali. Preimenovanje ne prepisuje ASN.1 unutra, a to ne čini ni umotavanje reda javnog ključa u PEM zaglavlje.

Traži li profil uopće certifikat?

Klijentski certifikati su jedna metoda autentifikacije među nekoliko, a mnogi ispravni TLS profili je nikada ne traže. Server može autentificirati korisnike putem dodatka, korisničkog imena i lozinke ili token pozadine, dok istovremeno zahtijeva od klijenta da provjeri identitet servera. Ako profil ne sadrži direktivu o klijentskom certifikatu, nijedan certifikat nikada neće biti zatražen, i nikakvo pretvaranje neće natjerati pristupnik da ga zatraži.

Starije konfiguracije sa statičkim ključem treći su slučaj. One prethode TLS rukovanju i očekuju datoteku unaprijed dijeljene tajne, zbog čega ni lijepljenje javnog ključa u to polje ne može raditi. Pročitajte šta profil zapravo traži prije nego što zaključite da vjerodajnica nije ispravna.

Šta ponovno kodiranje može i ne može

Privatni ključevi imaju legitimne alternativne spremnike. Isti RSA ili EC ključ može se zapisati kao tradicionalni PEM, kao PKCS#8 ili unutar PKCS#12 paketa, a alati će rado pretvarati između njih. Javni ključevi imaju sličnu priču: ssh-keygen može ispisati RFC 4716 oblik SSH ključa, a OpenSSH razumije i vlastiti format certifikata. Sve je to predstavljanje, a predstavljanje nije povjerenje.

Ono što pretvaranje ne može jest stvoriti potpis certifikacijskog tijela koje nikada nije vidjelo vaš ključ. Certifikat je tvrdnja izdavaoca da određeni javni ključ pripada određenom subjektu za određenu svrhu. Ponovno kodiranje čuva bajtove ključa i ostavlja tvrdnju odsutnom, pa pristupnik nema šta provjeriti prema svom spremištu povjerenja.

Ovo je korak na kojem većina pokušaja tiho propada: datoteka sada završava na .crt, klijent je čita bez prigovora, a rukovanje se ipak prekida jer druga strana ne može izgraditi lanac do pouzdanog izdavaoca.

Gdje certifikacijsko tijelo ulazi u sliku

Prava registracija počinje parom ključeva kojim upravljate i zahtjevom za potpisivanje certifikata koji nosi subjekt koji operater očekuje. Operater provjeri pravo, potpiše zahtjev CA ključem i vrati izdani certifikat zajedno s bilo kojim posredničkim lancem koji klijent mora predstaviti. Klijentu je tada potreban CA certifikat koji ga je potpisao, jer upravo on omogućava potvrdu da server s kojim razgovara pripada istoj implementaciji.

Tu posljednju datoteku lako je zaboraviti i nemoguće zamijeniti. Sam ključ za potpisivanje CA nikada ne pripada u klijentsku konfiguraciju, i nikakva lokalna konverzija ne proizvodi lanac koji je trebalo da dobijete.

Šta vas košta ponovno korištenje SSH ključa

Pretpostavite da je pretvaranje ipak proizvelo nešto prihvatljivo. Ponovno korištenje jednog para ključeva za SSH pristup i VPN autentifikaciju i dalje spaja dvije nezavisne sigurnosne odluke. Uklanjanje unosa iz authorized_keys zaustavlja SSH prijave i ne čini ništa certifikatu koji je VPN CA već izdao za isti javni ključ. VPN strana se opoziva vlastitim mehanizmom, što znači lista opozvanih certifikata ili operaterov evidencijski zapis.

Zato kontrolna lista završava uvjetom zaustavljanja, a ne trikom. Ako openssl ne raščlani datoteku kao certifikat, zaustavite pretvaranje i opišite šta imate: SSH ključ, SSH certifikat, X.509 certifikat, privatni ključ ili paket. Ako profil ne traži klijentski certifikat, zaustavite se i pitajte koju metodu autentifikacije server očekuje. Samo kada oba odgovora pokazuju na X.509, registracija postaje sljedeći korak, a taj razgovor ide mnogo brže s pravom imenicom u prvoj rečenici.