Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Наши способы организации безопасного удалённого доступа к рабочим местам и корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Alexandertlt  
#1 Оставлено : 26 августа 2020 г. 12:40:17(UTC)
Alexandertlt

Статус: Участник

Группы: Участники
Зарегистрирован: 06.12.2019(UTC)
Сообщений: 10
Российская Федерация
Откуда: Tolyatti

Сказал(а) «Спасибо»: 1 раз
Здравствуйте. Нужно настроить stunnel на стороне сервера, чтобы сервер запрашивал сертификат клиента.
Не могу понять, как указать сертификаты клиентов, которым можно подключаться к серверу.

Пример stunnel.conf:

[gost]
client = no
accept = host:4430
connect = host:80
cert = 26009fffd5bfa4a3921730763b2d30d5b18b37a1
CApath = /clients
verifyPeer = yes
requireCert = yes

Подскажите, в каком формате должны находиться сертификаты КЭПов в каталоге /clients ?

В документации stunnel (https://www.stunnel.org/static/stunnel.html) указано что сертификаты должны называться в формате XXXXXXXX.r0.
Но с помощью c_rehash не получилось получить эти имена.

Подскажите, пожалуйста, как указать в stunnel сертификаты КЭП клиентов?

Отредактировано пользователем 26 августа 2020 г. 12:41:42(UTC)  | Причина: Не указана

Offline pd  
#2 Оставлено : 26 августа 2020 г. 14:28:14(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,000
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 26 раз
Поблагодарили: 164 раз в 142 постах
Автор: Alexandertlt Перейти к цитате
Здравствуйте. Нужно настроить stunnel на стороне сервера, чтобы сервер запрашивал сертификат клиента.
Не могу понять, как указать сертификаты клиентов, которым можно подключаться к серверу.

Пример stunnel.conf:

[gost]
client = no
accept = host:4430
connect = host:80
cert = 26009fffd5bfa4a3921730763b2d30d5b18b37a1
CApath = /clients
verifyPeer = yes
requireCert = yes

Подскажите, в каком формате должны находиться сертификаты КЭПов в каталоге /clients ?

В документации stunnel (https://www.stunnel.org/static/stunnel.html) указано что сертификаты должны называться в формате XXXXXXXX.r0.
Но с помощью c_rehash не получилось получить эти имена.

Подскажите, пожалуйста, как указать в stunnel сертификаты КЭП клиентов?

Работа идёт исключительно с хранилищами сертификатов КриптоПро CSP, не с файлами на диске.

Например, CApath = TrustedPeople означает, что у вас есть готовое хранилище сертификатов с именем TrustedPeople, в котором лежат сертификаты пользователей, которым разрешён вход.

Если CApath не указан, проверка пользовательских сертификатов происходит по цепочке до доверенного издателя в штатном хранилище корневых сертификатов root.

Отредактировано пользователем 26 августа 2020 г. 14:28:47(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил pd за этот пост.
Alexandertlt оставлено 26.08.2020(UTC)
Offline Alexandertlt  
#3 Оставлено : 26 августа 2020 г. 16:11:55(UTC)
Alexandertlt

Статус: Участник

Группы: Участники
Зарегистрирован: 06.12.2019(UTC)
Сообщений: 10
Российская Федерация
Откуда: Tolyatti

Сказал(а) «Спасибо»: 1 раз
Спасибо! Совет помог. Заработало!Dancing
Offline two_oceans  
#4 Оставлено : 27 августа 2020 г. 5:39:25(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,039
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 68 раз
Поблагодарили: 236 раз в 222 постах
Как интересно. По названию параметра предполагал, что разрешение распространяется на все сертификатов определенного УЦ. А оказывается можно одной группе сертификатов (в указанном хранилище) разрешить вход, а другим сертификатам, выданным тем же УЦ, отказать? Или возможны оба сценария (разрешить всем от одного издателя и разрешить выборочно от одного издателя), тогда как настроить? Зависит от того сертификат УЦ в хранилище или конечный сертификат?

Отредактировано пользователем 27 августа 2020 г. 5:41:00(UTC)  | Причина: Не указана

Offline pd  
#5 Оставлено : 27 августа 2020 г. 12:41:40(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,000
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 26 раз
Поблагодарили: 164 раз в 142 постах
Автор: two_oceans Перейти к цитате
Как интересно. По названию параметра предполагал, что разрешение распространяется на все сертификатов определенного УЦ. А оказывается можно одной группе сертификатов (в указанном хранилище) разрешить вход, а другим сертификатам, выданным тем же УЦ, отказать? Или возможны оба сценария (разрешить всем от одного издателя и разрешить выборочно от одного издателя), тогда как настроить? Зависит от того сертификат УЦ в хранилище или конечный сертификат?

Не совсем, базовая проверка до доверенного корня происходит всегда (если проверка активна verify != 0).

Если указан CApath, сертификат будет дополнительно проверен на вхождение в хранилище сертификатов CApath.

Есть ещё альтернативный путь проверки по списку, через параметры checkSubject/checkIssuer.

Это строки в формате X.500 (RFC 2253, CERT_X500_NAME_STR) их может быть больше одной в конфигурации, получается тоже список доступа, но без сопоставления сертификатов побайтно, что может быть более удобно, так как перевыпуск сертификата не повлияет на доступ, ибо subject/issuer останутся неизменными.
Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил pd за этот пост.
two_oceans оставлено 27.08.2020(UTC)
Offline two_oceans  
#6 Оставлено : 28 августа 2020 г. 6:13:59(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,039
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 68 раз
Поблагодарили: 236 раз в 222 постах
Автор: pd Перейти к цитате
Не совсем, базовая проверка до доверенного корня происходит всегда (если проверка активна verify != 0). Если указан CApath, сертификат будет дополнительно проверен на вхождение в хранилище сертификатов CApath.
То есть берется объединение множеств допущенных базовой проверкой и CApath проверкой? Правильно понимаю?

Тогда теоретически можно войти и сертификатами от всех аккредитованных УЦ (когда установлен сертификат Минкомсвязи в корневые) и сертификатами от всех штатных корневых УЦ из поставки Windows. Смысл проверки резко снижается, если можно войти вообще любым действительным сертификатом. Выходит, чтобы работал только CApath надо заведомо "провалить" базовую проверку? Хотелось бы иметь возможность запретить часть прошедших базовую проверку для конкретного соединения. Как минимум запретить не гост-2012 сертификаты из поставки Windows.
Цитата:
Есть ещё альтернативный путь проверки по списку, через параметры checkSubject/checkIssuer.
Если это тоже работает в дополнение к базовой проверке, то берется пересечение или объединение множеств?
Цитата:
перевыпуск сертификата не повлияет на доступ, ибо subject/issuer останутся неизменными
Может поменяться порядок компонент, если сменился экземпляр/шаблоны УЦ (многие аккредитованные УЦ делают новые экземпляры УЦ ежегодно, прекращая выпуск конечных сертификатов на "прошлогоднем" экземпляре). У разных УЦ точно разный порядок компонент. Сертификаты разных назначений также могут отличаться по наличию/порядку некоторых компонент. Отдельная тема про кавычки в наименовании организации - УЦ их кодируют совершенно разными строками. Безусловно, это интересный способ, но от замены строк при смене сертификатов скорее всего не спасет, если не выпускать сертификаты на подконтрольном внутреннем УЦ.

Вопрос по сравнению - должен совпадать весь список в определенном порядке, совпадать весь список в произвольном порядке или возможен поиск по подстроке (отдельному компоненту)? Для отечественных сертификатов поиск исключительно по огрн/снилс/email был бы интересен. Опять же вопрос как компонент огрн/снилс указывать - латинскими буквами, кириллицей или оидом? Если проверка исключительно кодом Майкрософт, то полагаю порядок компонент важен и огрн/снилс указывать оидом или строкой согласно регистрации оида в реестре.
Offline pd  
#7 Оставлено : 28 августа 2020 г. 10:19:04(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,000
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 26 раз
Поблагодарили: 164 раз в 142 постах
Автор: two_oceans Перейти к цитате
Если это тоже работает в дополнение к базовой проверке, то берется пересечение или объединение множеств?

Во всех случая проверки дополняют друг друга, но не исключают, то есть должны пройти все проверки указанные в конфигурации.

Автор: two_oceans Перейти к цитате
Может поменяться порядок компонент...

Согласно указанному ранее RFC, subject/issuer указанные в формате X.500 всё таки должны переживать перевыпуск.

Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил pd за этот пост.
two_oceans оставлено 28.08.2020(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.