Отозванные сертификаты продолжают работать., RouterOS
check
Guest
0
03.07.2015 08:20:00
ROS 6.27 включил сервер OpenVpn. Галочка «Require Client Certificate» — включена. Все сертификаты (ca, server и client) сгенерированы ROS (System-Certificates). Openvpn клиент (Windows GUI) подключается успешно. Я отозвал клиентский сертификат — кнопка «Revoke» (System-Certificates). Статус этого сертификата сменился с «KIT» на «KRT». Но Openvpn клиент (Windows GUI) всё равно подключается к Mikrotik OpenVPN серверу, используя этот отозванный сертификат. Это нормально? Может, надо подождать какое-то время? Если да — как можно заставить отозванный сертификат перестать работать? Спасибо.
vbarinov
Guest
0
10.08.2020 16:54:00
Какой IP-адрес нужно указывать для CRL при создании сертификата CA? Внутренний 192.168…, 127.0.0.1 или внешний? Я указал внешний, но это не работает. Отозванный сертификат продолжает работать.
vbarinov
Guest
0
11.08.2020 15:37:00
Окей, последний попытка — 127.0.0.1 — то же самое, отозванный сертификат всё равно работает. Обновился до 7.1beta1 — ситуация не изменилась.
sindy
Guest
0
11.08.2020 20:32:00
Сторона, которая проверяет сертификат, представленный удалённым узлом, должна иметь возможность скачать CRL с веб-сервера, а центр сертификации (CA) должен иметь возможность обновлять его там с новыми отзывами. Так что если вы используете 127.0.0.1, я предполагаю, что CA, VPN-сервер, проверяющий сертификаты клиентов, и CRL-сервер находятся на одной машине. В этом случае на машине должен быть включён сервис /ip “www”, а в брандмауэре должно быть разрешено принимать входящие соединения на TCP-порт 80, по крайней мере с 127.0.0.1.
Deantwo
Guest
0
08.09.2020 11:20:00
Правильно ли я понимаю, что установить ca-crl-host можно только при подписании CA-сертификата? Значит, мой четырёхлетний самоподписанный сертификат придётся выбросить и создавать новый CA, если я хочу добавить ca-crl-host? Честно говоря, я уже проходил через это четыре года назад, когда переходил на текущий CA-сертификат, и тогда мне пришлось работать с двумя разными CA-сертификатами. Очень не хочется повторять это снова, ведь для нового CA-сертификата нужен отдельный роутер, потому что OpenVPN-сервер на роутере может использовать только один серверный сертификат одновременно. Есть ли вообще какое-то решение, чтобы обойтись без создания нового CA-сертификата? Или хотя бы более простой способ миграции, чтобы не менять все выданные сертификаты сразу?
sindy
Guest
0
13.10.2021 20:40:00
Итак, я вернулся к этому вопросу и обнаружил, что старое (wiki) руководство крайне недостаточно, а новое (Confluence) даже вводит в заблуждение, советуя самим подписывать все сертификаты. Нормальная процедура — создать сертификат Удостоверяющего Центра (CA), который сам себя подписывает, и использовать его для подписи всех сертификатов серверов и клиентов.
Ниже описано, что проверено на CHR с ROS 6.47.9. При подписании сертификата CA можно указать IP-адрес или FQDN, который будет использоваться для создания полного URL списка отозванных сертификатов (CRL), включенного в содержимое создаваемого CA-сертификата, с помощью параметра ca-crl-host. Если не планируете сложную конфигурацию, то это должен быть один из собственных IP-адресов маршрутизатора, который выполняет роль CA, либо FQDN, разрешающийся в один из этих адресов.
Чтобы узнать, какой URL в итоге получится, нужно экспортировать CA-сертификат и открыть его в любом просмотрщике сертификатов. Например, я указал ca-crl-host=crl.home.me, и в итоге получил URL ; судя по всему, число — это порядковый номер сертификата, который подписывает маршрутизатор, неважно — CA-сертификат или любой другой. Этот файл создается маршрутизатором и обновляется каждый раз при отзыве сертификата, подписанного этим CA, но в файловой системе он недоступен.
Можно передать список IP-адресов или FQDN, разделённых запятыми, но фактически используется только первый в списке — в сертификате только один URL. В отличие от того, что я видел на скриншоте в одном из постов на другом форуме, ссылка на этот файл не появляется динамически в таблице /certificate crl на самом маршрутизаторе; её нужно добавить вручную, используя отпечаток CA-сертификата и извлечённый из него URL — так же, как для любого внешнего CRL, который должен использовать маршрутизатор.
Также необходимо включить параметры crl-download и crl-use со значением yes в разделе /certificate settings. И только теперь сам маршрутизатор, например действующий как IPsec-ответчик, сможет проверять, что сертификаты инициатора не отозваны.
Вышеперечисленного достаточно, чтобы маршрутизатор, выступающий одновременно VPN-сервером и CA, мог отвергать входящие подключения от клиентов с отозванными сертификатами. Но если CA не находится на том же сервере, что и VPN, сервер должен уметь получать CRL с CA, и в идеале клиенты тоже должны иметь такую возможность, ведь сервер теоретически тоже могут украсть.
К сожалению, сейчас нельзя отделить HTTP-сервер для выдачи CRL от HTTP-сервера для управления. Поэтому если хотите ограничить доступ к управлению, но при этом сделать открытым доступ к CRL, придется использовать регулярные выражения для проверки layer7-protocol в URL GET-запросах и сбрасывать соединения, пытающиеся получить доступ к другим файлам с непозволенных источников.
