Держите ключ подписи 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.

Эти три проверки занимают несколько минут и переживают смену персонала, потому что это утверждения о правах, а не о привычке. Запишите результат вместе с путями и аккаунтами, которые он охватил, и датой, когда вы их выполняли. Иначе следующий человек, унаследовавший это развёртывание, заново выведет границу из руководства, где её никогда не было. Запись с датой — это ещё и то, что делает следующую ревизию делом нескольких минут, а не половины дня.