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

Уведомление

Icon
Error

30 Страницы«<7891011>»
Опции
К последнему сообщению К первому непрочитанному
Offline alexlex  
#81 Оставлено : 27 ноября 2015 г. 16:52:01(UTC)
alexlex

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

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

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 1 раз в 1 постах
Автор: pharaon Перейти к цитате
Автор: alexlex Перейти к цитате
Автор: pharaon Перейти к цитате
Автор: Евгений Пономаренко Перейти к цитате
Автор: alexlex Перейти к цитате
а у кого-нибудь работают боевые сертификаты


Работают.


У нас ключ rsa получают. А вот на этапе ввода пин в УТМ он пароль не принимает? Вы имя контейнера ГОСТ делали как у Центринформа?
Или УТМ у нас какой то старый?

У вас получилось создать ключ RSA ? в чем была причина


а хз...пробовали у своих операторов-у них понаставлено куча криптопрог-не получилось, на чистой машине клиента, всё вышло.


Не думаю, что это связано что-то с крипто... пробовал на двух новых машинах(на разных ОС) создавать пары ключей и запросы, а потом на УЦ обрабатывать их, потом сертификат прикреплял на новых машинах, заходил в личный кабинет, начал создавать RSA и все тоже самое(вылетает сообщение). Я вот думаю мб это связано из-за того что неправильный КПП(в сертификате указываю 760301001, а в ЛК значится только 760332003)? Просто карточку не хочется переделывать, в понедельник конечно же попробую, но думаю наврядли поможет, хотя все мб

Отредактировано пользователем 27 ноября 2015 г. 16:53:23(UTC)  | Причина: Не указана

Offline zanzibeer  
#82 Оставлено : 27 ноября 2015 г. 17:35:10(UTC)
zanzibeer

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

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

Поблагодарили: 2 раз в 2 постах
Автор: alexlex Перейти к цитате
Автор: pharaon Перейти к цитате
Автор: alexlex Перейти к цитате
Автор: pharaon Перейти к цитате
Автор: Евгений Пономаренко Перейти к цитате
Автор: alexlex Перейти к цитате
а у кого-нибудь работают боевые сертификаты


Работают.


У нас ключ rsa получают. А вот на этапе ввода пин в УТМ он пароль не принимает? Вы имя контейнера ГОСТ делали как у Центринформа?
Или УТМ у нас какой то старый?

У вас получилось создать ключ RSA ? в чем была причина


а хз...пробовали у своих операторов-у них понаставлено куча криптопрог-не получилось, на чистой машине клиента, всё вышло.


Не думаю, что это связано что-то с крипто... пробовал на двух новых машинах(на разных ОС) создавать пары ключей и запросы, а потом на УЦ обрабатывать их, потом сертификат прикреплял на новых машинах, заходил в личный кабинет, начал создавать RSA и все тоже самое(вылетает сообщение). Я вот думаю мб это связано из-за того что неправильный КПП(в сертификате указываю 760301001, а в ЛК значится только 760332003)? Просто карточку не хочется переделывать, в понедельник конечно же попробую, но думаю наврядли поможет, хотя все мб


А вы видели нормативные документы с требованиями к сертификатам, в которых указано, что поле Неструктурированное имя вообще необходимо? На совещаниях специалисты утверждали, что будут работать любые КЭП. Никаких упоминаний про КПП не было. Тем более, что привязка rsa-ключей будет идти по учетной записи на портале. Пробовали делать несколько сертов для организации? вы будете входить в одну и ту же учетную запись по ИНН. Я проверял на сертах без КПП вообще. Разные ключи, одна учетка, один список rsa-ключей.
Offline infocentre  
#83 Оставлено : 30 ноября 2015 г. 9:47:40(UTC)
infocentre

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

Группы: Участники
Зарегистрирован: 26.07.2012(UTC)
Сообщений: 255
Мужчина
Российская Федерация

Сказал «Спасибо»: 22 раз
Поблагодарили: 13 раз в 9 постах
Это такой же невыясненный вопрос, как и количество ключей для ИП. Одна и та же федеральная служба сама отвечает по-разному :-)

О каких тут нормативных документах вести речь(
Offline NUCvibor  
#84 Оставлено : 30 ноября 2015 г. 10:49:44(UTC)
NUCvibor

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

Группы: Участники
Зарегистрирован: 15.02.2012(UTC)
Сообщений: 121
Откуда: Смоленск

Сказал(а) «Спасибо»: 104 раз
Поблагодарили: 27 раз в 16 постах
Автор: kubaev Перейти к цитате
ответ разработчика КриптоАРМ по поводу несовместимого ключа с ЕГАИС
"Пока что точно не выяснили причину несовместимости, но предполагаем что контейнер КриптоАРМ-а не видится ЕГАИС и плохо воспринимается Клиентом JaCarta из-за различий в присвоении идентификаторов ключевой пары. Эти идентификаторы в PKCS #11 используются для сопоставления ключевой пары сертификату (по спецификации они нужны для случая наличия нескольких сертификатов с одинаковыми DN). На практике эти идентификаторы используются аналогично имени контейнера для привязки сертификатов в Crypto API.

В КриптоАРМ-е в качестве этого идентификатора используется случайный набор байт, что соответствует спецификации. ЕГАИС и Клиент JaCarta, судя по всему, предполагают что в качестве идентификатора будет использоваться строка (что так же не противоречит спецификации). Естественно, записанные КриптоАРМ-ом случайные данные не могут быть представлены в виде строки, и по этому клиент JaCarta отображает в имени контейнера HEX, а ЕГАИС вообще его не воспринимает.

В ближайшее время предполагаем исправить эту несовместимость."

Дополню немного, с использованием SDK Аладина тоже не получается создать контейнер с именем в виде строки


Кое-кому (не нам) уже удалось с использованием SDK Аладдина решить этот вопрос.
А когда (дата) Вам разработчик КриптоАРМа обещал это исправить? Я сегодня им отправил на эту тему вопрос, но ещё не получил ответа. А уже (как говорится) "забот полон рот". То ли переделывать уже выпущенные сертификаты, то ли ЕГАИС (считаю, что это её "кривота" с этим УТМ) подправят?
Offline kubaev  
#85 Оставлено : 30 ноября 2015 г. 11:14:58(UTC)
kubaev

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 8 раз в 5 постах
Автор: NUCvibor Перейти к цитате
Автор: kubaev Перейти к цитате
ответ разработчика КриптоАРМ по поводу несовместимого ключа с ЕГАИС
"Пока что точно не выяснили причину несовместимости, но предполагаем что контейнер КриптоАРМ-а не видится ЕГАИС и плохо воспринимается Клиентом JaCarta из-за различий в присвоении идентификаторов ключевой пары. Эти идентификаторы в PKCS #11 используются для сопоставления ключевой пары сертификату (по спецификации они нужны для случая наличия нескольких сертификатов с одинаковыми DN). На практике эти идентификаторы используются аналогично имени контейнера для привязки сертификатов в Crypto API.

В КриптоАРМ-е в качестве этого идентификатора используется случайный набор байт, что соответствует спецификации. ЕГАИС и Клиент JaCarta, судя по всему, предполагают что в качестве идентификатора будет использоваться строка (что так же не противоречит спецификации). Естественно, записанные КриптоАРМ-ом случайные данные не могут быть представлены в виде строки, и по этому клиент JaCarta отображает в имени контейнера HEX, а ЕГАИС вообще его не воспринимает.

В ближайшее время предполагаем исправить эту несовместимость."

Дополню немного, с использованием SDK Аладина тоже не получается создать контейнер с именем в виде строки


Кое-кому (не нам) уже удалось с использованием SDK Аладдина решить этот вопрос.
А когда (дата) Вам разработчик КриптоАРМа обещал это исправить? Я сегодня им отправил на эту тему вопрос, но ещё не получил ответа. А уже (как говорится) "забот полон рот". То ли переделывать уже выпущенные сертификаты, то ли ЕГАИС (считаю, что это её "кривота" с этим УТМ) подправят?


дату когда исправят не назвали, как и было процитировано "В ближайшее время предполагаем исправить эту несовместимость". С сегодняшнего дня в ЛК ЕГАИС можно скачать "боевой" УТМ и попробовать. У меня всё работает (ключ создавал в едином клиенте а запрос в крипто-арм).
Offline zanzibeer  
#86 Оставлено : 30 ноября 2015 г. 11:31:40(UTC)
zanzibeer

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

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

Поблагодарили: 2 раз в 2 постах
Скажите, а кто-нибудь разобрался как в криптоАРМе формировать собственные шаблоны для запроса на сертификат?

Offline Ghost-kun  
#87 Оставлено : 30 ноября 2015 г. 11:39:34(UTC)
Ghost-kun

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

Группы: Участники
Зарегистрирован: 11.03.2013(UTC)
Сообщений: 43
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Поблагодарили: 2 раз в 2 постах
Автор: zanzibeer Перейти к цитате
Скажите, а кто-нибудь разобрался как в криптоАРМе формировать собственные шаблоны для запроса на сертификат?


Добрый день.
По адресу "Program Files\Digt\Trusted\Desktop\" есть файл CertReqTemplateDefault.xml.
Там описываются шаблоны запросов. По аналогии создается свой.
Offline zanzibeer  
#88 Оставлено : 30 ноября 2015 г. 11:43:42(UTC)
zanzibeer

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

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

Поблагодарили: 2 раз в 2 постах
Автор: Ghost-kun Перейти к цитате
Автор: zanzibeer Перейти к цитате
Скажите, а кто-нибудь разобрался как в криптоАРМе формировать собственные шаблоны для запроса на сертификат?


Добрый день.
По адресу "Program Files\Digt\Trusted\Desktop\" есть файл CertReqTemplateDefault.xml.
Там описываются шаблоны запросов. По аналогии создается свой.


Я его правил, но результатов это не принесло почему-то. Потому и задал вопрос.
Offline NUCvibor  
#89 Оставлено : 30 ноября 2015 г. 11:51:52(UTC)
NUCvibor

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

Группы: Участники
Зарегистрирован: 15.02.2012(UTC)
Сообщений: 121
Откуда: Смоленск

Сказал(а) «Спасибо»: 104 раз
Поблагодарили: 27 раз в 16 постах
Автор: zanzibeer Перейти к цитате
Скажите, а кто-нибудь разобрался как в криптоАРМе формировать собственные шаблоны для запроса на сертификат?



Слишком подробно я не смогу это изложить здесь. Тем более, что сами мы до этих способов дошли интуитивно.
Шаблоны прописаны в файле C:\Program Files\Digt\Trusted\Desktop\CertReqTemplateDefault.xml. Определённая часть этого файла содержит тэги, в которых прописаны поля шаблонов, их названия, в ряде случаев - значения по умолчанию, ОИДы и т.д. Немного посидеть, поразбираться и (зная, что должно входить в запрос, и что - в сертификат) можно постичь эту нехитрую премудрость.
Это наш шаблон (мы его так назвали), более расширенная версия для Вас.
Желательно удалить шаблоны от "создателя". Заводской файл можете сохранить в другом месте.
++++++++++++++++++++++++++++++++++++++++++++++++++
<?xml version="1.0" encoding="windows-1251"?>
<PKIRequestTemplates>
<PKIRequestTemplate> <!--Сертификат для ЕГАИС (Юридическое лицо)-->
<CertificateRequestTemplate>
<TemplateInformation>
<SuppotedCA>
<MicrosoftCA/>
<CryptoProCA/>
</SuppotedCA>
<FriendlyName>Сертификат для ЕГАИС (Юридическое лицо) JaCarta</FriendlyName>
<Description>Сертификат для организаций, осуществляющих оптовую и розничную торговлю алкогольной продукцией.</Description>
</TemplateInformation>
<Subject> <!--Субъект-->
<DirectoryName>
<RDNSequence>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.3</OID>
<Name>Общее имя (CN)</Name>
<Value/>
<Length>64</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.4</OID>
<Name>Фамилия (SN)</Name>
<Value/>
<Length>32</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.42</OID>
<Name>Имя Отчество (G)</Name>
<Value/>
<Length>32</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.6</OID>
<Name>Страна (C)</Name>
<Value>RU</Value>
<Length>2</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.8</OID>
<Name>Регион (S)</Name>
<Value/>
<Length>128</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.7</OID>
<Name>Населенный пункт (L)</Name>
<Value/>
<Length>128</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.9</OID>
<Name>Адрес (STREET)</Name>
<Length>64</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>2.5.4.10</OID>
<Name>Организация (O)</Name>
<Value/>
<Length>64</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="false" hidden="false">
<OID>2.5.4.11</OID>
<Name>Подразделение (OU)</Name>
<Value/>
<Length>64</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="false" hidden="false">
<OID>2.5.4.12</OID>
<Name>Должность (T)</Name>
<Value/>
<Length>64</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>1.2.643.100.1</OID>
<Name>ОГРН</Name>
<Value/>
<Length>13</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="false" hidden="false">
<OID>1.2.643.100.3</OID>
<Name>СНИЛС</Name>
<Value/>
<Length>11</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>1.2.643.3.131.1.1</OID>
<Name>ИНН</Name>
<Value/>
<Length>12</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="false" hidden="false">
<OID>1.2.840.113549.1.9.2</OID>
<Name>КПП (UN)</Name>
<Value>КПП=</Value>
<Length>9</Length>
</RDNEntry>
<RDNEntry readonly="false" mandatory="true" hidden="false">
<OID>1.2.840.113549.1.9.1</OID>
<Name>E-mail</Name>
<Length>128</Length>
</RDNEntry>
</RDNSequence>
<DNRule>
2.5.4.3=$2.5.4.3$,
2.5.4.4=$2.5.4.4$,
2.5.4.42=$2.5.4.42$,
2.5.4.6=$2.5.4.6$,
2.5.4.8=$2.5.4.8$,
2.5.4.7=$2.5.4.7$,
2.5.4.10=$2.5.4.10$,
2.5.4.11=$2.5.4.11$,
2.5.4.12=$2.5.4.12$,
1.2.643.100.1=$1.2.643.100.1$,
1.2.643.100.3=$1.2.643.100.3$,
1.2.643.3.131.1.1=$1.2.643.3.131.1.1$,
1.2.840.113549.1.9.1=$1.2.840.113549.1.9.1$,
2.5.4.9=$2.5.4.9$
</DNRule>
</DirectoryName>
</Subject>
<Extensions> <!--Расширения сертификатов-->
<Extension> <!--Использование ключа-->
<OID>2.5.29.15</OID>
<Critical>True</Critical>
<Value>
<KeyUsage>
<Bits>
<KeyAgreement/> <!--Согласование ключей-->
<DataEncipherment/> <!--Шифрование данных-->
<NonRepudiation/> <!--Неотрекаемость-->
<DigitalSignature/> <!--Цифровая подпись-->
</Bits>
</KeyUsage>
</Value>
</Extension>
<Extension> <!--Улучшенный ключ-->
<OID>2.5.29.37</OID>
<Value>
<ExtendedKeyUsage>
<KeyPurposeId>1.3.6.1.5.5.7.3.2</KeyPurposeId> <!--Проверка подлинности клиента-->
<KeyPurposeId>1.3.6.1.5.5.7.3.4</KeyPurposeId> <!--Защищенная электронная почта-->
<KeyPurposeId>1.2.643.2.2.34.25</KeyPurposeId> <!--Пользователь службы штампов времени-->
</ExtendedKeyUsage>
</Value>
</Extension>
<Extension> <!--Политики сертификата-->
<OID>2.5.29.32</OID>
<Critical>True</Critical>
<Value>
<certificatePolicies>
<!-- Пример добавления собственной политики сертификата -->
<!--PolicyInformation>
<policyIdentifier>1.2.643.3.2.100.78.13.11</policyIdentifier>
</PolicyInformation-->
<!--Класс защиты ЭП владельца-->
<!--Для KC1-->
<PolicyInformation>
<policyIdentifier>1.2.643.100.113.1</policyIdentifier>
</PolicyInformation>
<!--Этот и все предыдущие идентификаторы для KC2-->
<PolicyInformation>
<policyIdentifier>1.2.643.100.113.2</policyIdentifier>
</PolicyInformation>
<!--Этот и все предыдущие для KC3-->
<!--PolicyInformation>
<policyIdentifier>1.2.643.100.113.3</policyIdentifier>
</PolicyInformation-->
<!--Этот и все предыдущие для KB1-->
<!--PolicyInformation>
<policyIdentifier>1.2.643.100.113.4</policyIdentifier>
</PolicyInformation-->
<!--Этот и все предыдущие для KB2-->
<!--PolicyInformation>
<policyIdentifier>1.2.643.100.113.5</policyIdentifier>
</PolicyInformation-->
<!--Этот и все предыдущие для KA1-->
<!--PolicyInformation>
<policyIdentifier>1.2.643.100.113.6</policyIdentifier>
</PolicyInformation-->
</certificatePolicies>
</Value>
</Extension>
<Extension> <!--Средство электронной подписи владельца-->
<OID>1.2.643.100.111</OID>
<Critical>False</Critical>
<Value>
<UTF8String>"Криптотокен"</UTF8String>
<Length>200</Length>
</Value>
</Extension>
<Extension> <!--Средства электронной подписи и УЦ издателя-->
<OID>1.2.643.100.112</OID>
<Critical>False</Critical>
<Value>
<signTool>
<UTF8String>СКЗИ "ViPNet CSP 4"</UTF8String>
<Length>200</Length>
</signTool>
<cATool>
<UTF8String>149/3/2/2-2052 от 29 января 2014 г.</UTF8String>
<Length>200</Length>
</cATool>
<signToolCert>
<UTF8String>Программный комплекс ViPNet Удостоверяющий центр 4</UTF8String>
<Length>100</Length>
</signToolCert>
<cAToolCert>
<UTF8String>СФ/128-2324 от 25 апреля 2014 г.</UTF8String>
<Length>100</Length>
</cAToolCert>
</Value>
</Extension>
</Extensions>
<Provider>
<!-- Name>Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider</Name -->
<!--Type>75</Type-->
</Provider>
<Keyset>
<CreateNew>true</CreateNew>
<Keyspec>3</Keyspec>
<MarkExportable>false</MarkExportable>
</Keyset>
</CertificateRequestTemplate>
</PKIRequestTemplate>
</PKIRequestTemplates>
Offline zanzibeer  
#90 Оставлено : 30 ноября 2015 г. 12:02:16(UTC)
zanzibeer

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

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

Поблагодарили: 2 раз в 2 постах
Автор: zanzibeer Перейти к цитате
Автор: Ghost-kun Перейти к цитате
Автор: zanzibeer Перейти к цитате
Скажите, а кто-нибудь разобрался как в криптоАРМе формировать собственные шаблоны для запроса на сертификат?


Добрый день.
По адресу "Program Files\Digt\Trusted\Desktop\" есть файл CertReqTemplateDefault.xml.
Там описываются шаблоны запросов. По аналогии создается свой.


Я его правил, но результатов это не принесло почему-то. Потому и задал вопрос.


Омг, я нуб. я правил шаблоны в папке x86. Извиняюсь за невнимательность.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
30 Страницы«<7891011>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.