Відкликаний сертифікат VPN усе ще підключається? Перевірте застосування CRL
Відкликані сертифікати все ще підключаються, коли CRL ніколи не доходить до перевіряльника. Перевірте в цьому порядку видавця, завантажений серійний номер, поведінку перезавантаження та активні сеанси.
Ви відкликали сертифікат, згенерували новий список, а старий профіль усе ще піднімає тунель. Сам відклик не зламаний: CRL — це підписана заява про те, що серійний номер більше не дійсний, і він змінює доступ лише тоді, коли компонент, що завершує TLS, завантажить його, для потрібного видавця, перш ніж ухвалити рішення про допуск. Саме тут лежить більшість таких випадків, і тому відклик і відмова — два різні факти.
Пройдіть п'ять перевірок нижче по порядку і зупиніться на першій, яка не виконується, бо кожна наступна припускає, що попередні правильні.
Перевірте, який компонент ухвалює рішення про допуск
Назвіть процес, який перевіряє клієнтський сертифікат, бо лише він може застосувати список. На сервері OpenVPN це сам демон, налаштований з crl-verify. В ocserv це рядок crl у ocserv.conf. У strongSwan вхідні дані — завантажені CRL разом з strictcrlpolicy. Проксі або пристрій, що завершує TLS перед VPN, також може бути справжнім перевіряльником, і якщо це так, демон за ним ніколи не бачить клієнтський сертифікат.
WireGuard належить до іншої категорії. У нього немає сертифікатів і немає списку відкликання; peer допускається за своїм відкритим ключем у конфігурації, тому припинення доступу означає видалення цього ключа. Якщо ви шукаєте CRL у розгортанні лише з WireGuard, такого механізму там немає.
Стережіться й пастки на боці клієнта. Клієнт, який відмовляється підключатися, бо йому не подобається сертифікат сервера, застосовує ланцюжок сервера, а не відкликає власні облікові дані. Сертифікат користувача відкликається лише там, де цей сертифікат перевіряється, а це майже завжди бік сервера.
Перевірте, для якого видавця підписано список
CRL обмежений одним видавничим CA. З кореневим і проміжним CA листові сертифікати походять від проміжного, тому значущий список — це CRL проміжного; список кореневого нічого не каже про ці листки. Перевіряльник, скерований на неправильний файл, бадьоро його розбирає, не знаходить відповідного запису й приймає все.
Підтвердьте відповідність, перш ніж торкатися демона. Видавець у сертифікаті має збігатися з subject списку:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateКоли обидва походять від одного CA, серійний номер, надрукований для сертифіката, — це значення, яке має з'явитися у списку. Якщо вони не збігаються, у вас неправильний CRL або неправильна його копія.
Термін дії належить до тієї ж перевірки. nextUpdate у минулому робить список застарілим, і перевіряльник, який відмовляє закрито, відхилить тоді кожного клієнта, а не лише відкликаного.
Перевірте, що серійний номер є в копії, завантаженій демоном
Відклик записує запис у базу CA, а повторна генерація записує новий файл. Жодна з дій не доходить до працюючого демона, який завантажив стару копію під час запуску. Вивантажте список і пошукайте серійний номер:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlПотім перевірте, як ваша реалізація підхоплює файл. OpenVPN читає шлях, заданий у crl-verify, один раз під час запуску, тому новий список потребує перезапуску або сигналу перезапуску; та сама опція, скерована на каталог, перечитується під час кожного з'єднання, і тому існує режим каталогу. strongSwan має перезавантажити свої облікові дані, наприклад за допомогою swanctl --load-creds. Те, що файл на диску правильний, і те, що перевіряльник його використовує, — два різні факти.
Перевірте політику для відсутнього або простроченого списку
Це рішення, яке багато розгортань ніколи не ухвалюють явно, і воно визначає, чи захищає відклик вас, чи замикає всіх зовні. Fail-closed означає, що без придатної інформації про відклик настає відмова; fail-open означає, що перевіряльник продовжує без неї. strongSwan надає вибір як strictcrlpolicy. OpenVPN з crl-verify відмовляється запускатися на файлі, який не може прочитати або розібрати, а прострочений список проявляється як помилка перевірки TLS про прострочений CRL, а не як мовчазний допуск.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
Який би напрямок ви не обрали, автоматизація важливіша за вибір: завдання, що перегенеровує CRL до nextUpdate, і попередження, коли розгорнута копія старіє, не дають жодній із політик стати інцидентом. Онлайн-перевірка через OCSP переносить свіжість на відповідач, але діє те саме правило, бо перевіряльник, не налаштований перевіряти відповідь, нічого не змінює.
Перевірте активний сеанс, потім копії ключа
Відклик оцінюється під час перевірки сертифіката, що відбувається під час підключення та під час перепогодження. Встановлений сеанс працює далі, доки не перепогодить, а значення OpenVPN за замовчуванням — раз на годину з reneg-sec 3600. Якщо людина має негайно вийти з мережі, завершіть сеанс разом із публікацією списку, а потім підтвердьте, що повторне підключення відхиляється.
Відокремте облікові дані від їхніх копій. Видалення профілю на одному ноутбуці не заважає іншій копії того самого закритого ключа автентифікуватися; саме відклик робить кожну копію непотрібною, і лише коли попередні перевірки виконуються. Видайте запасному пристрою власний сертифікат, щоб один можна було відкликати, не торкаючись іншого.
Перш ніж вважати справу закритою: перевірний компонент визначено, видавець списку збігається з видавцем листка, відкликаний серійний номер міститься в копії, яку демон справді завантажив, політика для відсутніх або прострочених списків обрана свідомо й контролюється, а активний сеанс завершено, а не перечекано. Формати, що лежать в основі всього цього, описано в RFC 5280.