Mielőtt átalakítaná: SSH-kulcs vagy OpenVPN-tanúsítvány

Az importálás tanúsítványhibával hiúsul meg, ezért a kézenfekvő lépés átalakításnak tűnik. Ez az ösztön olyan útra viszi az embereket, ahol a fájlkiterjesztés megváltozik, az elutasítás pedig pontosan ugyanaz marad. Az authorized_keys egy ssh-ed25519 sora és egy OpenVPN-kliens-tanúsítvány külön hitelesítő objektumok, különböző kibocsátókkal, különböző kódolásokkal és különböző visszavonási utakkal. Ha ezeket az ellenőrzéseket sorrendben végigveszi, egy percen belül megtudja, segíthet-e egyáltalán az átalakítás.

Melyik objektum van valójában a birtokában?

Öt dolgot neveznek az emberek kulcsnak, és csak az egyik az, amit egy TLS-profil kér. Az SSH nyilvános kulcs egyetlen szövegsor típuselőtaggal és base64-terheléssel. Az OpenSSH-tanúsítvány ez a kulcs plusz aláírás, principals és opciók, amelyeket a ssh-keygen a saját kis CA-jaként működve állít elő. Az X.509-tanúsítvány teljesen más szerkezet: alanyt, érvényességi ablakot, kiterjesztéseket és egy tanúsító hatóság aláírását hordozza. A magánkulcs a titkos fele, a kiadott csomag pedig általában egy tanúsítvány plusz a lánca plusz a magánkulcs egyetlen fájlban.

Az első próba egyetlen parancsba kerül. Irányítsa az openssl-t a fájlra, és kérje meg a tanúsítvány szerkezetének elemzésére:

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

Ha ez unable-to-load vagy PEM hibával meghiúsul, a fájl nem X.509-tanúsítvány, akárhogy is nevezte el. Az átnevezés nem írja újra a benne lévő ASN.1-et, és a nyilvános kulcs sorának PEM-fejlécszövegbe csomagolása sem teszi ezt.

Kér egyáltalán tanúsítványt a profil?

Az ügyféltanúsítványok egy hitelesítési módszer a több közül, és sok működő TLS-profil soha nem kér ilyet. A kiszolgáló hitelesítheti a felhasználókat bővítményen, felhasználónév és jelszó páron vagy token-háttéren keresztül, miközben továbbra is megköveteli, hogy az ügyfél ellenőrizze a kiszolgáló identitását. Ha a profil nem tartalmaz ügyféltanúsítvány-direktívát, soha nem kérnek tanúsítványt, és semmilyen átalakítás nem veszi rá az átjárót, hogy kérjen egyet.

A régebbi statikus kulcsos konfigurációk harmadik eset. A TLS-kézfogás előttiek, és előre megosztott titokfájlt várnak, ezért a nyilvános kulcs beillesztése abba a mezőbe sem működhet. Olvassa el, mit kér valójában a profil, mielőtt eldönti, hogy a hitelesítő adat hibás.

Mit tud és mit nem tud az újrakódolás

A magánkulcsoknak valóban vannak legitim alternatív tárolóik. Ugyanaz az RSA- vagy EC-kulcs írható hagyományos PEM-ként, PKCS#8-ként vagy PKCS#12-csomagon belül, és az eszközök szívesen átalakítanak közöttük. A nyilvános kulcsok története hasonló: a ssh-keygen ki tudja adni az SSH-kulcs RFC 4716-os formáját, és az OpenSSH a saját tanúsítványformátumát is érti. Mindez reprezentáció, és a reprezentáció nem bizalom.

Amit az átalakítás nem tud, az az, hogy olyan tanúsító hatóságtól hozzon létre aláírást, amely soha nem látta a kulcsát. A tanúsítvány egy kibocsátó állítása arról, hogy egy adott nyilvános kulcs egy adott alanyhoz tartozik egy adott célra. Az újrakódolás megőrzi a kulcs bájtjait, és az állítást hiányzóként hagyja, így az átjárónak nincs mit érvényesítenie a bizalmi tárolójával szemben.

Ez az a lépés, ahol a legtöbb kísérlet csendben elbukik: a fájl most .crt-ra végződik, az ügyfél panasz nélkül olvassa, a kézfogás mégis megszakad, mert a partner nem tud láncot építeni egy megbízható kibocsátóig.

Hol lép be a képbe a tanúsító hatóság

Az igazi regisztráció egy Ön által ellenőrzött kulcspárral és egy tanúsítvány-aláírási kérelemmel kezdődik, amely az üzemeltető által várt alanyt hordozza. Az üzemeltető ellenőrzi a jogosultságot, aláírja a kérelmet a CA kulcsával, és visszaadja a kiadott tanúsítványt bármely köztes lánccal együtt, amelyet az ügyfélnek be kell mutatnia. Ezután az ügyfélnek szüksége van az őt aláíró CA-tanúsítványra, mert ez teszi lehetővé annak megerősítését, hogy a kiszolgáló, amellyel beszél, ugyanahhoz a telepítéshez tartozik.

Ezt az utolsó fájlt könnyű elfelejteni, és lehetetlen helyettesíteni. A CA aláírókulcsa soha nem tartozik az ügyfélkonfigurációba, és semmilyen helyi átalakítás nem állítja elő azt a láncot, amelyet kapnia kellett volna.

Mibe kerül az SSH-kulcs újrafelhasználása

Tegyük fel, hogy egy átalakítás mégis valami elfogadhatót eredményezett. Egyetlen kulcspár újrafelhasználása az SSH-hozzáféréshez és a VPN-hitelesítéshez továbbra is két független biztonsági döntést kapcsol össze. Egy authorized_keys-bejegyzés eltávolítása leállítja az SSH-bejelentkezéseket, és semmit sem tesz azzal a tanúsítvánnyal, amelyet a VPN CA már kiadott ugyanarra a nyilvános kulcsra. A VPN-oldal a saját mechanizmusán keresztül vonódik vissza, azaz a tanúsítvány-visszavonási lista vagy az üzemeltető regisztrációs nyilvántartása révén.

Az ellenőrzőlista tehát leállási feltétellel zárul, nem trükkel. Ha az openssl nem elemzi a fájlt tanúsítványként, állítsa le az átalakítást, és írja le, mi van Önnél: SSH-kulcs, SSH-tanúsítvány, X.509-tanúsítvány, magánkulcs vagy csomag. Ha a profil nem kér ügyféltanúsítványt, álljon meg, és kérdezze meg, milyen hitelesítési módszert vár a kiszolgáló. Csak akkor lesz a regisztráció a következő lépés, ha mindkét válasz X.509-re mutat, és az a beszélgetés sokkal gyorsabban megy a megfelelő főnévvel az első mondatban.