Hold OpenVPN-CA’ens signeringsnøgle ude af /etc/openvpn

To mapper, der ser ens ud i en vejledning, udfører helt forskellige opgaver. Den ene rummer certifikatmyndigheden: dens private nøgle, dens serienummertæller og fortegnelsen over alt, hvad den har signeret. Den anden rummer det, som daemonen skal bruge for at starte og betjene klienter. At lægge begge på samme vært under samme konto er bekvemt i en eftermiddag og dyrt resten af udrulningens levetid, fordi daemonen så kører ved siden af den ene nøgle, der kan skabe enhver identitet, den ønsker.

Hvad CA-arbejdsområdet indeholder

En PKI-mappe er udstederens tilstand, ikke konfiguration. Den indeholder CA’ens private nøgle og certifikat, en serienummerfil, et indeks over udstedte certifikater og det per-identitet-materiale, der er fremstillet ud fra dem.

Signering af en anmodning ændrer den tilstand, og derfor tilhører arbejdsområdet en administratorkontrolleret konto på en vært, hvor VPN-tjenesten ikke kører. Enhver, der kan læse CA’ens private nøgle, kan udstede et certifikat, som serveren vil stole på, så nøglens beskyttelse er hele tillidsmodellen i én fil. Kopiering til et andet sted for at spare et trin skaber en ekstra ting at beskytte og en ekstra ting at glemme. Hver signatur øger også serienummeret og tilføjer en post til indekset, og derfor er arbejdsområdet én kopi af tilstand i stedet for en mappe med filer.

CA’ens offentlige certifikat er anderledes. Det er beregnet til distribution, og det er det, klienter og servere bruger til at verificere hinanden.

Hvad daemonen læser, når den starter

En kørende server forbruger et lille sæt: sit eget certifikat, sin egen private nøgle, CA-certifikatet til at verificere peers og det nøglemateriale, dens valgte tilstand kræver. Den læser disse stier ved opstart og igen ved genindlæsning.

Ejerskab skal vurderes mod den enhed, der faktisk starter, ikke mod en interaktiv root-shell. Deklareret sandboxing kan gøre en del af filsystemet skrivebeskyttet eller usynligt, selv når en manuel test som root lykkes.

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 linje er den, folk springer over. Den spørger daemonens egen konto, om den kan læse nøglen, og det er den eneste version af spørgsmålet, der betyder noget, når privilegierne er droppet. En nul-exit som root siger intet om, hvad der sker efter droppet.

De to fejlveje er værd at adskille, før du ændrer nogen tilladelse. En signeringsfejl peger på PKI-mappen, søgetilladelsen på dens overordnede mapper og den konto, der kører udstederen. En opstartsfejl peger på enheden, dens arbejdsmappe og de stier, der er nævnt i serverkonfigurationen. At gøre hele træet læsbart for alle løser ingen af dem og fjerner den grænse, som begge afhænger af.

Hvorfor kopiering af CA-nøglen til serveren fejler senere

Kopien starter normalt som et fejlretningstræk: nogen vil forny en klient på VPN-værten, så CA-nøglen havner i /etc/openvpn og fornyelsen virker. Den umiddelbare opgave lykkes, og grænsen er væk.

Så tages der backup af serveren, og signeringsmyndigheden følger med i backupperne. Et snapshot, en supportpakke eller en kopi af konfigurationsmappen bærer nu evnen til at udstede betroede identiteter, så længe CA’en er gyldig. Den, der har den kopi, kan skabe et certifikat til ethvert navn, serveren accepterer, også navne, der aldrig blev udstedt. Den eneste registrering af den udstedelse er den, de vælger at beholde.

At komme ud af den tilstand er ikke et spørgsmål om at slette en fil. Du skal afgøre, om nøglen var eksponeret, rotere CA’en hvis den var, og redistribuere tillid til hver peer. Et separat arbejdsområde undgår hele samtalen.

Konti, mapper, backupper

Giv udstederen sin egen konto og hjemmemappe, holdt væk fra VPN-værten, hvor det er praktisk. Giv daemonen en anden konto med læseadgang til det udrullede materiale og skriveadgang til intet, der udsteder certifikater. Udrul ved at kopiere offentlige certifikater udad og aldrig ved at trække udstederens private tilstand indad. Tag backup af de to roller hver for sig, fordi deres følsomhed og deres gendannelseshistorier er forskellige.

Efter en tilbagekaldelse skal du opdatere den CRL-fil, som serverkonfigurationen angiver, og derefter genindlæse tjenesten, så nye forbindelser læser den. Easy-RSA-dokumentationen dækker arbejdsområdets opbygning og signeringsworkflow; ejerskabsreglerne omkring det er stadig en beslutning om din vært. Bekræft, hvad tjenesten indlæste med openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate i stedet for at antage, at genindlæsningen fangede den.

En test, der beviser adskillelsen

Kontrollér det negative tilfælde, ikke kun det, der virker. Signér et certifikat fra udstederkontoen som designet, og bekræft derefter, at samme konto ikke kan starte tjenesten eller læse serverens private nøgle. Bekræft derefter, at daemonens konto ikke kan læse CA’ens private nøgle.

De tre kontroller tager et par minutter og overlever personaleforandringer, fordi de er udsagn om tilladelser snarere end om vane. Skriv resultatet ned med de stier og konti, det dækkede, plus datoen, du kørte dem. Den næste, der arver denne udrulning, vil ellers udlede grænsen igen fra en vejledning, der aldrig havde en. En dateret registrering er også det, der gør det næste gennemsyn til minutter i stedet for en eftermiddag.