Výzva k zadání klíče OpenVPN po OpenSSL 3: zkontrolujte poskytovatele

Nikdo s profilem nic nedělal, a přesto stejný klient nyní při každém spuštění žádá heslo k soukromému klíči. Když tato změna přijde během několika dnů po upgradu distribuce, pravděpodobnou příčinou je právě upgrade: OpenSSL 3 přeorganizoval podporu algoritmů a klíč, který stará knihovna bez problémů četla, může být nečitelný, aniž by se změnil jediný bajt. Provádějte kontroly v pořadí, protože dvě z nich vypadají při pohledu na výzvu stejně.

První otázka je, zda je klíč šifrovaný, druhá, zda jej tento build dokáže dešifrovat. Změny konfigurace mají smysl jen tehdy, když známe obě odpovědi.

Zkontrolujte, zda je klíč šifrovaný

Přečtěte první řádek souboru a potom nechte knihovnu, ať jej zpracuje, protože název souboru nic nedokazuje. Blok PEM s označením ENCRYPTED PRIVATE KEY je šifrovaný PKCS#8 a starší RSA PRIVATE KEY blok nesoucí Proc-Type: 4,ENCRYPTED je tradiční forma; oba očekávají heslo. Nešifrovaný PRIVATE KEY blok by o něj neměl žádat vůbec. Spusťte zpracování pod účtem, který soubor vlastní, protože problém s oprávněním dává jinou a mnohem méně zajímavou chybu.

Pokud je klíč opravdu nešifrovaný a klient přesto žádá, přestaňte se dívat na kryptografii a zkontrolujte, zda profil neuvádí soubor askpass, který služba ještě dokáže přečíst.

Zkontrolujte, zda jej tento build dokáže dešifrovat

OpenSSL 3 rozdělil podporu algoritmů do poskytovatelů a sada starších šifer nyní sídlí v legacy poskytovateli, nikoli v tom výchozím. Klíč zašifrovaný jednou z těchto šifer zůstává platný, knihovna načtená bez legacy poskytovatele jej však nedokáže dekódovat. U některých klientů se to projeví jako výzva, která se opakuje, u jiných jako tvrdé selhání hned po zadání hesla.

Zpracujte stejný klíč dvakrát stejným binárním souborem: nejprve jen s výchozím poskytovatelem, potom s legacy i výchozím vyžádanými na příkazovém řádku. Pokud druhý pokus uspěje tam, kde první selhal, diagnóza stojí na důkazu, ne na načasování upgradu. Pokud oba selžou stejně, heslo je chybné nebo je soubor poškozený a žádné nastavení poskytovatele neopraví ani jedno.

Zkontrolujte nejužší dostupnou opravu

Upřednostněte změnu omezenou na klienta před systémovou. Některé buildy 2.6 přijímají volbu profilu, která pro proces daného daemona načte oba poskytovatele, proto si direktivu před spoléháním se na ni ověřte v manuálu pro vaši přesnou verzi; úprava systémového openssl.cnf místo toho ovlivní každý program OpenSSL na hostiteli. Užší nastavení se také mnohem snáze vrací zpět, jakmile je klíč znovu zakódován.

Nemažte heslo jen proto, aby výzva zmizela. Změníte tím chráněný údaj na soubor v otevřeném textu a tiše změníte riziko každé zálohy, kopie a diagnostického balíčku, ve kterém se objeví. Rozdíl, na kterém záleží, je mezi klíčem, který své heslo potřebuje, a klíčem, který tato knihovna nedokáže dekódovat.

Zkontrolujte kontext služby a poté znovu zakódujte

Jakmile lze klíč odemknout, znovu jej zašifrujte aktuálním algoritmem aby závislost zmizela. Zapište nový soubor moderní šifrou, ověřte, že se zpracuje, aktualizujte profil a starou kopii držte jen do prvního úspěšného připojení. Nikdy nedávejte heslo na příkazový řádek, kde je každý místní uživatel může přečíst ze seznamu procesů. Starý soubor odstraňte až poté, co se nový připojí z účtu služby, ne jen z vašeho shellu.

Potom zkontrolujte jednotku, která klienta skutečně spouští. Klíč čitelný ve vašem shellu může být nečitelný pro službu běžící pod jiným účtem nebo se zpevněným nastavením domovského adresáře.

Zaznamenejte nastavení poskytovatele vedle profilu a mějte u něj i test se dvěma příkazy. Když pozdější upgrade legacy poskytovatele odstraní, spusťte tento test znovu a zjistěte, zda klíč ještě potřebuje jej, nebo zda lze profil z tohoto obchvatu vyřadit.

Výzva je symptom s nejméně třemi příčinami a jen jedna z nich je chybějící heslo.