CRM-система для УК и ТСЖ

Сертификаты

Будете спамить рекламой - будем нещадно банить)))
Сообщение
Автор
two_oceans
Ветеран
Сообщений: 546
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 439 раза
Поблагодарили: 415 раза

Сертификаты

#1 Сообщение two_oceans » 31 окт 2016, 11:47

Programmer писал(а):У меня есть вот что:
1. Файл
8CAE88BBFD404A7A53630864F9033606E1DC45E2.cer
установлен в "Доверенные корневые центры сертификации".
Выдал: "Головной удостоверяющий центр".
Это краеугольный камень единого пространства доверия сертификатов ГОСТ. Если подробнее, как все это примерно работает - Головной удостоверяющий центр (ГУЦ) выдал сертификат сам себе, но в дальнейшем этот сертификат практически не используется, небольшое исключение - подчиненные УЦ (удостоверяющие центры) ГУЦ, на текущий момент их 2 (УЦ 1 ИС ГУЦ, УЦ 2 ИС ГУЦ), считая с 1 истекшим сертификатом у них целых 6 сертификатов. Такие тонкости можно посмотреть на https://e-trust.gosuslugi.ru/MainCA (у меня браузер предупреждает что сайт недоверенный, такие пироги).
Когда другой удостоверяющий центр посылает документы на аккредитацию, у него тоже имеется только самоподписанный корневой сертификат. После аккредитации, УЦ 1 ИС ГУЦ или УЦ 2 ИС ГУЦ выпускает сертификат на тот же открытый ключ, что и был указан в корневом сертификате. Это называется кросс-сертификат, благодаря нему нет необходимости ставить отдельный корневой сертификат для каждого аккредитованного УЦ, так как по цепочке доверия дойдет до корневого ГУЦ (уже доверенного благодаря установке в корневые сертификаты). Важно отметить, 1) если у какой-то компании тоже есть головной и подчиненные УЦ, то каждый подчиненный получает свой кросс-сертификат отдельно, головной УЦ компании не включается в цепочку, так как в кросс-сертификате стоит запрет на подчиненные УЦ, 2) если отсутствует (не установлен на компьютере и не включен в проверяемую цифровую подпись) сертификат УЦ 1(2) ИС ГУЦ , который выдал кросс-сертификат, то цепочка не дойдет до ГУЦ и выйдет ошибка. Поэтому на практике вместе с кросс-сертификатом прилагается еще и сертификат УЦ 1(2) ИС ГУЦ (ставятся в Промежуточные центры сертификации) либо многие УЦ поставляют свой корневой сертификат вместо кросс-сертификата. У неаккредитованных такого выбора нет - они всегда поставляют свой корневой, так как кросс-сертификата нет. Итого, сертификат ГУЦ в многих случаях просто пылится в сторонке. Отдельный вопрос, что мало все это поставить 1 раз, нужно еще и регулярно проверять списки отзыва для каждого УЦ.
Programmer писал(а):2. Шесть файлов: header.key, maska.key, maska2.key, name.key, primary.key, primary2.key, котрые тупо записаны на флэшку. Я их вижу и могу свобдно копировать. С помощью КриптоПро установлены в "Личное". В диспетчере сертификатов там просматривается фамилия директора УК.

Подскажите, пожалуйста, что с этим дальше делать в части организации SOAP? И нужна ли мне эта флэшка каждый день для работы SOAP, или достаточно установленных сертификатов? Спасибо!
Похоже, сертификата директора в виде отдельного файла нет, всё в контейнере закрытого ключа. Все зависит от того, как именно будет организован обмен. Закрытый ключ необходим для подписи и шифрования, но возможно его перевести в другую форму и не использовать флешку (см. шаг 3). Наиболее вероятно какое-либо решение на основе OpenSSL (в статьях ссылка на МагПро, который использует его), тогда общий обзор...
Шаг 1 (при любой реализации). нужно будет вытащить сертификат из закрытого контейнера или из "Личное" (экспорт сертификата - без закрытого ключа). Без закрытого ключа потому, что в КриптоПро не реализован экспорт закрытого ключа по соображениям безопасности (можно только копировать в другой контейнер, но не в файл), а стандартное средство Microsoft делает это неправильно. Поэтому доставать закрытый ключ придется отдельно. Должен получиться сертификат в формате DER (расширение файла CER).
Шаг 2. Если используется OpenSSL, то нужно (для удобства) преобразовать сертификат из DER в PEM (расширение или PEM или CRT) средствами OpenSSL, потому что понимаются оба формата, но по умолчанию принят формат PEM и если использовать DER нужно указывать в параметрах формат входного файла сертификата для каждой команды, что несколько утомительно. PEM формат - кодировка base64 от содержимого DER формата плюс строки разделители начинающиеся /заканчивающиеся 5 дефисами, обычно его можно посмотреть обычным блокнотом. Блокнот может испортить переводы строк, но для исправления тоже есть утилиты.

Шаг 3. Извлечение закрытого ключа. В принципе, шаг зависит от реализации - есть возможность настроить обращение к обычному КриптоПро и использование флешки (добавив DLL от КриптоПро и дописав параметры или настроив файл конфигурации), но частенько закрытый ключ извлекают на жесткий диск, а флешку возвращают например в бухгалтерию или в сейф. Это не очень-то безопасно - исчезновение флешки заметить проще чем копирование файла закрытого ключа по сети на сторону. На Ваше усмотрение. Я тестировал для немного другого случая и за неделю до истечения сертификатов, поэтому извлекал.

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

Код: Выбрать все

privkey.exe f:\abcdefgh.000 1234> c:\privkey.pem
где f:\abcdefgh.000 путь к папке на флешке, где лежат 6 файликов, 1234 пароль, privkey.pem - файл, куда запишется вывод программы. Так как запишется вывод программы, то нужно проверить что там не сообщение об ошибке, а реально закрытый ключ. У закрытого ключа начало "-----BEGIN PRIVATE KEY-----", ошибка может означать опечатку в пароле (не удалось проверить открытый ключ), в имени папки или что у флешки другое имя диска (не найден контейнер).

Шаг 4. Объединение закрытого ключа и сертификата (необязательно). Обычно OpenSSL при подписании ожидает, что сертификат и закрытый ключ находятся в одном файле. Если в предыдущих шагах получилось 2 разных файла, то нужно либо указывать отдельно файл с закрытым ключом, либо объединить - добавить закрытый ключ в файл сертификата. Если в Шаге 3 решили оставить флешку и заменить параметрами, то здесь тоже нужно пропустить и использовать параметры. Формат PEM позволяет объединять их при помощи любого текстового редактора (я простым блокнотом пробовал). Просто выделить все из одного файла, из другого и сохранить под новым именем. Естественно объединенный файл нужно хранить осторожно как и отдельный файл закрытого ключа. Для каких-то реализаций (в моем случае - собственный "самопальный" УЦ) может потребоваться извлечение открытого ключа и объединение с закрытым в ключевую пару, но это уже отдельная история.
Далее надо организовать тестовые стенды, настроить канал, и пробовать формировать запросы. В документации это все описано. <...> Для тестирования желательно сформировать тестовые ключи( хотя никто не запрещает тестироваться на "боевых")
Именно. Зачем формировать тестовые ключи, я так и не понял. Наверно, чтобы не ждать изготовления "боевых" ключей? Если они уже есть, тестовые не обязательны. Документацию пока не читал подробно, даже не знаю стоит ли - некоторые изменения до сих пор там не отражены. :)
Шесть файлов: header.key, maska.key, maska2.key, name.key, primary.key, primary2.key
у меня называются masks.key masks2.key в остальном тоже самое.
Почему у меня видны на флэшке 8 файлов, а у моего коллеги - нет?
Вероятно 7 и 8 файлы это сертификат (CER) и запрос на сертификат (REQ или CSR). Иногда еще бывает печатная форма заявления (DOC, RTF) или печатная форма сертификата (PDF). Это зависит от УЦ - некоторые позволяют генерировать запрос на сертификат самостоятельно. Запрос - это по сути сертификат без информации, добавляемой в УЦ и без подписи УЦ. В этом случае контейнер закрытого ключа не содержит сертификата, потому что его еще не выпустили. Затем из УЦ присылают готовый сертификат и при установке сертификата появляется выбор - установить сертификат в закрытый контейнер или оставить их по отдельности. Конечно есть случаи, когда бухгалтерия хранит на флешке какие-нибудь фотографии и прочую постороннюю информацию.

Programmer
Ветеран
Сообщений: 698
Зарегистрирован: 09 окт 2016, 16:39
Благодарил (а): 3891 раза
Поблагодарили: 643 раза

Сертификаты

#2 Сообщение Programmer » 31 окт 2016, 13:09

Спасибо! А где взять privkey.exe? У себя я не нахожу.

Я хотел спросить так: У меня на флешке 6 файлов, а у моего коллеги флешка как бы пустая. Каким образом были получены эти шесть файлов у меня? Бухгалтерия молчит, как СССР в годы застоя.

two_oceans
Ветеран
Сообщений: 546
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 439 раза
Поблагодарили: 415 раза

Сертификаты

#3 Сообщение two_oceans » 31 окт 2016, 13:29

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

Аватар пользователя
AlcorVol
Активист
Сообщений: 192
Зарегистрирован: 20 окт 2016, 00:40
Откуда: Вологда
Благодарил (а): 764 раза
Поблагодарили: 191 раза

Сертификаты

#4 Сообщение AlcorVol » 31 окт 2016, 15:04

[quote="two_oceans"][/quote]
Константин, вот ещё кое-что на эту тему с Хабра. Возможно, интересно будет:
https://habrahabr.ru/post/311062/

Programmer
Ветеран
Сообщений: 698
Зарегистрирован: 09 окт 2016, 16:39
Благодарил (а): 3891 раза
Поблагодарили: 643 раза

Сертификаты

#5 Сообщение Programmer » 31 окт 2016, 16:54

А можно обойтись без .NET?

portal-gkh
Бывалый
Сообщений: 312
Зарегистрирован: 15 авг 2016, 12:39
Благодарил (а): 34 раза
Поблагодарили: 202 раза

Сертификаты

#6 Сообщение portal-gkh » 31 окт 2016, 20:48

Programmer писал(а):А можно обойтись без .NET?


Можно, если знать Java :D . Net и Java самые распростаненные среды среди :) создателей софта для работы с госсервисами.

two_oceans
Ветеран
Сообщений: 546
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 439 раза
Поблагодарили: 415 раза

Сертификаты

#7 Сообщение two_oceans » 01 ноя 2016, 04:26

.Net Java популярные, потому что для них сами разработчики из КриптоПро выкладывали примерный код для работы со СМЭВ. Потом пример растащили и адаптировали под другие ФГИС. Оно понятно, чем с нуля на другом языке писать, многим проще "перестроится" и сочинять из готового примера.
Где-то находил код, как подписывать цифровой подписью на Дельфи, обращаясь к библиотекам КриптоПро через майкрософтовский криптопровайдер (такая вот загогулина, зато без .Net). Построение/разбор XML для Дельфи тоже вроде есть. Конкретно под ГИС на Дельфи не видел, наверно придется допилить. Находил программку, как нормализировать xml файл в форму c14n по правилам СМЭВ (представьте себе, не каждый XML "одинаково полезен" и воспринимается СМЭВ - с ума сойти). Еще знаю, кто-то пишет на python интеграцию с ГИС, так что полагаю возможно все. Вопрос какого качества готовые части и сколько придется "допиливать" до получения приемлемого результата.

two_oceans
Ветеран
Сообщений: 546
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 439 раза
Поблагодарили: 415 раза

Сертификаты

#8 Сообщение two_oceans » 07 июн 2017, 11:08

Несколько новых находок:
1) Ранее я писал о сложностях перевода ключей из контейнера КриптоПро в формат P12 и PEM. В качестве обходного маневра приходилось использовать утилиту privkey. У нее был очевидный недостаток в одностороннем преобразовании, так как описания расчета контрольных сумм контейнера КриптоПро нет в свободном доступе. То есть приходилось генерить контейнер на КриптоПро и потом из него вытаскивать ключ. И вот тадам!
На сайте КриптоПро неожиданно обнаружилась (раньше не видел) утилита которая делает обратное преобразование из P12 в контейнер Криптопро. Можно сказать цикл замкнулся и можно гораздо шире использовать ключи. Из справки выяснилось, что есть возможность задать имя и некоторые другие параметры контейнера, а также что один контейнер может хранить 2 ключа разного назначения. Таким образом, теперь можно сгенерить ключ (и даже выдать самому себе сертификат) под OpenSSL, а затем засунуть его в контейнер КриптоПро. С учетом совместимости КриптоПро с различными токенами и библиотеки доступа к КриптоПро из OpenSSL возможности значительно расширились.
Для тех, кто конвертацией не занимается тоже есть плюс - утилита умеет ремонтировать поврежденные контейнеры КриптоПро. То есть теперь флешку с битым контейнером есть шанс привести в рабочее состояние.

2) Искал у себя в реестре совсем другое, но наткнулся на хранилище где КриптоПро хранит ключи. В моем случае имя оказалось:

Код: Выбрать все

HKEY_LOCAL_MACHINE\SOFTWARE\Crypto Pro\Settings\USERS\S-1-5-...\Keys\a988830f-...
где S-1-5-... цифровой идентификатор пользователя, a988830f-... имя контейнера.
В этом разделе обнаружились 6 параметров бинарного типа с именами как у файлов в контейнере на флешке. Отсюда несколько выводов: с правами администратора и парой утилит можно просмотреть (и так далее) ключи любого пользователя компьютера, даже если он не выполнил вход; ранее озвученные ответы о хранении ключей пользователя в HKEY_CURRENT_USER неверны; ключи не включаются в часть перемещаемого профиля пользователя; предупреждение Виндоуз при принудительном сбросе пароля пользователя о потере доступа к ключам тоже не в кассу; соответственно контейнеры не цепляются утилитами миграции от Майкрософт.
Далее, рядом с Keys есть раздел KeyDevices и там перечислены все сертификаты, которые подключались к компьютеру. Названы по имени контейнера, далее указаны реквизиты носителя и наименование папки. То есть хоть я и удалил кучу прошлогодних сертификатов, а там они все "палятся".

mercury
Новичок
Сообщений: 9
Зарегистрирован: 03 фев 2017, 16:16
Благодарил (а): 6 раза
Поблагодарили: 11 раза

Сертификаты

#9 Сообщение mercury » 09 июн 2017, 12:41

Подскажите. Кто-нибудь генерил для ГИС ЖКХ сертификат ? Дело в том что год назад зарегистрировал собственную ИС с сертификатом выданным для входа в ГИС и всё прокатило, а пару недель назад пытался повторить всё на тестовом стенде : на выданный ранее сертификат ругается =
Screenshot_10.jpg
Пытался сгенерить *.pem с помощью OpenSSL, но на него ругается так =
Screenshot_12.jpg

Поддержка ответила вкратце всё норм ГИС правильно реагирует
что делать ? dash2

two_oceans
Ветеран
Сообщений: 546
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 439 раза
Поблагодарили: 415 раза

Сертификаты

#10 Сообщение two_oceans » 15 июн 2017, 13:47

mercury писал(а):Источник цитаты Дело в том что год назад зарегистрировал собственную ИС с сертификатом выданным для входа в ГИС и всё прокатило, а пару недель назад пытался повторить всё на тестовом стенде : на выданный ранее сертификат ругается =
Интересно. Как я понимаю, в сертификате должна быть такая строчка.
kc2.JPG
Это один из сертификатов, что я пробовал для сделать для собственного УЦ на основе OpenSSL, так что на другие строчки внимания не обращайте.
Вкратце - чтобы сертификат считался квалифицированным помимо прочего в нем указывается средство электронной подписи субъекта (КриптоПро или Випнет обычно) и средства удостоверяющего центра. Эти средства разделены на 6 классов безопасности. Исходя из указанных средств, в сертификате также указываются классы совпадающие у средств субъекта и УЦ. То есть УЦ не может выдать сертификаты класса, которого у него нет. Классы, которые есть у УЦ - перечислены в корневом сертификате и проверяются в процессе аккредитации.
Самый слабый класс КС1, посильнее КС2, потом КС3 и так далее. КС2 включает в себя КС1; КС3 включает в себя КС2 и КС1. Дальше не перечисляю, потому как средства класса КС3 и выше могут расцениваться на свой класс только если устанавливаются при участии специалистов ФСБ (что большинству из нас приснится только в страшном сне).
Соответственно разные категории информации должны защищаться определенным классом средств безопасности. Доступные КС1 и КС2 предназначены для данных не составляющих гостайну (персональные данные входят в эту категорию, дальше я не разбирался).

Возвращаясь к сообщению об ошибке - видимо сейчас ГИС требует класс КС2 в сертификате (КС1 тоже должен быть указан, так как входит в КС2), а в сертификате стоит только КС1. Вывод - нужно добавить КС2 в заявке на выпуск сертификата. В уже готовом сертификате это нельзя поменять. Если же в сертификате указаны и КС1 и КС2, то дело может быть в криптопровайдере. При установке КриптоПро версий 3.6 R3 и R4 (3.6.1) также просит выбрать класс безопасности (ранее был отдельный установщик для каждого класса) и вероятно потребуется переустановить криптопровайдер, выбрав класс КС2.

По заявкам. Я чаще всего генерировал заявки на сертификат на АРМ "Генерация ключей" (программа для УЦ Федерального казначейства), там в уголке есть список классов, по умолчанию как раз стоит КС2, но можно понизить до КС1 (УЦ казначейства как раз класса КС2, так что выше КС2 не повысить). В программах других УЦ также обычно есть выбор класса. Если генерировать заявку в OpenSSL, то там нужно вручную вписать данные политики в файле конфигурации, в секции где строка basicConstraints= , в типовом файле это секция [v3_req]. OpenSSL о классах не знает, так что они указываются цифрами 1.2.643.100.113.1 - КС1; 1.2.643.100.113.2 - КС2, перечисляются через запятую. Строчка для КС2:

Код: Выбрать все

certificatePolicies      = 1.2.643.100.113.1,1.2.643.100.113.2
Итого: лучше бы узнать весь список требований заранее.


Вернуться в «ГИС ЖКХ. Форум разработчиков программного обеспечения и всего, что с ним связано»

Кто сейчас на форуме

Количество пользователей, которые сейчас просматривают этот форум: нет зарегистрированных пользователей и 1 гость