Hald OpenVPN-CA-en sin signeringsnøkkel utanfor /etc/openvpn

To mapper som ser like ut i ein rettleiar, gjer heilt ulike arbeid. Den eine held sertifikatstyresmakta: den private nøkkelen hennar, serienummerteljaren og oversynet over alt ho har signert. Den andre held det daemonen treng for å starte og tena klientar. Å leggje båe på same vert under same konto er praktisk for ein ettermiddag og dyrt resten av levetida til utrullinga, fordi daemonen då køyrer ved sida av den eine nøkkelen som kan lage kva som helst identitet han vil.

Kva CA-arbeidsområdet inneheld

Ei PKI-mappe er utgivartilstand, ikkje konfigurasjon. Ho inneheld den private nøkkelen og sertifikatet til CA-en, ei serienummerfil, ein indeks over utgivne sertifikat og materialet per identitet som er laga frå dei.

Signering av ein førespurnad endrar denne tilstanden, og difor høyrer arbeidsområdet til ein administratorkontrollert konto på ein vert der VPN-tenesta ikkje køyrer. Alle som kan lese den private nøkkelen til CA-en, kan gje ut eit sertifikat serveren vil stole på, så vernet av nøkkelen er heile tillitsmodellen i éi fil. Å kopiere han til ein annan stad for å spare eit steg skaper ein ekstra ting å verne og ein ekstra ting å gløyme. Kvar signatur aukar også serienummeret og legg til ei oppføring i indeksen, og difor er arbeidsområdet éin kopi av tilstand i staden for ei mappe med filer.

Det offentlege CA-sertifikatet er annleis. Det er meint å distribuerast, og det er det klientar og serverar brukar for å verifisere kvarandre.

Kva daemonen les når han startar

Ein køyrande server brukar eit lite sett: sitt eige sertifikat, sin eigen private nøkkel, CA-sertifikatet for å verifisere partar og det nøkkelmaterialet den valde modusen krev. Han les desse stiane ved oppstart og igjen ved omlasting.

Eigarskap må vurderast mot eininga som faktisk startar, ikkje mot eit interaktivt root-skal. Deklarert sandkassing kan gjere delar av filsystemet skriveverna eller usynleg sjølv når ein manuell test som root lukkast.

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 linja er den folk hoppar over. Ho spør den eigen kontoen til daemonen om han kan lese nøkkelen, og det er den einaste versjonen av spørsmålet som tel etter at privilegia er sleppte. Ein null-utgang som root seier ingenting om kva som skjer etter sleppet.

Dei to feilvegane er verd å skilje før du endrar noka løyve. Ein signeringsfeil peikar på PKI-mappa, søkeløyvet på dei overordna mappene hennar og kontoen som køyrer utgivaren. Ein oppstartsfeil peikar på eininga, arbeidsmappa hennar og stiane som er namngjevne i serverkonfigurasjonen. Å gjere heile treet lesbart for alle rettar ingen av dei og fjernar grensa begge er avhengige av.

Kvifor kopiering av CA-nøkkelen til serveren feilar seinare

Kopien startar vanlegvis som eit feilsøkingstrekk: nokon vil fornye ein klient på VPN-verten, så CA-nøkkelen hamnar i /etc/openvpn og fornyinga verkar. Den umiddelbare oppgåva lukkast, og grensa er borte.

Så blir det teke tryggingskopi av serveren, og signeringsstyresmakta blir med i kopiane. Eit augeblinksbilete, ein støttepakke eller ein kopi av konfigurasjonsmappa ber no evna til å gje ut betrudde identitetar så lenge CA-en er gyldig. Den som har den kopien, kan lage eit sertifikat for eitkvart namn serveren godtek, også namn som aldri vart gjevne ut. Den einaste registreringa av den utgivinga er den dei vel å behalde.

Å kome seg ut av den tilstanden er ikkje eit spørsmål om å slette ei fil. Du må avgjere om nøkkelen var eksponert, rotere CA-en om han var det, og redistribuere tillit til kvar part. Eit separat arbeidsområde unngår heile samtalen.

Kontoar, mapper, tryggingskopiar

Gje utgivaren sin eigen konto og heimemappe, halden borte frå VPN-verten der det er praktisk. Gje daemonen ein annan konto, med lesetilgang til det utrulla materialet og skrivetilgang til ingenting som gjev ut sertifikat. Rull ut ved å kopiere offentlege sertifikat utover og aldri ved å trekke den private tilstanden til utgivaren innover. Ta tryggingskopi av dei to rollene kvar for seg, fordi følsemda deira og gjenopprettingshistoriene er ulike.

Etter ein tilbakekalling, oppdater CRL-fila som serverkonfigurasjonen namngjev, og last så tenesta på nytt slik at nye tilkoplingar les ho. Easy-RSA-dokumentasjonen dekkjer oppbygginga av arbeidsområdet og signeringsflyten; eigarskapsreglane rundt det er framleis ei avgjerd om verten din. Stadfest kva tenesta lasta med openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate i staden for å gå ut frå at omlastinga tok ho med.

Ein test som provar delinga

Kontroller det negative tilfellet, ikkje berre det som verkar. Signer eit sertifikat frå utgivarkontoen som designa, og stadfest deretter at same konto ikkje kan starte tenesta eller lese den private nøkkelen til serveren. Stadfest deretter at kontoen til daemonen ikkje kan lese den private nøkkelen til CA-en.

Dei tre kontrollane tek nokre minutt og overlever personalendringar, fordi dei er utsegner om løyve og ikkje om vane. Skriv ned resultatet med stiane og kontoane det dekte, pluss datoen du køyrde dei. Den neste som arvar denne utrullinga vil elles leie grensa på nytt ut frå ein rettleiar som aldri hadde ei. Ei datert registrering er også det som gjer neste gjennomgang til minutt i staden for ein ettermiddag.