Hâld de OpenVPN-CA-ûndertekeningskaai bûten /etc/openvpn

Twa mappen dy’t yn in hantlieding itselde lykje, dogge folslein ferskillende wurk. De iene hâldt de sertifikaasje-ynstânsje: syn partikuliere kaai, syn searjenûmerteller en it register fan alles wat er ûndertekene hat. De oare hâldt wat de daemon nedich hat om te starten en kliïnten te betsjinjen. Beide op deselde host ûnder itselde akkount pleatse is handich foar ien middei en djoer foar de rest fan it libben fan ’e útrôl, want de daemon rint dan njonken de iene kaai dy’t elke identiteit meitsje kin dy’t er wol.

Wat de CA-wurkromte befettet

In PKI-map is útjowerstatus, gjin konfiguraasje. It befettet de partikuliere kaai en it sertifikaat fan ’e CA, in searjenûmerbestân, in yndeks fan útjûn sertifikaten en it materiaal per identiteit dat dêrfan makke is.

It ûndertekenjen fan in fersyk feroaret dy status, en dêrom heart de wurkromte ta oan in troch de behearder betsjinne akkount op in host dêr’t de VPN-tsjinst net rint. Elkenien dy’t de partikuliere kaai fan ’e CA lêze kin, kin in sertifikaat útjaan dêr’t de tsjinner op fertrouwe sil, dus de beskerming fan ’e kaai is it hiele fertrouwensmodel yn ien bestân. It kopiearjen nei in twadde plak om in stap te sparjen makket in twadde ding om te beskermjen en in twadde ding om te ferjitten. Elke ûndertekening ferheget ek it searjenûmer en foeget in ynskriuwing ta oan ’e yndeks, en dêrom is de wurkromte ien kopy fan status yn plak fan in map mei bestannen.

It iepenbiere CA-sertifikaat is oars. It is bedoeld om ferspraat te wurden, en it is wat kliïnten en tsjinners brûke om elkoar te ferifiearjen.

Wat de daemon lêst as er start

In rinnende tsjinner brûkt in lyts set: syn eigen sertifikaat, syn eigen partikuliere kaai, it CA-sertifikaat om partners te ferifiearjen en hokker kaaimateriaal syn keazen modus ek nedich hat. Hy lêst dy paden by it starten en wer by it werladen.

Eigendom moat wurde beoardiele tsjin ’e ienheid dy’t echt start, net tsjin in ynteraktive root-shell. Ferklearre sandboxing kin in part fan it bestânsysteem allinnich-lêze of ûnsichtber meitsje, sels as in hânmjittige test as root slagget.

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

Dy tredde rigel is dejinge dy’t minsken oerslaan. Hy freget it eigen akkount fan ’e daemon oft it de kaai lêze kin, en dat is de iennige ferzje fan ’e fraach dy’t der ta docht as de foarrjochten ienris sakke binne. In nul-útgong as root seit neat oer wat der nei it sakjen bart.

De twa flaterpaden binne it wurdich te skieden foar’t jo hokker tastimming dan ek feroarje. In ûndertekeningsflater wiist nei de PKI-map, de syktastimming op syn âldermappen en it akkount dat de útjower rint. In startflater wiist nei de ienheid, syn wurkmap en de paden neamd yn ’e tsjinnerkonfiguraasje. It hiele beam meitsje ta wrâldlêsber lost gjin fan beide op en hellet de grins fuort dêr’t beide fan ôfhinklik binne.

Wêrom’t it kopiearjen fan ’e CA-kaai nei de tsjinner letter mislearret

De kopy begjint meast as in debug-stap: immen wol in kliïnt fernije op ’e VPN-host, dus de CA-kaai bedarret yn /etc/openvpn en de fernijing wurket. De direkte taak slagget, en de grins is fuort.

Dan wurdt de tsjinner reservearre, en de ûndertekeningsynstânsje komt by de reservekopyen. In snapshot, in stipebondel of in kopy fan ’e konfiguraasjemap draacht no it fermogen om fertroude identiteiten út te jaan salang’t de CA jildich is. Wa’t dy kopy hat, kin in sertifikaat meitsje foar elke namme dy’t de tsjinner akseptearret, ek foar nammen dy’t nea útjûn binne. It iennige register fan dy útjefte is dejinge dy’t sy keare te hâlden.

Better wurde fan dy status is gjin kwestje fan in bestân fuortsmite. Jo moatte beslute oft de kaai bleatlein wie, de CA rotearje as dat sa wie, en it fertrouwen opnij ferdiele oer elke partner. In aparte wurkromte foarkomt it hiele petear.

Akkounts, mappen, reservekopyen

Jou de útjower syn eigen akkount en thúsmap, bûten de VPN-host holden wêr’t dat praktysk is. Jou de daemon in oar akkount, mei lêstastimming ta it útrôle materiaal en skriuwtastimming ta neat dat sertifikaten útjout. Rôl út troch iepenbiere sertifikaten nei bûten te kopiearjen en nea troch partikuliere útjowerstatus nei binnen te lûken. Meitsje reservekopyen fan ’e twa rollen apart, want harren gefoelichheid en harren werstelferhalen ferskille.

Nei in ynlûking, fernij it CRL-bestân dat de tsjinnerkonfiguraasje neamt, en werlaad dan de tsjinst sadat nije ferbiningen it lêze. De Easy-RSA-dokumintaasje behannelet de yndieling fan ’e wurkromte en de ûndertekeningswurkstream; de eigendomsregels deromhinne bliuwe in beslút oer jo host. Befêstigje wat de tsjinst laden hat mei openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate yn plak fan oan te nimmen dat it werladen it oppakt hat.

In test dy’t de skieding bewissiget

Kontrolearje it negative gefal, net allinnich it wurkjende. Undertekenje in sertifikaat fan it útjowerakkount sa’t ûntwurpen, en befêstigje dan dat itselde akkount de tsjinst net starte kin of de partikuliere kaai fan ’e tsjinner lêze kin. Befêstigje dan dat it akkount fan ’e daemon de partikuliere kaai fan ’e CA net lêze kin.

Dy trije kontrôles nimme in pear minuten en oerlibje personielsferoarings, want it binne útspraken oer tastimmingen yn plak fan oer gewoante. Skriuw it resultaat op mei de paden en akkounts dy’t it besloech, plus de datum wêrop jo se rûnen. De folgjende persoan dy’t dizze útrôl erft, sil oars de grins opnij ôfliede út in hantlieding dy’t nea ien hie. In datearre register is ek wat de folgjende resinsje minuten yn plak fan in middei duorje lit.