Houd de OpenVPN-CA-signeringssleutel buiten /etc/openvpn

Twee mappen die er in een handleiding hetzelfde uitzien, doen volledig verschillende taken. De ene bevat de certificaatautoriteit: de privésleutel, de serienummerteller en het overzicht van alles wat zij heeft ondertekend. De andere bevat wat de daemon nodig heeft om te starten en clients te bedienen. Beide op dezelfde host onder hetzelfde account zetten is handig voor één middag en duur voor de rest van de levensduur van de uitrol, want de daemon draait dan naast de enige sleutel die elke gewenste identiteit kan maken.

Wat de CA-werkruimte bevat

Een PKI-map is uitgeverstatus, geen configuratie. Zij bevat de privésleutel en het certificaat van de CA, een serienummerbestand, een index van uitgegeven certificaten en het per identiteit geproduceerde materiaal.

Het ondertekenen van een aanvraag verandert die status, en daarom hoort de werkruimte bij een door de beheerder beheerd account op een host waar de VPN-dienst niet draait. Iedereen die de privésleutel van de CA kan lezen, kan een certificaat uitgeven dat de server vertrouwt, dus de bescherming van de sleutel is het hele vertrouwensmodel in één bestand. Hem naar een tweede locatie kopiëren om een stap te sparen maakt een tweede ding om te beschermen en een tweede ding om te vergeten. Elke handtekening verhoogt ook het serienummer en voegt een regel aan de index toe, en daarom is de werkruimte één kopie van status en geen map met bestanden.

Het openbare CA-certificaat is anders. Het is bedoeld om te worden verspreid, en het is wat clients en servers gebruiken om elkaar te verifiëren.

Wat de daemon leest bij het starten

Een draaiende server verbruikt een kleine set: zijn eigen certificaat, zijn eigen privésleutel, het CA-certificaat om peers te verifiëren en welk sleutelmateriaal zijn gekozen modus ook vereist. Hij leest die paden bij het opstarten en opnieuw bij het herladen.

Eigendom moet worden beoordeeld tegen de unit die daadwerkelijk start, niet tegen een interactieve root-shell. Verklaarde sandboxing kan een deel van het bestandssysteem alleen-lezen of onzichtbaar maken, zelfs wanneer een handmatige test als root slaagt.

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

Die derde regel is degene die mensen overslaan. Hij vraagt het eigen account van de daemon of het de sleutel kan lezen, en dat is de enige versie van de vraag die ertoe doet zodra privileges zijn afgestaan. Een nul-exit als root zegt niets over wat er na het afstaan gebeurt.

De twee foutpaden zijn het waard om te scheiden voordat u enige toestemming wijzigt. Een ondertekeningsfout wijst naar de PKI-map, de zoektoestemming op de bovenliggende mappen en het account dat de uitgever draait. Een opstartfout wijst naar de unit, de werkmap en de paden die in de serverconfiguratie worden genoemd. De hele boom voor iedereen leesbaar maken lost geen van beide op en verwijdert de grens waarvan beide afhangen.

Waarom het kopiëren van de CA-sleutel naar de server later mislukt

De kopie begint meestal als een debug-stap: iemand wil een client op de VPN-host vernieuwen, dus de CA-sleutel belandt in /etc/openvpn en de vernieuwing werkt. De onmiddellijke taak slaagt, en de grens is weg.

Dan wordt de server geback-upt, en de ondertekeningsinstantie komt in de back-ups terecht. Een snapshot, een supportbundel of een kopie van de configuratiemap draagt nu het vermogen om vertrouwde identiteiten uit te geven zolang de CA geldig is. Wie die kopie heeft, kan een certificaat maken voor elke naam die de server accepteert, ook voor namen die nooit zijn uitgegeven. De enige registratie van die uitgifte is degene die zij kiezen te bewaren.

Herstellen van die toestand is geen kwestie van een bestand verwijderen. U moet beslissen of de sleutel is blootgesteld, de CA roteren als dat zo is, en het vertrouwen opnieuw verdelen over elke peer. Een aparte werkruimte voorkomt het hele gesprek.

Accounts, mappen, back-ups

Geef de uitgever een eigen account en thuismap, weg van de VPN-host waar dat praktisch is. Geef de daemon een ander account, met leestoegang tot het uitgerolde materiaal en schrijftoegang tot niets dat certificaten uitgeeft. Rol uit door openbare certificaten naar buiten te kopiëren en nooit door privéstatus van de uitgever naar binnen te trekken. Maak back-ups van de twee rollen apart, omdat hun gevoeligheid en hun herstelverhalen verschillen.

Na een intrekking werkt u het CRL-bestand bij dat de serverconfiguratie noemt, en herlaadt u daarna de dienst zodat nieuwe verbindingen het lezen. De Easy-RSA-documentatie behandelt de indeling van de werkruimte en de ondertekeningsworkflow; de eigendomsregels eromheen blijven een beslissing over uw host. Controleer wat de dienst heeft geladen met openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate in plaats van aan te nemen dat het herladen het heeft opgepakt.

Een test die de scheiding bewijst

Controleer het negatieve geval, niet alleen het werkende. Onderteken een certificaat vanuit het uitgeversaccount zoals bedoeld, en bevestig dan dat hetzelfde account de dienst niet kan starten en de privésleutel van de server niet kan lezen. Bevestig daarna dat het account van de daemon de privésleutel van de CA niet kan lezen.

Die drie controles kosten een paar minuten en overleven personeelswisselingen, omdat het uitspraken over toestemmingen zijn en niet over gewoonte. Schrijf het resultaat op met de paden en accounts die het dekte, plus de datum waarop u ze hebt uitgevoerd. De volgende persoon die deze uitrol erft, zal anders de grens opnieuw afleiden uit een handleiding die er nooit een had. Een gedateerd verslag is ook wat de volgende beoordeling minuten in plaats van een middag laat duren.