Håll OpenVPN-CA:ns signeringsnyckel utanför /etc/openvpn

Två kataloger som ser likadana ut i en guide gör helt olika jobb. Den ena innehåller certifikatutfärdaren: dess privata nyckel, serienummerräknaren och registret över allt den signerat. Den andra innehåller det daemonen behöver för att starta och betjäna klienter. Att lägga båda på samma värd under samma konto är bekvämt för en eftermiddag och dyrt för resten av utrullningens livstid, eftersom daemonen då kör bredvid den enda nyckel som kan skapa vilken identitet den vill.

Vad CA-arbetsytan innehåller

En PKI-katalog är utfärdarens tillstånd, inte konfiguration. Den innehåller CA:ns privata nyckel och certifikat, en serienummerfil, ett index över utfärdade certifikat och materialet per identitet som tagits fram ur dem.

Att signera en begäran ändrar det tillståndet, och därför tillhör arbetsytan ett administratörskontrollerat konto på en värd där VPN-tjänsten inte körs. Den som kan läsa CA:ns privata nyckel kan utfärda ett certifikat som servern kommer att lita på, så nyckelns skydd är hela förtroendemodellen i en enda fil. Att kopiera den till en andra plats för att spara ett steg skapar en andra sak att skydda och en andra sak att glömma. Varje signatur ökar också serienumret och lägger till en post i indexet, och därför är arbetsytan en kopia av tillstånd i stället för en mapp med filer.

CA:ns offentliga certifikat är annorlunda. Det är avsett att distribueras, och det är vad klienter och servrar använder för att verifiera varandra.

Vad daemonen läser när den startar

En körande server förbrukar en liten uppsättning: sitt eget certifikat, sin egen privata nyckel, CA-certifikatet för att verifiera parter och det nyckelmaterial som det valda läget kräver. Den läser dessa sökvägar vid start och igen vid omladdning.

Ägandeskap måste bedömas mot enheten som faktiskt startar, inte mot ett interaktivt root-skal. Deklarerad sandlåda kan göra en del av filsystemet skrivskyddat eller osynligt även när ett manuellt test som root lyckas.

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 $?

Den tredje raden är den folk hoppar över. Den frågar daemonens eget konto om det kan läsa nyckeln, och det är den enda versionen av frågan som spelar roll när privilegierna väl släppts. En nollutgång som root säger ingenting om vad som händer efter släppet.

De två felvägarna är värda att skilja på innan du ändrar någon behörighet. Ett signeringsfel pekar på PKI-katalogen, sökbehörigheten på dess överordnade kataloger och kontot som kör utfärdaren. Ett startfel pekar på enheten, dess arbetskatalog och de sökvägar som nämns i serverkonfigurationen. Att göra hela trädet läsbart för alla åtgärdar inget av dem och tar bort den gräns som båda är beroende av.

Varför kopiering av CA-nyckeln till servern misslyckas senare

Kopian börjar oftast som ett felsökningssteg: någon vill förnya en klient på VPN-värden, så CA-nyckeln hamnar i /etc/openvpn och förnyelsen fungerar. Den omedelbara uppgiften lyckas, och gränsen är borta.

Sedan säkerhetskopieras servern, och signeringsmyndigheten följer med i kopiorna. En ögonblicksbild, ett supportpaket eller en kopia av konfigurationskatalogen bär nu förmågan att utfärda betrodda identiteter så länge CA:n är giltig. Den som har den kopian kan skapa ett certifikat för vilket namn servern accepterar som helst, även namn som aldrig utfärdats. Den enda registreringen av den utfärdandet är den de väljer att behålla.

Att återhämta sig från det tillståndet är inte en fråga om att radera en fil. Du måste avgöra om nyckeln exponerats, rotera CA:n om så var fallet, och omfördela förtroendet till varje part. En separat arbetsyta undviker hela samtalet.

Konton, kataloger, säkerhetskopior

Ge utfärdaren ett eget konto och egen hemkatalog, hållen borta från VPN-värden där det är praktiskt. Ge daemonen ett annat konto, med läsbehörighet till det utrullade materialet och skrivbehörighet till ingenting som utfärdar certifikat. Rulla ut genom att kopiera offentliga certifikat utåt och aldrig genom att dra utfärdarens privata tillstånd inåt. Säkerhetskopiera de två rollerna separat, eftersom deras känslighet och deras återställningshistorier skiljer sig.

Efter en återkallelse, uppdatera CRL-filen som serverkonfigurationen anger, och ladda sedan om tjänsten så att nya anslutningar läser den. Easy-RSA-dokumentationen täcker arbetsytans utformning och signeringsflödet; ägandereglerna runt den är fortfarande ett beslut om din värd. Bekräfta vad tjänsten laddade med openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate i stället för att anta att omladdningen tog den.

Ett test som bevisar delningen

Kontrollera det negativa fallet, inte bara det som fungerar. Signera ett certifikat från utfärdarkontot enligt designen och bekräfta sedan att samma konto inte kan starta tjänsten eller läsa serverns privata nyckel. Bekräfta därefter att daemonens konto inte kan läsa CA:ns privata nyckel.

De tre kontrollerna tar några minuter och överlever personalbyten, eftersom de är påståenden om behörigheter och inte om vana. Skriv ner resultatet med de sökvägar och konton det täckte, plus datumet du körde dem. Nästa person som ärver den här utrullningen kommer annars att härleda gränsen på nytt från en guide som aldrig hade någon. En daterad registrering är också det som gör nästa granskning till minuter i stället för en eftermiddag.