Тримайте ключ підпису 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.

Ці три перевірки займають кілька хвилин і переживають зміну персоналу, бо це твердження про права, а не про звичку. Запишіть результат разом зі шляхами й обліковими записами, які він охопив, і датою, коли ви їх виконували. Інакше наступна людина, що успадкує це розгортання, знову виведе межу з посібника, де її ніколи не було. Запис із датою — це також те, що робить наступний огляд справою кількох хвилин, а не півдня.