Почему не полностью отзывается клиент?

Question

[Владимир Юрченков]

Есть кластер из 2х серверов, при отзыве сертификата на основном 1 сервере (там же где и создавался клиент), клиент все равно продолжает подключаться ко 2 серверу. Как отозвать и на 2м сервере, там же даже этих ключей нет.

Answer 1

[Ziptar]

Я не помню поддерживает ли OVPN CRL*, но если да - сформировать с помощью CA на первом сервере CRL (список отзыва сертификатов) - и показать его второму серверу так, чтобы он понял.
Иначе - никак.
*вообще должен, реагирует же первый сервер как-то на отзыв

>там же даже этих ключей нет
Ну, один ключ то всё-таки есть - открытый ключ CA с первого сервера. Он вместе с сертификатом [открытого ключа] всегда рядышком. И вот потому, что он там есть - сервер доверяет всем клиентам, предъявляющим ему сертификаты, удостоверенные закрытым ключом от пары CA. Но знать не знает о том, что какие-то из этих сертификатов были отозваны. И вот это ему надо показать. Для этого и существуют CRL.

Comments

[Владимир Юрченков]

А если ему передать index файл, где проставляются метки отзыва R?

[Ziptar]

Владимир Юрченков,
щито, простите?
Я не знаю какую имплементацию OVPN и PKI вместе с ним вы используете; в стандартизированной терминологии, оторванной от конкретных реализаций - я расписал как что и зачем. Если в используемом вами PKI вместо CRL есть некие index-файлы с некими R метками - мне об этом ничего неизвестно.
В норме CRL должны быть подписаны закрытым ключом CA точно так же, как и выпускаемые этим CA сертификаты. Но может в случае OVPN в той реализации, которую вы используете, будет достаточно простого списка - не знаю.

Answer 2

[res2001]

Что клиент подключается к серверам с разными ключами? Ну тогда надо отзывать и второй клиентский ключ.

Вообще в вашей конфигурации нет смысла создавать клиентам разные ключи. Вам ничто не мешает синхронизировать клиентские ключи на серверах, точно так же как и список отзыва.
Кстати для списков отзыва есть протокол OCSP, позволяющий проверять списки отзывов по сети. В этом случае отпадает необходимости передавать файлы со списком отзыва по серверам. Но тут, конечно, надо заморочиться с поднятием и поддержкой OCSP сервера и нужно указывать URL OCSP при создании сертификатов.

Comments

[Ziptar]

OVPN-сервер ничего не знает о клиентских ключах, и знать не должен. Знает только PKI. OVPN серверу надо знать только сертификат CA и список отзыва, но не клиентские ключи и сертификаты.

[res2001]

Ziptar, Да неужели? Пойдите ка что-нибудь почитайте как организуется шифрование/расшифрование в инфраструктуре PKI и какие ключи для этого требуются. А так же и по смежной теме - установка и проверка электронной подписи. Openvpn работает на тех же принципах.

Под синхронизацие клиентских ключей на серверах, я подразумевал синхронизацию клиентских сертификатов, которые в PKI содержат в т.ч. и публичные ключи.

[Ziptar]

Что касается OSCP - не обязательно. В свойствах сертификата указываются точки распространения списка отзывов (CDP), и разные реализации PKI могут уметь (а могут не уметь) выгружать CRL полностью через них, причем вариации протоколов ограничены только возможностями PKI - хоть самба, хоть http, хоть нфс - что умеет, в общем. А сам OSCP не про списки отзывов как таковые, в общем то.

[Владимир Юрченков]

@Что клиент подключается к серверам с разными ключами?@

Нет. Настройку сервера осуществлял стандартным способом, потом просто брал конфиг 1 сервера и ставил на 2й, в конфиге прописывал еще один ip и все. Все создается на первом сервере. После отзыва клиента, подключение идет, но так как недоступен 1 сервере, его перебрасывает на 2й. Там же тоже как-то проверятся он должен.

[Ziptar]

res2001, читай внимательно что тебе пишут, а писал я тебе про ovpn-сервер, а не про PKI. Центру сертификации необходимо знать, какие сертификаты им выпущены. Тому, что лишь проверяет подпись центра сертификации - в данном случае это OVPN сервер - этого знать не нужно.
И нет ни малейшего смысла тащить PKI вместе с CA, его закрытым ключом, и списком сертификатов им выпущенных, на второй сервер.

[res2001]

Владимир Юрченков, Вам надо перенести обновленный список отзыва на второй сервер.
openvpn должен быть настроен на проверку списка отзыва (опция crl-verify).

[res2001]

Ziptar,

И нет ни малейшего смысла тащить PKI вместе с CA на второй сервер.

Как минимум список отзыва надо тащить, если он проверяется не через OSCP. Весь PKI - не нужно. ЦА и приватный ключ ЦА вообще должен быть где-то в другом месте, клиентские приватные ключи только у клиентов (серверные только на серверах) и генерировать их клиент должен самостоятельно и передавать ЦА только запрос на сертификат ... ну в общем все как в учебниках по PKI и X.509, но в жизни часто это не так.

[Ziptar]

res2001, про список отзыва я написал просто в самом начале первым же ответом.
Ты же писал про синхронизацию клиентских ключей - а она просто не нужна, ни в отношении открытых, ни в отношении закрытых.

>но в жизни часто это не так.
Ага, но это только то, что касается наших гос. УЦ - в жизни. В реальной. А в онлайновой, так сказать, все вполне соответствует чаще, чем не соответствует.

[res2001]

Ziptar,

Ты же писал про синхронизацию клиентских ключей - а она просто не нужна, ни в отношении открытых, ни в отношении закрытых.

Согласен. Про синхронизацию ключей перебор был. Погорячился.
Но с клиентскими сертификатами openvpn сервер все равно имеет дело иначе криптография не заработает, видимо они передаются при подключении клиента. Это я к твоей фразе

OVPN-сервер ничего не знает о клиентских ключах, и знать не должен

Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.

Владимир Юрченков, Ты же наверняка использовал скрипты easy-rsa для генерации ключей. Там же можно генерировать и список отзыва и это не index файл. Вот этот файл нужно притащить на второй сервер и положить по пути, указанному в опции crl-verify конфига openvpn.

[Ziptar]

res2001,
>видимо они передаются при подключении клиента
Конечно, само собой. Открытый ключ клиента точно передается, закрытый может использоваться для подписи челленжа - стандартная история - но конкретику надо смотреть отдельно в этом моменте.

>Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.
А, окей, мы просто друг друга не поняли. Разумеется, я имел в виду в "холодном" состоянии.