Форум

Люди добрые, помогите!!! Пожалуйста! Нужны действующие сертификаты соответствия, удовлетворяющие требованиям ТР ТС 019/2011 на СИЗ (№ и дата действия, желательно сканы в личку nadyaiv30@mail.ru):
1. Рукавицы резиновые
2.Рукавицы комбинированные
3. Сапоги кирзовые
4.Сапоги резиновые
5.Сапоги кожаные
6.Респиратор
7.Очки защитные
8.Костюм х/б для защиты
9.Перчатки с полимерным покрытием
10.Костюм защитный Л-1 с сигнальными элементами
11. Каска защитная с щитком
12.Комбинезон сигнальный
13.Пояс предохранительный со страховкой

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

Проверка у нас

у Вас быстрее получится до любого магазина спецодежды добежать, а по дороге купить вкуснющщую шоколадину

Это краеугольный камень единого пространства доверия сертификатов ГОСТ. Если подробнее, как все это примерно работает - Головной удостоверяющий центр (ГУЦ) выдал сертификат сам себе, но в дальнейшем этот сертификат практически не используется, небольшое исключение - подчиненные УЦ (удостоверяющие центры) ГУЦ, на текущий момент их 2 (УЦ 1 ИС ГУЦ, УЦ 2 ИС ГУЦ), считая с 1 истекшим сертификатом у них целых 6 сертификатов. Такие тонкости можно посмотреть на https://e-trust.gosuslugi.ru/MainCA (у меня браузер предупреждает что сайт недоверенный, такие пироги).
Когда другой удостоверяющий центр посылает документы на аккредитацию, у него тоже имеется только самоподписанный корневой сертификат. После аккредитации, УЦ 1 ИС ГУЦ или УЦ 2 ИС ГУЦ выпускает сертификат на тот же открытый ключ, что и был указан в корневом сертификате. Это называется кросс-сертификат, благодаря нему нет необходимости ставить отдельный корневой сертификат для каждого аккредитованного УЦ, так как по цепочке доверия дойдет до корневого ГУЦ (уже доверенного благодаря установке в корневые сертификаты). Важно отметить, 1) если у какой-то компании тоже есть головной и подчиненные УЦ, то каждый подчиненный получает свой кросс-сертификат отдельно, головной УЦ компании не включается в цепочку, так как в кросс-сертификате стоит запрет на подчиненные УЦ, 2) если отсутствует (не установлен на компьютере и не включен в проверяемую цифровую подпись) сертификат УЦ 1(2) ИС ГУЦ , который выдал кросс-сертификат, то цепочка не дойдет до ГУЦ и выйдет ошибка. Поэтому на практике вместе с кросс-сертификатом прилагается еще и сертификат УЦ 1(2) ИС ГУЦ (ставятся в Промежуточные центры сертификации) либо многие УЦ поставляют свой корневой сертификат вместо кросс-сертификата. У неаккредитованных такого выбора нет - они всегда поставляют свой корневой, так как кросс-сертификата нет. Итого, сертификат ГУЦ в многих случаях просто пылится в сторонке. Отдельный вопрос, что мало все это поставить 1 раз, нужно еще и регулярно проверять списки отзыва для каждого УЦ.
Похоже, сертификата директора в виде отдельного файла нет, всё в контейнере закрытого ключа. Все зависит от того, как именно будет организован обмен. Закрытый ключ необходим для подписи и шифрования, но возможно его перевести в другую форму и не использовать флешку (см. шаг 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 не предусмотрено запоминание пароля). Большинство решений по автоматизации оставляет файл без шифрования, но с различными ограничениями прав доступа к нему.
В статье на хабре есть исходники утилиты и есть готовая версия. Использование просто [code:1xf1y3b6]privkey.exe f:\abcdefgh.000 1234> c:\privkey.pem[/code:1xf1y3b6] где f:\abcdefgh.000 путь к папке на флешке, где лежат 6 файликов, 1234 пароль, privkey.pem - файл, куда запишется вывод программы. Так как запишется вывод программы, то нужно проверить что там не сообщение об ошибке, а реально закрытый ключ. У закрытого ключа начало "-----BEGIN PRIVATE KEY-----", ошибка может означать опечатку в пароле (не удалось проверить открытый ключ), в имени папки или что у флешки другое имя диска (не найден контейнер).

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

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

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

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

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

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

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

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

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

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

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

Интересно. Как я понимаю, в сертификате должна быть такая строчка. Это один из сертификатов, что я пробовал для сделать для собственного УЦ на основе 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:[code:k4uiqpvd]certificatePolicies = 1.2.643.100.113.1,1.2.643.100.113.2[/code:k4uiqpvd] Итого: лучше бы узнать весь список требований заранее.

Оцените шутку юмора. Из ФСС прислали письмо на заключение соглашения об электронном обмене, хотят обкатывать электронные больничные. В нашем городе таких больниц пока нет, но на случай если кто будет лечится в областном центре, прислали и нам. Ну ладно, прошел по ссылке, прочитал руководство по установке КЭП.
Особенно порадовало предложение установить корневой сертификат Тестового центра Крипто-Про и выпустить там тестовый сертификат. Ага-ага, и все кому не лень смогут выпустить там же сертификат, подписать свой зловред и много чего натворить с компьютерами организации. Это уже не говоря, что тестовый сертификат действует месяца 3 всего и с ним вряд ли возможно зайти на Госуслуги.
Про привязку сертификата к организации не слова ни в письме, ни в соглашении, ни в руководстве. Наверно имеет смысл только если потом ФСС всем выдаст сертификаты. Хорошо бы бесплатно.
Решил зайти для пробы своим рабочим сертификатом (ну вдруг они по ЕСИА опознают организацию). Как бы не так - после авторизации ЕСИА переход на https://cabinets.fss.ru/insurer/saml/SA ... onConsumer с результатом "404 Not Found". Тоже походу сначала хотят всех загнать в свою ИС, а потом доводить до ума.