Hou die OpenVPN-CA-ondertekeningsleutel buite /etc/openvpn

Twee gidse wat in ’n handleiding dieselfde lyk, doen heeltemal verskillende take. Die een hou die sertifikaatowerheid: sy private sleutel, sy reeksnommerteller en die rekord van alles wat dit onderteken het. Die ander hou wat die daemon nodig het om te begin en kliënte te bedien. Om albei op dieselfde gasheer onder dieselfde rekening te plaas, is gerieflik vir een middag en duur vir die res van die ontplooiing se lewe, want die daemon loop dan langs die een sleutel wat enige identiteit kan skep wat hy wil.

Wat die CA-werkarea bevat

’n PKI-gids is uitreiker-toestand, nie konfigurasie nie. Dit bevat die CA se private sleutel en sertifikaat, ’n reekslêer, ’n indeks van uitgereikte sertifikate en die per-identiteit-materiaal wat daaruit geproduseer is.

Die ondertekening van ’n versoek verander daardie toestand, en daarom behoort die werkarea aan ’n administrateur-beheerde rekening op ’n gasheer waar die VPN-diens nie loop nie. Enigiemand wat die CA se private sleutel kan lees, kan ’n sertifikaat uitreik wat die bediener sal vertrou, so die beskerming van die sleutel is die hele vertrouensmodel in een lêer. Om dit na ’n tweede plek te kopieer om ’n stap te spaar, skep ’n tweede ding om te beskerm en ’n tweede ding om te vergeet. Elke ondertekening verhoog ook die reeksnommer en voeg ’n inskrywing by die indeks, en daarom is die werkarea een kopie van toestand eerder as ’n gids met lêers.

Die publieke CA-sertifikaat is anders. Dit is bedoel om versprei te word, en dit is wat kliënte en bedieners gebruik om mekaar te verifieer.

Wat die daemon lees wanneer dit begin

’n Lopende bediener gebruik ’n klein stel: sy eie sertifikaat, sy eie private sleutel, die CA-sertifikaat om eweknieë te verifieer, en watter sleutelmateriaal ook al sy gekose modus vereis. Dit lees daardie paaie by die opstart en weer by herlaai.

Eienaarskap moet teen die eenheid wat werklik begin, geëvalueer word, nie teen ’n interaktiewe root-dop nie. Verklaarde sandkasting kan ’n deel van die lêerstelsel lees-alleen of onsigbaar maak selfs wanneer ’n handmatige toets as root slaag.

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

Daardie derde reël is die een wat mense oorslaan. Dit vra die daemon se eie rekening of dit die sleutel kan lees, en dit is die enigste weergawe van die vraag wat saak maak nadat voorregte laat val is. ’n Uittrede van nul met root sê niks oor wat ná die val gebeur nie.

Die twee foutpaaie is die moeite werd om te skei voordat jy enige toestemming verander. ’n Ondertekeningsfout wys na die PKI-gids, die soektoestemming op sy ouergidse en die rekening wat die uitreiker laat loop. ’n Opstartfout wys na die eenheid, sy werkende gids en die paaie wat in die bedienerkonfigurasie genoem word. Om die hele boom wêreldleesbaar te maak, los nie een van hulle op nie, en dit verwyder die grens waarvan albei afhanklik is.

Waarom die kopiëring van die CA-sleutel na die bediener later misluk

Die kopie begin gewoonlik as ’n ontfoutingsetap: iemand wil ’n kliënt op die VPN-gasheer hernu, so die CA-sleutel beland in /etc/openvpn en die hernuwing werk. Die onmiddellike taak slaag, en die grens is weg.

Dan word die bediener gerugsteun, en die ondertekeningsowerheid sluit by die rugsteune aan. ’n Momentopname, ’n ondersteuningsbundel of ’n kopie van die konfigurasiegids dra nou die vermoë om vertroude identiteite uit te reik solank die CA geldig is. Wie ook al daardie kopie hou, kan ’n sertifikaat skep vir enige naam wat die bediener aanvaar, insluitend name wat nooit uitgereik is nie. Die enigste rekord van daardie uitreiking is die een wat hulle kies om te hou.

Om van daardie toestand te herstel, is nie ’n kwessie van ’n lêer te verwyder nie. Jy moet besluit of die sleutel blootgestel was, die CA roteer as dit was, en vertroue aan elke eweknie herverdeel. ’n Aparte werkarea vermy die hele gesprek.

Rekeninge, gidse, rugsteune

Gee die uitreiker sy eie rekening en tuisgids, weg van die VPN-gasheer waar dit prakties is. Gee die daemon ’n ander rekening, met leestoegang tot die ontplooide materiaal en skryftoegang tot niks wat sertifikate uitreik nie. Ontplooi deur publieke sertifikate uitwaarts te kopieer en nooit deur private uitreiker-toestand inwaarts te trek nie. Rugsteun die twee rolle afsonderlik, want hulle sensitiwiteit en hulle herstelverhale verskil.

Ná ’n herroeping, werk die CRL-lêer by wat die bedienerkonfigurasie noem, en herlaai dan die diens sodat nuwe verbindings dit lees. Die Easy-RSA-dokumentasie dek die werkarea-uitleg en die ondertekeningswerkvloei; die eienaarskapreëls daaromtrent bly ’n besluit oor jou gasheer. Bevestig wat die diens gelaai het met openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate eerder as om te aanvaar die herlaai het dit opgetel.

’n Toets wat die skeiding bewys

Kontroleer die negatiewe geval, nie net die werkende een nie. Onderteken ’n sertifikaat van die uitreiker-rekening soos ontwerp, en bevestig dan dat dieselfde rekening nie die diens kan begin of die bediener se private sleutel kan lees nie. Bevestig dan dat die daemon se rekening nie die CA se private sleutel kan lees nie.

Daardie drie kontroles neem ’n paar minute en oorleef personeelveranderings, want hulle is stellings oor toestemmings eerder as oor gewoonte. Skryf die resultaat neer met die paaie en rekeninge wat dit gedek het, plus die datum waarop jy dit gedoen het. Die volgende persoon wat hierdie ontplooiing erf, sal andersins die grens herlei uit ’n handleiding wat nooit een gehad het nie. ’n Gedateerde rekord is ook wat die volgende hersiening minute eerder as ’n middag laat neem.