Нові входи у VPN не працюють, хоча сертифікати чинні: перевірте CRL

Сертифікати, яким лишилося ще кілька місяців, і входи, що одразу не працюють, указують на два різні об’єкти з двома різними годинниками. Сервер відхиляє з’єднання, бо список відкликаних сертифікатів, до якого він звертається, уже перевищив власну дату завершення терміну дії, а не тому, що сертифікати користувачів застаріли. Поновлення сертифіката користувача нічого не дає для цього списку.

Розділення цих двох розкладів і є всією діагностикою, і воно змінює те, яким має бути виправлення.

Два годинники, і лише один із них — сертифікат

Сертифікат несе вікно дійсності. Список відкликаних сертифікатів несе власне вікно, а також видавця й підпис, і верифікатори відмовляються довіряти списку, час наступного оновлення якого минув. Коли це трапляється, клієнт подає цілком чинний сертифікат, а сервер усе одно розриває з’єднання з повідомленням про список. Користувачі читають це повідомлення як «сертифікат прострочено», що надсилає запит на поновлення не туди.

Ці два об’єкти мають і різних власників: сертифікат походить від CA, яка його видала, тоді як список за розкладом генерує той, хто цією CA керує. Користувач не може його оновити, і повторне видавання сертифікатів не може його подовжити.

Прочитайте список, який служба справді завантажує

Почніть із робочої конфігурації, а не з файлу, який ви очікуєте. Шлях crl-verify може бути абсолютним, відносним до профілю або копією, вбудованою в образ, і верифікатор читає саме цю копію. Огляньте її на місці за допомогою openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate і порівняйте дати з годинником сервера.

Потім підтвердьте, що файл справді той, який використовується: перевірте його підпис за допомогою openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, який повідомляє результат перевірки, а не тихо друкує поля. Список, підписаний іншою CA, або застаріла копія, залишена в другому каталозі, не працює так само, як прострочений.

Згенеруйте заново з бази даних відкликань, а не з нуля

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

Крок генерування тримайте в контролі версій разом з рештою інструментів CA, щоб інтервал і ключ підпису були задокументовані, а не запам’ятовані. Достатньо запису в операційному посібнику, який називає команду, підписувача й ціль публікації. Будь-хто на чергуванні може потім згенерувати список заново, не вгадуючи, який файл індексу є авторитетним. Серійний номер списку й час наступного оновлення збережіть разом із записом про розгортання.

Розгорніть там, куди дивиться верифікатор

Скопіюйте новий список за шляхом, який читає служба, встановіть власника й режим так, щоб службовий обліковий запис міг його читати, а інші ні, і перезавантажте або перезапустіть згідно із задокументованою поведінкою. Якщо демон кешує список під час запуску, заміна файлу без перезавантаження не змінить нічого, що помітить працюючий процес. Підтвердьте часову позначку, яку процес повідомляє після перезавантаження.

Якщо клієнтів перевіряють кілька служб, розгорніть список на кожній із них. Оновлення однієї кінцевої точки й залишення іншої зі старою копією створює збій, який з’являється лише в користувачів, що потрапляють на другу. Тримайте короткий перелік цих кінцевих точок у тому самому операційному посібнику. Після впровадження перевірте дату списку, яку повідомляє кожна з них, замість того щоб припускати, що копія дійшла.

Зробіть наступний дедлайн видимим до того, як він мине

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

Після розгортання перевірте обидва напрямки: дозволений користувач з’єднується, а відома відкликана ідентичність усе ще не проходить. Друга перевірка ловить неповне повторне генерування, і для неї потрібна одна команда проти тестового профілю, який ви тримаєте саме для цієї мети.