Skôr než to prevediete: SSH kľúč verzus certifikát OpenVPN
Riadok v authorized_keys, certifikát OpenSSH a certifikát X.509 sú rôzne objekty. Skontrolujte, ktorý z nich máte, skôr než čokoľvek prevediete.
Import zlyháva s chybou certifikátu, takže zjavný krok vyzerá ako prevod. Ten inštinkt vedie ľudí cestou, na ktorej sa zmení prípona súboru a odmietnutie zostane presne rovnaké. Riadok ssh-ed25519 v authorized_keys a klientsky certifikát OpenVPN sú oddelené objekty poverení s rôznymi vydavateľmi, rôznymi kódovaniami a rôznymi cestami odvolania. Keď tieto kontroly prejdete po poradí, do minúty zistíte, či prevod vôbec môže pomôcť.
Aký objekt vlastne máte?
Ľudia nazývajú kľúčom päť vecí a len jedna z nich je to, čo chce profil TLS. Verejný kľúč SSH je jeden riadok textu s prefixom typu a údajmi base64. Certifikát OpenSSH je tento kľúč plus podpis, principáli a voľby, ktoré vytvára ssh-keygen vystupujúci ako vlastná malá CA. Certifikát X.509 je úplne iná štruktúra: nesie subjekt, okno platnosti, rozšírenia a podpis od certifikačnej autority. Súkromný kľúč je tajná polovica a vydaný balík je zvyčajne certifikát plus jeho reťaz plus súkromný kľúč v jednom súbore.
Prvý test stojí jeden príkaz. Namierte openssl na súbor a požiadajte ho o rozbor štruktúry certifikátu:
openssl x509 -in client.crt -noout -subject -issuer
Ak to zlyhá s chybou nedá sa načítať alebo chybou PEM, súbor nie je certifikát X.509, nech ste ho nazvali akokoľvek. Premenovanie neprepíše ASN.1 vnútri a nezaberie ani obalenie riadku verejného kľúča do textu hlavičky PEM.
Žiada profil vôbec certifikát?
Klientske certifikáty sú jedna metóda autentizácie z viacerých a mnohé funkčné profily TLS ich nikdy nevyžadujú. Server môže autentizovať používateľov cez plugin, používateľské meno a heslo alebo tokenový backend, pričom stále vyžaduje, aby klient overil identitu servera. Ak profil neobsahuje direktívu klientskeho certifikátu, nikdy nebude vyžiadaný žiadny certifikát a žiadny prevod neprinúti bránu, aby ho vyžiadala.
Staršie konfigurácie so statickým kľúčom sú tretí prípad. Predchádzajú handshake TLS a očakávajú súbor vopred zdieľaného tajomstva, a preto ani vloženie verejného kľúča do toho poľa nemôže fungovať. Prečítajte si, čo profil skutočne žiada, skôr než rozhodnete, že poverenie je nesprávne.
Čo prekódovanie dokáže a čo nie
Súkromné kľúče majú legitímne alternatívne kontajnery. Ten istý kľúč RSA alebo EC možno zapísať ako tradičný PEM, ako PKCS#8 alebo do balíka PKCS#12 a nástroje medzi nimi rady prevádzajú. Verejné kľúče majú podobný príbeh: ssh-keygen dokáže vypísať podobu RFC 4716 kľúča SSH a OpenSSH rozumie aj vlastnému formátu certifikátu. To všetko je reprezentácia a reprezentácia nie je dôvera.
Čo prevod nevie, je vytvoriť podpis od certifikačnej autority, ktorá váš kľúč nikdy nevidela. Certifikát je tvrdenie vydavateľa, že určitý verejný kľúč patrí určitému subjektu pre určitý účel. Prekódovanie zachová bajty kľúča a tvrdenie ponechá neprítomné, takže brána nemá čo overiť proti svojmu úložisku dôvery.
Toto je krok, na ktorom väčšina pokusov potichu zlyhá: súbor teraz končí na .crt, klient ho číta bez sťažností a handshake napriek tomu zlyhá, pretože protistrana nedokáže zostaviť reťaz k dôveryhodnému vydavateľovi.
Kde do hry vstupuje certifikačná autorita
Skutočná registrácia začína párom kľúčov, ktorý ovládate, a žiadosťou o podpis certifikátu, ktorá nesie subjekt očakávaný operátorom. Operátor overí oprávnenie, podpíše žiadosť kľúčom CA a vráti vydaný certifikát spolu s akýmkoľvek sprostredkujúcim reťazom, ktorý klient musí predložiť. Klient potom potrebuje certifikát CA, ktorý ho podpísal, pretože práve ten mu umožní potvrdiť, že server, s ktorým hovorí, patrí k rovnakému nasadeniu.
Ten posledný súbor sa ľahko zabudne a nedá sa nahradiť. Samotný podpisový kľúč CA nikdy nepatrí do klientskej konfigurácie a akokoľvek veľký miestny prevod nevytvorí reťaz, ktorú ste mali dostať.
Čo vás stojí opätovné použitie SSH kľúča
Predpokladajme, že prevod predsa len vytvoril niečo prijateľné. Opätovné použitie jedného páru kľúčov pre prístup SSH aj autentizáciu VPN stále spája dve nezávislé bezpečnostné rozhodnutia. Odstránenie záznamu z authorized_keys zastaví prihlásenia SSH a certifikátu, ktorý CA VPN už pre ten istý verejný kľúč vydala, neurobí nič. Strana VPN sa odvoláva vlastným mechanizmom, teda zoznamom odvolaných certifikátov alebo registračným záznamom operátora.
Preto sa kontrolný zoznam končí zastavovacou podmienkou, nie trikom. Ak openssl súbor nerozpozná ako certifikát, prestaňte prevádzať a opíšte, čo máte: kľúč SSH, certifikát SSH, certifikát X.509, súkromný kľúč alebo balík. Ak profil klientsky certifikát nežiada, zastavte sa a spýtajte sa, akú metódu autentizácie server očakáva. Až keď obe odpovede ukazujú na X.509, stáva sa registrácia ďalším krokom, a ten rozhovor je oveľa rýchlejší so správnym podstatným menom v prvej vete.