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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Александр_35  
#1 Оставлено : 27 августа 2021 г. 10:06:24(UTC)
Александр_35

Статус: Новичок

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

Добрый день!

Собственно изначально я делал с помощью BouncyCastle и доработоной мной библиотекой get_cpccert_mod
Получал сертификат\закрытые ключи и использовал далее в своих целях.

Теперь возникла потребность сохранения контейнера в реестр и установки из него сертификата, программным способом, без доступа к удалённой машине.
Я реализовал метод на сервисе, в который пользователь POST запросом отправляет архив с контейнером, на удалённой машине архив распаковывается и собственно тут у меня сложности.

С тем как и где хранить контейнер в реестре я вроде разобрался, создаю раздел в корневом разделе реестра HKEY_LOCAL_MAACHINE\...\Crypto Pro\...\KEYS\{sid}\ и записываю туда файлы из архива.
Теперь мне необходимо как то установить из этого архива сертификат и связать его с закрытым ключом.

Помогите с советом как это вообще правильнее сделать. Дело в том , что ходить постоянно на удаленную машину очень сложное занятие, сертификатов достаточно много.

UPD. программа написана с использованием CryptoPro Net. и CSP 4.0

Отредактировано пользователем 27 августа 2021 г. 10:49:14(UTC)  | Причина: Не указана

Offline two_oceans  
#2 Оставлено : 27 августа 2021 г. 13:39:03(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Добрый день.
Что-то слегка перепутали местами? У меня
Код:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Crypto Pro\Settings\Users\{sid}\Keys\{container_name}]
в котором 6 параметров. Часть "Wow6432Node\" только на 64-разрядных системах. Если создаете раздел пользователя программно, то потом стоит установить, начиная с {sid} корректные разрешения на полный доступ (только конкретному пользователю, системе, создателю-владельцу, без наследования от родительского раздела).

Тоже как раз разбираюсь с подобной задачей. Правда я пошел в сторону хранения контейнера в папке на диске, но часть с установкой сертификатов из контейнера "застряла".
В дальнейшем думаю это автоматизировать примерно так - специальная программка (клиентская часть), пользователь видит список сертификатов, может запросить у администратора ИБ согласование доступа через серверную часть. Администратор ИБ согласует в (административная часть) и (административная часть) предоставляет полномочия на папку-контейнер для этого сертификата в общей папке. (клиентская часть) получает сообщение о согласовании, создает символическую ссылку и устанавливает сертификат пользователю.

Отредактировано пользователем 27 августа 2021 г. 14:03:22(UTC)  | Причина: Не указана

Offline two_oceans  
#3 Оставлено : 27 августа 2021 г. 13:52:58(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
В плане централизованного развертывания все сводится к тому, что основные методы удаленного управления требуют прав администратора, а установка должна проводиться от конкретного пользователя (вариант симуляции установки в хранилище искусственной загрузкой профиля пользователя не рассматриваю, так как это практически то же самое плюс "изобретение велосипеда еще раз"). у нас пользователи работают под учетными записями домена, в домене их учетные записи ограничены, но на конкретный компьютер выданы повышенные права.

Подробнее выходит так: если компьютер в домене, то группа "администраторы" домена включена в группу "администраторы" компьютера, аналогично "пользователи" домена в "пользователи" компьютера. Выдавая права на конкретный компьютер, включаем пользователя домена в группу "администраторы" компьютера. Выходит такой "локальный администратор", но одновременно "пользователь" с точки зрения домена = "локальный администратор" из домена.

Однако для "локальных администраторов" по умолчанию включены политики ограничения их доступа из сети. На новых ОС только самый первый "суперадминистратор" может подключиться к стандартным скрытым ресурсам, создаваемые потом "локальные администраторы" прав доступа не имеют. Утилита psexec, похоже по этой же причине вываливается с ошибкой если указать данные такого "локального администратора" из домена, хотя отлично работает при подключении от имени доменного администратора. Отключать политики, полагаю, не имеет смысла с точки зрения безопасности, ведь нам, казалось бы, надо всего лишь запустить команду или вызвать CryptoApi от имени определенного пользователя (и даже не нужны права администратора этого пользователя! К своему профилю он и с ограниченными правами имеет доступ).

Вижу такие направления решения этой задачи:
1) использование runas (и вообще вторичный вход) - пока все попытки использовать напрямую обламываются;
2) планировщик задач (вариация вторичного входа, не спорю) - создается задача с тригером на определенное событие, выполняющая некий батник от имени пользователя. Батник можно защитить от изменений высоким уровнем целостности. Главное, что залогинившись под доменным администратором через psexec мы сможем и записать батник и создать задачу и записать событие.
3) клиентская - серверная - администраторская архитектура приложения развертывания. Пользователь либо сам запускает программку либо программка висит в автозапуске и выступает как "локальный агент" для команд администратора с сервера. Напоминает построение ботнета, но в благих целях. Естественно тут также можно ограничить количество команд, чтобы антивирусы не считали новым трояном.
Пока что я копаю в строну способов 2 и 3 - думаю создать что-то вроде своей телеметрии и заодно распространять сертификаты.

Отредактировано пользователем 27 августа 2021 г. 13:56:20(UTC)  | Причина: Не указана

Offline Александр_35  
#4 Оставлено : 27 августа 2021 г. 14:05:46(UTC)
Александр_35

Статус: Новичок

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

Интересное решение, но к сожалению СОБ согласовал хранение контейнеров в реестре текущего пользователя. В принципе мне не создаст труда провести все требуемые операции по сохранению контейнера из поставляемого архива. Самая моя сложность это как установить сертификат из контейнера и связать их.
Нужно ли в таком случае извлекать сертификат их контейнера?
А потом через certmgr.exe связывать с контейнером. Для меня это пока непонятно, в какую сторону надо двигаться.

В одной теме нашёл пример, но что с этой информацией делать????
certmgr.exe -install -store uMy -file "D:\key\key_test.cer" -certificate -container "\\.\REGISTRY\container_name" -silent -inst_to_cont

К счастью у меня веб сервис вертится под администратором и проблем с всякими админским телодвижениями нет.

Отредактировано пользователем 27 августа 2021 г. 14:08:02(UTC)  | Причина: Не указана

Offline two_oceans  
#5 Оставлено : 27 августа 2021 г. 14:17:31(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Автор: Александр_35 Перейти к цитате
... Нужно ли в таком случае извлекать сертификат их контейнера?
А потом через certmgr.exe связывать с контейнером. Для меня это пока непонятно, в какую сторону надо двигаться.

В одной теме нашёл пример, но что с этой информацией делать????
...
К счастью у меня веб сервис вертится под администратором и проблем с всякими админским телодвижениями нет.
Проблема не с "админскими телодвижениями", а с тем, что надо запустить certmgr (либо другую программу установки сертификата) от имени конечного пользователя - не администратора. Запустив от администратора вы поставите сертификат администратору, а не пользователю. Пользователь потом не увидит сертификата в своем хранилище.

Если Вы уже пересылаете контейнер с установленным сертификатом, то половина опций не нужна (извлекать для certmgr.exe не требуется), -store uMy и -certificate уже выбраны по умолчанию, c -silent часто проблемы, я добавил пин-код и тип провайдера. В итоге у меня вышло:
Код:
certmgr.exe -install -container "\\.\REGISTRY\container_name" -pin 1234 -provtype 80
То есть сервис теперь должен запустить эту команду от имени другого пользователя. Тут и начинаются танцы с планировщиком и событиями.

В теории служба может олицетворять другого пользователя, что по идее еще проще: как служба psexec олицетворяет администратора. Ссылку на нечто подобное видел, но так сразу не найду.

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

Offline Александр_35  
#6 Оставлено : 27 августа 2021 г. 14:29:36(UTC)
Александр_35

Статус: Новичок

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

А мне и не требуется чтобы сертификаты хранились под конечным пользователем, у меня выборка сертификатов происходит в зависимости от требуемого ОГРН.
Поэтому попробую я складывать файлы контейнера в реестр и далее устанавливать из него сертификаты.
Offline two_oceans  
#7 Оставлено : 27 августа 2021 г. 14:36:40(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
И подписывать будете в службе? Тогда и в реестр по идее надо вносить под сид пользователя от которого работает служба. Ну а далее просто запускаете команду, на winapi функция CreateProcess.

Либо можно и устанавливать сертификат через winapi - нужно создать сертификат из файла, например, проставить в полученный контекст ссылку на контейнер и добавить в хранилище.

Если же подписываете не в одной службе, то придется ставить сертификаты в хранилище - большая часть программ написанных для работы с КриптоПро предполагает что сертификат есть в хранилище того пользователя, который подписывает.

Отредактировано пользователем 27 августа 2021 г. 14:39:16(UTC)  | Причина: Не указана

Offline Александр_35  
#8 Оставлено : 27 августа 2021 г. 14:51:57(UTC)
Александр_35

Статус: Новичок

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

Всё верно, той же службой и подписывается, поэтому я в первом посте написал про SID юзера в реестре.
Немного не понял из какого файла сертификат надо получить?
header.key я в принципе уже дербанил для получение сертификата и даже без проблем его устанавливал.

А вот "например, проставить в полученный контекст ссылку на контейнер и добавить в хранилище" для меня не очень очевидная процедура.
Offline TolikTipaTut1  
#9 Оставлено : 27 августа 2021 г. 16:03:26(UTC)
TolikTipaTut1

Статус: Активный участник

Группы: Участники
Зарегистрирован: 05.07.2018(UTC)
Сообщений: 233

Сказал(а) «Спасибо»: 30 раз
Поблагодарили: 24 раз в 21 постах
https://www.cryptopro.ru...aspx?g=posts&t=14724

https://www.cryptopro.ru....aspx?g=posts&t=6125

Похожие темы (на мой субъективный взгляд), связанные с установкой сертификата и прописыванием пути вручную

Отредактировано пользователем 27 августа 2021 г. 16:11:17(UTC)  | Причина: Не указана

Offline two_oceans  
#10 Оставлено : 29 августа 2021 г. 5:15:18(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Да, похожие, хоть и давние. Не так давно была тема с перечислением контейнеров, где бились чтобы на сертификаты в реестре пин не кэшиоровался и сертификат в хранилище не добавлялся, но при этом функции работали. Там снова все моменты разбирали, уже на версиях поновее.
Цитата:
А вот "например, проставить в полученный контекст ссылку на контейнер и добавить в хранилище" для меня не очень очевидная процедура.
Наверно я не очень ясно написал, сначала нужно получить данные сертификата в двоичном виде в памяти (подойдет в общем любой метод: и прочитать непонятный файл потом выровнять через CryptQueryObject - как в теме по ссылке; и прочитать файл потом перекодировать вручную; и вырезать из header.key и т.д.).

Потом передать данные сертификата в CertCreateCertificateContext - получится указатель на память с наполовину раскодированными данными, он же контекст сертификата PCERT_CONTEXT. В отличие от самого сертификата, неизменяемого после выпуска в УЦ, контекст можно изменить в любой момент - дополнительно содержит всякие служебные пометки выставляемые операционной системой, там и ссылка на контейнер, и указание какие использования сертификата от УЦ система будет в упор игнорировать, какие наоборот разрешит даже если УЦ запретил и т.д. Одно из полей контекста - те самые данные сертификата, что передавались при создании (сам сертификат).

Потом подготавливается структура описания ссылки, там тип криптопровайдера, имя контейнера, циферка для выбора ключа или сертификата в контейнере (обмена ключей 1 или подписи 2). Потом для контекста устанавливается "пометка" ссылка на контейнер, передается данная структура. Потом открывается хранилище Личное, и контекст с которым работали и проставляли ссылку на сертификат добавляется в хранилище.

При типичном подписании все происходит в обратном порядке - контексты сертификатов из хранилища показываются пользователю, пользователь выбирает один, для него считывается пометка ссылка на контейнер, получается контекст криптопровайдера связанный с этим контейнером HCRYPTPROV, выполняется вычисление хэша и подписание хэша ключом - получается значение "чистой" RAW подписи, обертывается дополнительными данными.
В темах подробнее расписано (правда порядок там немного другой, последовательность подлиннее, а здесь я пишу короткую последовательность), разве что если используется сервис на дотнете, то и средства надо использовать дотнетовские. В этом к сожалению, не подскажу - какие там классы и методы нужны. Однако можно через p invoke работать с голым Microsoft CryptoApi.

Offline Александр_35  
#11 Оставлено : 1 сентября 2021 г. 15:20:27(UTC)
Александр_35

Статус: Новичок

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

В общем я сделал удалённую установку сертификатов через отправку zip архива.
Собственно я только name.key распарсил на предмет названия контейнера создал ветку в реестре, сложил туда всё содержимое файла и через вызов certmgr установил сертификат из контейнера.
Всё хорошо, но теперь рабочий стол полон сообщений о предложении импортировать ключ на eToken. Где можно настроить , чтобы окно не вылезало?
Offline two_oceans  
#12 Оставлено : 2 сентября 2021 г. 5:22:36(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Насчет "отправки" в различных обновлениях, развертываниях я все равно не понимаю, почему не сделать простое скачивание с http(s), ведь там много вариантов ограничить доступность файла конкретному клиенту. Вчера наткнулся на давний концепт, как предлагали обновлять Дельфивские приложения, просто нет слов, предлагали и по почте архив посылать и даже Radmin использовать для доставки архива.

По вопросу: у Криптопро 4 такого предложения импорта на токен точно нет; надо найти возле часов иконку утилиты токена (либо иконку КриптоАрм - смотря чье окно), и либо вообще выключить запуск утилиты в ее настройках (рядовому пользователю утилита токена требуется только при смене пароля на токен, то есть где-то раз в полгода в лучшем случае, КриптоАрм тоже прекрасно работает из контекстного меню) либо в настройках утилиты отключить предложение импорта на токен. Лично у меня утилиты выключены, поэтому по расположению настройки импорта на токен не смогу подсказать.

Однако, тут что-то не так в принципе - утилита под одним пользователем не должна видеть контейнеры другого пользователя в реестре. Поэтому подозрение, что либо: 1) сервис запущен под тем же пользователем что вошел на рабочий стол (что не рекомендуется Майкрософт - реестр пользователя может просто крашнуться при любом выключении компьютера: при выходе самого пользователя реестр не выгрузится из-за службы, а после выхода службы не факт, что найдется достаточно времени до физического отключения питания - реестр может не сохраниться или записаться не полностью).

Либо 2) на раздел реестра Users\{sid} не установлены корректные "неразрешения" доступа от других пользователей. Пожалуйста, не забывайте этот шаг для реестра - по умолчанию разрешение наследуется от вышестоящего раздела реестра Users, который могут читать все, а вам надо выключить наследование и установить полный доступ одному конкретному пользователю, системе и создателю-владельцу.

Отредактировано пользователем 2 сентября 2021 г. 5:28:20(UTC)  | Причина: Не указана

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