Kaksi hakemistoa, jotka opetusohjelmassa näyttävät samalta, tekevät täysin eri tehtäviä. Toinen sisältää varmenteiden myöntäjän: sen yksityisen avaimen, sarjanumerolaskurin ja merkinnät kaikesta, minkä se on allekirjoittanut. Toinen sisältää sen, mitä daemon tarvitsee käynnistyäkseen ja palvellakseen asiakkaita. Molempien sijoittaminen samaan isäntään saman tilin alle on kätevää yhdeksi iltapäiväksi ja kallista käyttöönoton loppuelämän ajan, koska daemon kulkee silloin sen ainoan avaimen vieressä, joka voi luoda minkä tahansa haluamansa identiteetin.

Mikä on CA-työtilan sisältö

PKI-hakemisto on myöntäjän tila, ei kokoonpano. Se sisältää CA:n yksityisen avaimen ja varmenteen, sarjanumerotiedoston, myönnettyjen varmenteiden hakemiston ja kunkin identiteetin materiaalin, joka niistä on tuotettu.

Pyynnön allekirjoittaminen muuttaa tätä tilaa, minkä vuoksi työtila kuuluu ylläpitäjän hallitsemalle tilille isännässä, jossa VPN-palvelu ei ole käynnissä. Kuka tahansa, joka voi lukea CA:n yksityisen avaimen, voi myöntää varmenteen, johon palvelin luottaa, joten avaimen suojaus on koko luottamusmalli yhdessä tiedostossa. Sen kopioiminen toiseen paikkaan vaiheen säästämiseksi luo toisen suojeltavan asian ja toisen unohdettavan asian. Jokainen allekirjoitus myös kasvattaa sarjanumeroa ja lisää merkinnän hakemistoon, minkä vuoksi työtila on yksi tilan kopio eikä tiedostokansio.

CA:n julkinen varmenne on erilainen. Se on tarkoitettu jaettavaksi, ja asiakkaat ja palvelimet käyttävät sitä toistensa varmistamiseen.

Mikä on daemonin lukema käynnistyksessä

Käynnissä oleva palvelin kuluttaa pienen joukon: oman varmenteensa, oman yksityisen avaimensa, CA-varmenteen vertaisten varmistamiseen ja sen avainmateriaalin, jota valittu tila vaatii. Se lukee nämä polut käynnistyksessä ja uudelleenlatauksessa.

Omistajuus on arvioitava sitä yksikköä vasten, joka todella käynnistyy, ei interaktiivista root-kuorta vasten. Ilmoitettu hiekkalaatikointi voi tehdä osan tiedostojärjestelmästä vain luku -tilaan tai näkymättömäksi, vaikka manuaalinen testi rootina onnistuisi.

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

Kolmatta riviä ihmiset ohittavat. Se kysyy daemonin omalta tililtä, voiko se lukea avaimen, ja se on ainoa kysymyksen versio, jolla on merkitystä sen jälkeen, kun oikeudet on pudotettu. Nollapaluu rootina ei kerro mitään siitä, mitä pudotuksen jälkeen tapahtuu.

Kaksi virhepolkua kannattaa erottaa ennen kuin muutat mitään käyttöoikeutta. Allekirjoitusvirhe osoittaa PKI-hakemistoon, sen ylähakemistojen hakuoikeuteen ja myöntäjää ajavan tiliin. Käynnistysvirhe osoittaa yksikköön, sen työhakemistoon ja palvelimen kokoonpanossa nimettyihin polkuihin. Koko puun tekeminen kaikkien luettavaksi ei korjaa kumpaakaan ja poistaa rajan, josta molemmat riippuvat.

Miksi CA-avaimen kopioiminen palvelimelle epäonnistuu myöhemmin

Kopio alkaa yleensä virheenkorjausliikkeenä: joku haluaa uusia asiakkaan VPN-isännässä, joten CA-avain päätyy hakemistoon /etc/openvpn ja uusiminen toimii. Välitön tehtävä onnistuu ja raja on poissa.

Sitten palvelimesta otetaan varmuuskopio, ja allekirjoitusviranomainen liittyy varmuuskopioihin. Tilannekuva, tukipaketti tai kopio kokoonpanohakemistosta kantaa nyt kyvyn myöntää luotettuja identiteettejä niin kauan kuin CA on voimassa. Kuka tahansa tuon kopion haltija voi luoda varmenteen mille tahansa nimelle, jonka palvelin hyväksyy, myös nimille, joita ei koskaan myönnetty. Ainoa merkintä tuosta myönnöstä on se, jonka he päättävät pitää.

Tilasta toipuminen ei ole tiedoston poistamista. Sinun on päätettävä, paljastuiko avain, vaihdettava CA, jos paljastui, ja jaettava luottamus uudelleen jokaiselle vertaiselle. Erillinen työtila välttää koko keskustelun.

Tilit, hakemistot, varmuuskopiot

Anna myöntäjälle oma tili ja kotihakemisto, poissa VPN-isännästä silloin kun se on käytännöllistä. Anna daemonille eri tili, jolla on lukuoikeus käyttöön otettuun materiaaliin ja kirjoitusoikeus ei mihinkään, mikä myöntää varmenteita. Ota käyttöön kopioimalla julkisia varmenteita ulospäin ja koskaan vetämällä myöntäjän yksityistä tilaa sisäänpäin. Varmuuskopioi kaksi roolia erikseen, koska niiden arkaluonteisuus ja palautustarinat eroavat.

Peruutuksen jälkeen päivitä CRL-tiedosto, jonka palvelimen kokoonpano nimeää, ja lataa sitten palvelu uudelleen, jotta uudet yhteydet lukevat sen. Easy-RSA-dokumentaatio käsittelee työtilan rakennetta ja allekirjoitusprosessia; sen omistajuussäännöt ovat edelleen päätös isännästäsi. Varmista, mitä palvelu latasi komennolla openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate sen sijaan, että olettaisit uudelleenlatauksen ottaneen sen käyttöön.

Testi, joka todistaa eron

Tarkista kielteinen tapaus, älä vain toimivaa. Allekirjoita varmenne myöntäjän tililtä suunnitellusti ja varmista sitten, että sama tili ei voi käynnistää palvelua eikä lukea palvelimen yksityistä avainta. Varmista sitten, että daemonin tili ei voi lukea CA:n yksityistä avainta.

Nämä kolme tarkistusta vievät muutaman minuutin ja kestävät henkilöstövaihdokset, koska ne ovat väitteitä käyttöoikeuksista eikä tavasta. Kirjoita tulos muistiin polkuineen ja tileineen, jotka se kattoi, sekä päivämäärä, jolloin teit ne. Seuraava tämän käyttöönoton perijä johtaa muuten rajan uudelleen opetusohjelmasta, jossa sitä ei koskaan ollut. Päivätty merkintä on myös se, mikä tekee seuraavasta tarkastuksesta minuuttien eikä iltapäivän mittaisen.

Aiheeseen liittyvät artikkelit