Држете го клучот за потпис на CA на OpenVPN надвор од /etc/openvpn

Два директориуми што изгледаат слично во упатство вршат сосема различни работи. Едниот ја држи сертификатната власт: нејзиниот приватен клуч, бројачот на сериски броеви и записот за сѐ што потпишала. Другиот го држи она што на демонот му треба за да стартува и да им служи на клиентите. Да ги држите двете на исти хост под иста сметка е погодно за едно попладне и скапо за остатокот од животот на распоредувањето, зашто демонот тогаш работи покрај единствениот клуч што може да создаде каков било идентитет.

Што содржи работниот простор на CA

Директориумот PKI е состојба на издавачот, не конфигурација. Ги содржи приватниот клуч и сертификатот на CA, датотека со сериски броеви, индекс на издадени сертификати и материјалот за секој идентитет создаден од нив.

Потпишувањето барање ја менува таа состојба, затоа работниот простор ѝ припаѓа на сметка под административна контрола на хост каде што не работи VPN услугата. Секој што може да го прочита приватниот клуч на CA може да издаде сертификат на кој серверот ќе му верува, па заштитата на клучот е целиот модел на доверба во една датотека. Неговото копирање на второ место за да се заштеди чекор создава второ нешто за заштита и второ нешто за заборавање. Секој потпис исто така го зголемува серискиот број и додава запис во индексот, затоа работниот простор е една копија од состојбата, а не папка со датотеки.

Јавниот сертификат на CA е различен. Тој е наменет за распределба и токму него клиентите и серверите го користат за да се проверуваат меѓусебно.

Што чита демонот при стартување

Серверот што работи троши мал сет: сопствен сертификат, сопствен приватен клуч, сертификатот на CA за проверка на партнерите и материјалот за клучеви што го бара избраниот режим. Ги чита тие патеки при стартувањето и повторно при превчитувањето.

Сопственоста треба да се оценува спрема единицата што навистина стартува, а не спрема интерактивна root обвивка. Објавеното изолирање може да направи дел од датотечниот систем само за читање или невидлив, дури и кога рачниот тест како root успева.

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

Третата линија е таа што луѓето ја прескокнуваат. Таа ја прашува сопствената сметка на демонот дали може да го прочита клучот, а тоа е единствената верзија на прашањето што е важна откако ќе се спушти привилегијата. Излез со нула како root не ви кажува ништо за тоа што се случува по спуштањето.

Двете патеки на дефект вреди да се разделат пред да смените каква било дозвола. Неуспехот при потпис упатува на директориумот PKI, дозволата за пребарување во неговите родителски директориуми и сметката што го извршува издавачот. Неуспехот при стартување упатува на единицата, нејзиниот работен директориум и патеките наведени во конфигурацијата на серверот. Правењето на целото дрво читливо за сите не поправа ниту едно од двете и ја отстранува границата од која зависат двете.

Зошто копирањето на клучот на CA на серверот подоцна пропаѓа

Копијата обично започнува како чекор за отстранување грешки: некој сака да обнови клиент на хостот со VPN, па клучот на CA слетува во /etc/openvpn и обновувањето успева. Непосредната задача успева, а границата ја нема.

Потоа серверот се архивира и органот за потпис се придружува на резервните копии. Снимка, пакет за поддршка или копија од конфигурацискиот директориум сега ја носи способноста да издава доверливи идентитети додека CA е важечки. Кој ја држи таа копија може да создаде сертификат за секое име што серверот го прифаќа, вклучно и имиња што никогаш не биле издадени. Единствениот запис за тоа издавање е оној што тие ќе изберат да го сочуваат.

Опоравувањето од таквата состојба не е прашање на бришење датотека. Мора да одлучите дали клучот бил изложен, да го завртите CA ако бил, и да ја распределите довербата повторно на секој партнер. Одделен работен простор ја избегнува целата таа расправа.

Сметки, директориуми, резервни копии

Дајте му на издавачот сопствена сметка и домашна папка, држени надвор од хостот со VPN каде што е практично. Дајте му на демонот друга сметка, со пристап за читање до распоредениот материјал и без пристап за пишување до ништо што издава сертификати. Распоредувајте со копирање јавни сертификати нанадвор и никогаш со влечење на приватната состојба на издавачот навнатре. Правете резервни копии од двете улоги одделно, зашто нивната чувствителност и нивните приказни за враќање се разликуваат.

По отповикување, ажурирајте ја датотеката CRL што ја наведува конфигурацијата на серверот, потоа превчитајте ја услугата за новите врски да ја прочитаат. Документацијата на Easy-RSA го покрива распоредот на работниот простор и текот на потпишување; правилата за сопственост околу него остануваат одлука за вашиот хост. Потврдете што вчитала услугата со openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate наместо да претпоставите дека превчитувањето го зело.

Тест што ја докажува поделбата

Проверете го негативниот случај, не само работниот. Потпишете сертификат од сметката на издавачот како што е замислено, па потврдете дека истата сметка не може да ја стартува услугата или да го прочита приватниот клуч на серверот. Потоа потврдете дека сметката на демонот не може да го прочита приватниот клуч на CA.

Тие три проверки траат неколку минути и преживуваат промени на персоналот, зашто се изјави за дозволи, а не за навика. Запишете го резултатот со патеките и сметките што ги опфатил, плус датумот кога сте ги извршиле. Инаку следниот човек што ќе го наследи ова распоредување повторно ќе ја изведе границата од упатство што никогаш немало таква. Датиран запис е и она што го прави следниот преглед минути, а не попладне.