Dva adresáře, které v návodu vypadají podobně, dělají úplně jinou práci. Jeden drží certifikační autoritu: její soukromý klíč, počítadlo sériových čísel a záznam o všem, co podepsala. Druhý drží to, co daemon potřebuje ke spuštění a obsluze klientů. Umístit oba na stejný host pod stejným účtem je pohodlné na jedno odpoledne a drahé po zbytek života nasazení, protože daemon pak běží vedle jediného klíče, který dokáže vyrobit jakoukoli identitu, jakou si přeje.

Co pracovní prostor CA obsahuje

Adresář PKI je stav vydavatele, nikoli konfigurace. Obsahuje soukromý klíč a certifikát CA, soubor se sériovým číslem, index vydaných certifikátů a materiál pro jednotlivé identity, který z nich byl vytvořen.

Podepsání žádosti tento stav mění, a proto pracovní prostor patří účtu spravovanému administrátorem na hostu, kde služba VPN neběží. Kdokoli, kdo může číst soukromý klíč CA, může vydat certifikát, kterému bude server důvěřovat, takže ochrana klíče je celý model důvěry v jednom souboru. Zkopírovat ho na druhé místo, abychom ušetřili krok, vytváří druhou věc k ochraně a druhou věc k zapomenutí. Každý podpis také zvyšuje sériové číslo a připojuje záznam do indexu, a proto je pracovní prostor jednou kopií stavu, nikoli složkou souborů.

Veřejný certifikát CA je jiný. Je určen k distribuci a klienti i servery jej používají k vzájemnému ověření.

Co daemon čte při spuštění

Běžící server spotřebovává malou sadu: vlastní certifikát, vlastní soukromý klíč, certifikát CA pro ověřování protějšků a jakýkoli klíčový materiál, který jeho zvolený režim vyžaduje. Tyto cesty čte při startu a znovu při opětovném načtení.

Vlastnictví se musí vyhodnocovat vůči jednotce, která skutečně startuje, ne vůči interaktivnímu root shellu. Deklarované sandboxování může část souborového systému učinit pouze pro čtení nebo neviditelnou, i když ruční test jako root uspěje.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

Ten třetí řádek lidé přeskakují. Ptá se vlastního účtu daemonu, zda může klíč číst, a to je jediná verze otázky, která po odebrání privilegií záleží. Nulový návratový kód jako root neříká nic o tom, co se stane po odebrání.

Obě cesty selhání stojí za to oddělit, než změníte jakékoli oprávnění. Selhání podpisu ukazuje na adresář PKI, oprávnění prohledávat jeho nadřazené adresáře a účet, který spouští vydavatele. Selhání startu ukazuje na jednotku, její pracovní adresář a cesty uvedené v konfiguraci serveru. Zpřístupnění celého stromu všem neopraví ani jedno z nich a odstraní hranici, na které obě závisí.

Proč kopírování klíče CA na server později selže

Kopie obvykle začíná jako ladicí krok: někdo chce obnovit klienta na hostu VPN, takže klíč CA skončí v /etc/openvpn a obnova funguje. Okamžitý úkol uspěje a hranice je pryč.

Pak se server zálohuje a podpisová autorita se připojí k zálohám. Snímek, diagnostický balíček nebo kopie konfiguračního adresáře nyní nese schopnost vydávat důvěryhodné identity po dobu platnosti CA. Kdokoli tu kopii má, může vyrobit certifikát pro jakékoli jméno, které server přijme, včetně jmen, která nebyla nikdy vydána. Jediný záznam o tomto vydání je ten, který se rozhodnou uchovat.

Zotavení z tohoto stavu není otázkou smazání souboru. Musíte rozhodnout, zda byl klíč vystaven, pokud ano, rotovat CA, a redistribuovat důvěru všem protějškům. Oddělený pracovní prostor celé konverzaci předchází.

Účty, adresáře, zálohy

Dejte vydavateli vlastní účet a domovský adresář, mimo host VPN, kde je to praktické. Dejte daemonu jiný účet s přístupem pro čtení k nasazenému materiálu a bez přístupu pro zápis k čemukoli, co vydává certifikáty. Nasaďte kopírováním veřejných certifikátů ven a nikdy stahováním soukromého stavu vydavatele dovnitř. Zálohujte obě role odděleně, protože jejich citlivost a jejich scénáře obnovy se liší.

Po odvolání aktualizujte soubor CRL, který uvádí konfigurace serveru, a poté službu znovu načtěte, aby jej nová připojení přečetla. Dokumentace Easy-RSA pokrývá uspořádání pracovního prostoru a postup podepisování; pravidla vlastnictví kolem něj zůstávají rozhodnutím o vašem hostu. Ověřte, co služba načetla, pomocí openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate místo abyste předpokládali, že to opětovné načtení převzalo.

Test, který dokazuje oddělení

Ověřte negativní případ, ne jen ten funkční. Podepište certifikát z účtu vydavatele podle návrhu a poté potvrďte, že stejný účet nemůže spustit službu ani přečíst soukromý klíč serveru. Poté potvrďte, že účet daemonu nemůže přečíst soukromý klíč CA.

Tyto tři kontroly trvají několik minut a přežijí změny personálu, protože jsou tvrzeními o oprávněních, nikoli o zvyku. Zapište výsledek s cestami a účty, které pokryl, plus datum, kdy jste je provedli. Další člověk, který toto nasazení zdědí, si jinak hranici znovu odvodí z návodu, který ji nikdy neměl. Datovaný záznam je také to, díky čemu další revize trvá minuty místo odpoledne.

Související články