OpenVPN-kulcskérés az OpenSSL 3 után: ellenőrizze a szolgáltatót

Senki nem nyúlt a profilhoz, mégis ugyanaz a kliens most minden indításkor jelmondatot kér a személyes kulcshoz. Amikor ez a változás egy disztribúciós frissítés utáni napokban jelenik meg, a frissítés a valószínű ok: az OpenSSL 3 átszervezte az algoritmustámogatását, és egy kulcs, amelyet a régi könyvtár gond nélkül olvasott, olvashatatlanná válhat anélkül, hogy egyetlen bájt megváltozna. Végezze el az ellenőrzéseket sorrendben, mert közülük kettő azonosnak tűnik, ha csak a kérést nézi.

Az első kérdés az, hogy a kulcs titkosított-e, a második pedig az, hogy ez a build képes-e visszafejteni. A konfiguráció módosításának csak akkor van értelme, ha mindkét válasz ismert.

Ellenőrizze, hogy a kulcs titkosított-e

Olvassa el a fájl első sorát, majd hagyja, hogy a könyvtár feldolgozza, mert egy fájlnév semmit nem bizonyít. A ENCRYPTED PRIVATE KEY címkével ellátott PEM-blokk titkosított PKCS#8, a régebbi RSA PRIVATE KEY blokk pedig, amely Proc-Type: 4,ENCRYPTED hordoz, a hagyományos forma, és mindkettő jelmondatot vár. A titkosítatlan PRIVATE KEY blokknak egyáltalán nem kellene kérnie. A feldolgozást a fájl tulajdonosának fiókjával futtassa, mert az engedélyprobléma más és sokkal kevésbé érdekes hibát ad.

Ha a kulcs valóban titkosítatlan, és a kliens mégis kér, hagyja abba a kriptográfia vizsgálatát, és ellenőrizze, hogy a profil megnevez-e olyan askpass-fájlt, amelyet a szolgáltatás még olvasni tud.

Ellenőrizze, hogy ez a build vissza tudja-e fejteni

Az OpenSSL 3 szolgáltatókra osztotta az algoritmustámogatását, és egy sor régebbi titkosító most a legacy szolgáltatóban található az alapértelmezett helyett. Az egyik ilyen titkosítóval titkosított kulcs érvényes marad, de a legacy szolgáltató nélkül betöltött könyvtár nem tudja dekódolni. Egyes klienseknél ez ismétlődő kérésként jelenik meg, másoknál kemény hibaként közvetlenül a jelmondat után.

Dolgozza fel ugyanazt a kulcsot kétszer ugyanazzal a binárissal: először csak az alapértelmezett szolgáltatóval, majd legacy és alapértelmezett egyszerre kérve a parancssorban. Ha a második kísérlet ott sikerül, ahol az első elbukott, a diagnózis bizonyítékokon nyugszik, nem a frissítés időpontján. Ha mindkettő azonosan bukik el, a jelmondat hibás vagy a fájl sérült, és semmilyen szolgáltatóbeállítás nem javítja egyiket sem.

Ellenőrizze a legszűkebb elérhető javítást

A kliensre korlátozott változtatást részesítse előnyben a rendszerszintűvel szemben. Néhány 2.6-os build elfogad egy profilbeállítást, amely mindkét szolgáltatót betölti az adott daemon folyamatához, ezért a rá támaszkodás előtt ellenőrizze az irányelvet a pontos verziójához tartozó kézikönyvben; a rendszer openssl.cnf szerkesztése helyette a gazdagép minden OpenSSL-programjára hat. A szűkebb beállítást sokkal könnyebb visszavonni is, miután a kulcsot újrakódolták.

Ne törölje a jelmondatot, hogy a kérés eltűnjön. Ez egy védett hitelesítő adatot egyszerű szöveges fájllá alakít, és csendesen megváltoztatja minden biztonsági mentés, másolat és támogatási csomag kockázatát, amelyben megjelenik. A fontos különbség az, hogy az egyik kulcsnak szüksége van a jelmondatára, a másikat pedig ez a könyvtár nem tudja dekódolni.

Ellenőrizze a szolgáltatás környezetét, majd kódolja újra

Amint a kulcs feloldható, titkosítsa újra egy jelenlegi algoritmussal hogy a függőség eltűnjön. Írja meg az új fájlt modern titkosítóval, ellenőrizze, hogy feldolgozható, frissítse a profilt, és a régi másolatot csak addig tartsa meg, amíg egy kapcsolat sikerül. Soha ne tegye a jelmondatot parancssorba, ahol bármely helyi felhasználó kiolvashatja a folyamatlistából. Csak azután távolítsa el a régi fájlt, hogy az új csatlakozott a szolgáltatásfiókból, nem csupán a saját héjából.

Ezután ellenőrizze azt az egységet, amely valóban futtatja a klienst. Egy a héjában olvasható kulcs olvashatatlan lehet egy másik fiók alatt vagy megerősített sajátkönyvtár-beállítással futó szolgáltatás számára.

Jegyezze fel a szolgáltató beállítását a profil mellé, és tartsa ott a kétparancsos tesztet. Amikor egy későbbi frissítés eltávolítja a legacy szolgáltatót, futtassa újra ezt a tesztet, hogy lássa, szüksége van-e még a kulcsnak rá, vagy kivehető-e a profil ebből a kerülőmegoldásból.

A kérés tünet, amelynek legalább három oka van, és csak az egyikük a hiányzó jelmondat.