в сертификате в поле субъект отсутствует значение снилс что делать

Для оформления и выдачи квалифицированных сертификатов ключей проверки электронной подписи в Удостоверяющий центр в обязательном порядке необходимо предоставление копий паспорта и СНИЛС (даже от юридических лиц).

Статьей 17 Федерального закона № 63-ФЗ от 06.04.2011 «Об электронной подписи» устанавливаются требования к информации, содержащейся в квалифицированном сертификате ключа проверки электронной подписи, одними из которых являются указание на фамилию, имя и отчество владельца квалифицированного сертификата — для физического лица либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата — для юридического лица; а также указание на страховой номер индивидуального лицевого счета владельца квалифицированного сертификата — для физического лица либо идентификационный номер налогоплательщика владельца квалифицированного сертификата — для юридического лица.

В соответствии со ст. 18 Федерального закона № 63-ФЗ, а также ст. 9 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных», Удостоверяющий центр обязан установить личность заявителя, данные о котором вносятся в квалифицированный сертификат, и запросить основной документ, удостоверяющий личность, установить его персональные данные, которые подлежат внесению в сертификат. Необходимость этого вызвана тем, что Удостоверяющий центр должен иметь подтверждение правильности внесенных в сертификат данных и надлежащего установления личности.

В части предоставления СНИЛС необходимо отметить, что Федеральный закон № 63-ФЗ (п. 2 ст. 18) устанавливает данное требование только для физических лиц, клиент — юридическое лицо формально предоставлять СНИЛС не обязан, такое требование в законодательстве отсутствует. Но, поскольку Удостоверяющий центр изготавливает квалифицированные сертификаты, которые возможно применять в любой действующей информационной системе, имеющей возможность работать с квалифицированными сертификатами, то в квалифицированных сертификатах УЦ СКБ Контур соблюдено требование ЕСИА и портала Госуслуг, предполагающее наличие СНИЛС и в сертификатах для юридических лиц. В связи с тем, в соответствии с Федеральным законом № 63-ФЗ, информационная система вправе устанавливать дополнительные требования к составу сертификатов, такое требование правомерно. Соответственно, в квалифицированных сертификатах электронной подписи УЦ СКБ Контур технически предусмотрено внесение СНИЛСа любого лица, данные о котором вносятся в сертификат, вне зависимости от того, кто является заявителем.

Если СНИЛС был подтвержден из СМЭВ, предоставлять оригинал документа не требуется.

Источник

Разбираем квалифицированные сертификаты X.509 в поисках ИНН, СНИЛС и ОГРН

«Коллеги, нам необходимо вести реестр выданных квалифицированных сертификатов с возможностью поиска по ИНН, СНИЛС и ОГРН. Сколько дней нужно для создания парсера сертификатов и первого макета?» — с такого вопроса начальника началась очередная летучка.

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

Когда-то я участвовал в небольшом проекте по моделированию SSL MITM, где отвечал за генерацию ключей и сертификатов для этого самого «человека посередине». Поэтому представлял, что квалифицированный сертификат ключа проверки электронной подписи (далее — квалифицированный сертификат) — это сертификат X.509, для описания внутренней структуры которого используется всеми любимый ASN.1.

Вот только не помнил я, чтобы тогда на глаза попадались эти ИННы, СНИЛСы и ОГРНы. Поэтому ответил более, чем скромно: «Босс, два дня, не меньше!», надеясь выполнить задачку за несколько часов.

Ниже рассказ о том, насколько сильно я ошибся в расчетах, а также готовое решение для парсинга сертификатов X.509 на C# с возможностью извлечения полей и их атрибутов с заданными объектными идентификаторами (OID).

Шаг 1. Предварительные изыскания и проверка гипотезы

Нет, серьезно, это правда, что в сертификате X.509 есть СНИЛС? Для проверки найдем образец — просим помощи у Яндекса по запросу «реестр выданных квалифицированных сертификатов», на первой же странице выдачи находим Реестр выданных УЦ ГКУ ЛО «ОЭП» сертификатов, скачиваем первый попавшийся сертификат (под номером 10842) — Komarov_Aleksey_Petrovich_2017-03-31_a2ba20c4.cer.

Открываем сертификат с помощью стандартного средства просмотра OC Windows и находим в описании субъекта подозрительно похожую строку с объектным идентификатором 1.2.643.100.3, состоящую из 11 цифр. СНИЛС?

О том, что такое объектный идентификатор (OID) вообще, лучше всего почитать здесь. Как используются объектные идентификаторы в описании структуры сертификатов X.509 — смотрим Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509).

Открываем сертификат в виртуальной машине с установленным криптопровайдером КриптоПРО CSP, который наверняка знает отечественную специфику, и подтверждаем догадку.

Итак, поставленная задача потенциально выполнима, СНИЛС в квалифицированном сертификате есть. Идем дальше.

Шаг 2. Знакомство с нормативной базой

Естественно, не в любом сертификате X.509 можно найти ИНН, СНИЛС и ОГРН. К примеру, если в браузере щелкнуть по замочку рядом с адресной строкой «https://yandex.ru/» и экспортировать сертификат, то там никаких длинных цифровых последовательностей не обнаружится.

При этом следует заметить, что стандарт Х.509 не ограничивает набор атрибутов, которые могут быть указаны в имени издателя и/или субъекта. Стандарт лишь рекомендует поддерживать ряд атрибутов, среди которых — страна, организация, регион, общепринятое имя и др., но о СНИЛСе и прочем не сказано ни слова.

Интересующие нас данные точно содержатся в сертификатах, которые попадают в сферу действия Федерального закона «Об электронной подписи» от 06 апреля 2011 г. № 63-ФЗ. Внимательно изучаем статью 17 и убеждаемся, что ИНН, СНИЛС и ОГРН действительно должны содержаться в квалифицированных сертификатах.

18. К дополнительным атрибутам имени, необходимость использования которых устанавливается в соответствии с Федеральным законом, относятся:

1) OGRN (ОГРН).
Значением атрибута OGRN является строка, состоящая из 13 цифр и представляющая ОГРН владельца квалифицированного сертификата — юридического лица. Объектный идентификатор типа атрибута OGRN имеет вид 1.2.643.100.1, тип атрибута OGRN описывается следующим образом: OGRN ::= NUMERIC STRING SIZE 13;

2) SNILS (СНИЛС).
Значением атрибута SNILS является строка, состоящая из 11 цифр и представляющая СНИЛС владельца квалифицированного сертификата — физического лица. Объектный идентификатор типа атрибута SNILS имеет вид 1.2.643.100.3, тип атрибута SNILS описывается следующим образом: SNILS ::= NUMERIC STRING SIZE 11;

3) INN (ИНН).
Значением атрибута INN является строка, состоящая из 12 цифр и представляющая ИНН владельца квалифицированного сертификата. Объектный идентификатор типа атрибута INN имеет вид 1.2.643.3.131.1.1, тип атрибута INN описывается следующим образом: INN ::= NUMERIC STRING SIZE 12.

Можно попробовать проверить себя — зная OID, найти описываемый им объект. Для примера возьмем OID = 1.2.643.100.3 (СНИЛС). Обращаемся к официальному реестру идентификаторов и «прогуливаемся» по дереву:

Значение 1.2.643.100 найти уже не удается, такой OID в списках официального каталога не значится. Переходим по ссылке в национальный реестр, продолжаем поиски. Обнаруженные идентификаторы, до которых удалось «спуститься» по дереву:

Проверить себя не получится, поскольку не все ярусы отображены на сайте национального реестра объектных идентификаторов. Но надежда умирает последней, пробуем отправить официальный запрос оператору национального дерева – в ОАО «Инфотекс Интернет Траст». Цитируем переписку:

– Подскажите, возможно ли на сайте oid.iitrust.ru уточнить, каким объектам соответствуют OID’ы: 1.2.643.3.131.1.1, 1.2.643.100.1, 1.2.643.100.3? В поиске они не находятся, но мы предполагаем, что это ИНН, ОГРН и СНИЛС. Как можно получить подтверждение этому?

Круг замкнулся, считаем, что проверка проведена успешно.

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую имя, фамилию и отчество (если имеется) — для физического лица, или наименование — для юридического лица. Объектный идентификатор типа атрибута commonName имеет вид 2.5.4.3.

В нашем случае (Komarov_Aleksey_Petrovich_2017-03-31_a2ba20c4.cer) значением атрибута commonName является строка «Комитет по природным ресурсам Ленинградской области», следовательно, владелец сертификата – юридическое лицо.

Для юридического лица устанавливаем следующее соответствие объектных идентификаторов (не всех, выборочно, интересных нам) типам атрибутов:

Шаг 3. Разработка парсера X.509 сертификата на С#

Так сложилось, что разработка у нас ведется на C#, поэтому и пример парсера будет на C#, ничего личного и никакого холивара.

Для простоты формализуем задачу следующим образом. Дано: файл квалифицированного сертификата в системе ограничений CER (Canonical encoding rules). Требуется: разобрать (распарсить) сертификат и извлечь значения ИНН, СНИЛС и ОГРН из поля субъекта (Subject).

Для первых набросков обращаемся к возможностям пространства имен System.Security.Cryptography.X509Certificates:

На выходе получаем:

Свойство X509Certificate.Subject возвращает имя субъекта сертификата с типом string.

На первый взгляд, можно останавливаться и несложными регулярными выражениями (пример) выбрать из строки интересующие нас значения, зная их OID’ы и типы значений. Но согласитесь, изящности такому решению явно не хватает. Кроме того, установленный криптопровайдер может заменить коды OID’ов на символьные обозначения, что приведет к лишнему усложнению кода.

StackOverflow даёт подсказку — использовать сторонние библиотеки, выбираем наиболее цитируемую — BouncyCastle.

Библиотека подключается в один клик добавлением reference в проект. Предлагаемый уровень абстракции позволяет интуитивно понятно просматривать данные в формате ASN.1. Остается только уточнить «смещение» интересующих нас значений относительно начала файла сертификата, чтобы правильно указать позицию для парсера.

Открываем сертификат в редакторе ASN.1 Editor и устанавливаем соответствие со структурой сертификата:

Нас интересует поле «Имя субъекта», в котором и записываются значения ИНН, СНИЛС и ОГРН. Если внимательно посмотреть на рисунок, можно сделать следующий вывод: поле «Имя субъекта» (325, 654) SEQUENCE представляет собой последовательность (SEQUENCE) множеств (SET), состоящих из последовательностей (SEQUENCE) пар ключ/значение.

В соответствии с этой логикой реализуем парсер:

Смотрим вывод, соглашаемся:

Подведение итогов

Итак, подытоживая проделанную работу, мы:

Источник

В сертификате в поле субъект отсутствует значение снилс что делать

ЭЦП — довольно сложный цифровой продукт, обращение с которым в определенных ситуациях может потребовать некоторых навыков и знаний. Например, в ходе установки сертификатов ЭП посредством «КриптоПро» после выбора соответствующего ключевого контейнера нередко выдаются неприятные сообщения об ошибке вследствие отсутствия открытого шифровочного ключа, который необходим для обеспечения информационной безопасности, без чего система не будет принимать ЭЦП.

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

Что может послужить причиной такой ошибки

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

В целях устранения ошибки обычно бывает достаточно произвести корректную ручную переустановку сертификата.

Решение ошибки: отсутствие электронного сертификата в контейнере закрытого ключа

Для начала запускаем «КриптоПро» нажатием кнопки «Пуск». Затем выбираем «Настройку», в возникающем на мониторе окне заходим в опцию панели управления, далее «сервис – установить личный сертификат».

Далее, через кнопку «обзор» указываем путь, где сохранен открытый ключ – файл с расширением *.cert или *.crt

Жмём «Далее», в мастере установки сертификата мы увидим путь, который указывали до нашего сертификата.

Нам отображается информация, содержащаяся в открытом ключе на пользователя, жмём «далее»

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

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

Самый простой вариант выбрать автоматический поиск, затем после «обнаружения» необходимого контейнера, мы увидим заполненную строчку с его именем и после жмём «Далее»

Личный сертификат пользователя всегда устанавливается в хранилище «Личное», можно выбрать как вручную, так и КриптоПро может сделать это за вас по умолчанию, затем подтверждаем установку цепочки сертификатов и жмём «Далее»

>

В случае успешной установки КриптоПро выдаст окно с информацией об окончании процедуры и жмём «Готово»

Затем появится окно с подтверждением данной операции, жмём «ДА»

В следующем окне увидим информацию о том, что процесс окончен успешно. Сертификат установлен в контейнер закрытого ключа.

Особенности версий КриптоПро

С января 2019 года квалифицированные сертификаты могут выпускаться только по ГОСТ 2012, выпуск по другому ГОСТу прекращен. Мы об этом писали ранее в статье. Важно помнить, что версии криптопро на ГОСТ 2012 работают только с версии 4.0 и выше. Все старые версии КриптоПро, для нормальной работы, потребуется обновить или заменить на актуальную. Сделать это нужно не позднее 31 декабря 2019 года.

«Коллеги, нам необходимо вести реестр выданных квалифицированных сертификатов с возможностью поиска по ИНН, СНИЛС и ОГРН. Сколько дней нужно для создания парсера сертификатов и первого макета?» — с такого вопроса начальника началась очередная летучка.

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

Когда-то я участвовал в небольшом проекте по моделированию SSL MITM, где отвечал за генерацию ключей и сертификатов для этого самого «человека посередине». Поэтому представлял, что квалифицированный сертификат ключа проверки электронной подписи (далее — квалифицированный сертификат) — это сертификат X.509, для описания внутренней структуры которого используется всеми любимый ASN.1.

Вот только не помнил я, чтобы тогда на глаза попадались эти ИННы, СНИЛСы и ОГРНы. Поэтому ответил более, чем скромно: «Босс, два дня, не меньше!», надеясь выполнить задачку за несколько часов.

Шаг 1. Предварительные изыскания и проверка гипотезы

Нет, серьезно, это правда, что в сертификате X.509 есть СНИЛС? Для проверки найдем образец — просим помощи у Яндекса по запросу «реестр выданных квалифицированных сертификатов», на первой же странице выдачи находим Реестр выданных УЦ ГКУ ЛО «ОЭП» сертификатов, скачиваем первый попавшийся сертификат (под номером 10842) — Komarov_Aleksey_Petrovich_2017-03-31_a2ba20c4.cer.

Открываем сертификат с помощью стандартного средства просмотра OC Windows и находим в описании субъекта подозрительно похожую строку с объектным идентификатором 1.2.643.100.3, состоящую из 11 цифр. СНИЛС?

О том, что такое объектный идентификатор (OID) вообще, лучше всего почитать здесь. Как используются объектные идентификаторы в описании структуры сертификатов X.509 — смотрим Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509).

Открываем сертификат в виртуальной машине с установленным криптопровайдером КриптоПРО CSP, который наверняка знает отечественную специфику, и подтверждаем догадку.

Итак, поставленная задача потенциально выполнима, СНИЛС в квалифицированном сертификате есть. Идем дальше.

Шаг 2. Знакомство с нормативной базой

Естественно, не в любом сертификате X.509 можно найти ИНН, СНИЛС и ОГРН. К примеру, если в браузере щелкнуть по замочку рядом с адресной строкой «https://yandex.ru/» и экспортировать сертификат, то там никаких длинных цифровых последовательностей не обнаружится.

При этом следует заметить, что стандарт Х.509 не ограничивает набор атрибутов, которые могут быть указаны в имени издателя и/или субъекта. Стандарт лишь рекомендует поддерживать ряд атрибутов, среди которых — страна, организация, регион, общепринятое имя и др., но о СНИЛСе и прочем не сказано ни слова.

Интересующие нас данные точно содержатся в сертификатах, которые попадают в сферу действия Федерального закона «Об электронной подписи» от 06 апреля 2011 г. № 63-ФЗ. Внимательно изучаем статью 17 и убеждаемся, что ИНН, СНИЛС и ОГРН действительно должны содержаться в квалифицированных сертификатах.

18. К дополнительным атрибутам имени, необходимость использования которых устанавливается в соответствии с Федеральным законом, относятся:

1) OGRN (ОГРН).
Значением атрибута OGRN является строка, состоящая из 13 цифр и представляющая ОГРН владельца квалифицированного сертификата — юридического лица. Объектный идентификатор типа атрибута OGRN имеет вид 1.2.643.100.1, тип атрибута OGRN описывается следующим образом: OGRN ::= NUMERIC STRING SIZE 13;

2) SNILS (СНИЛС).
Значением атрибута SNILS является строка, состоящая из 11 цифр и представляющая СНИЛС владельца квалифицированного сертификата — физического лица. Объектный идентификатор типа атрибута SNILS имеет вид 1.2.643.100.3, тип атрибута SNILS описывается следующим образом: SNILS ::= NUMERIC STRING SIZE 11;

3) INN (ИНН).
Значением атрибута INN является строка, состоящая из 12 цифр и представляющая ИНН владельца квалифицированного сертификата. Объектный идентификатор типа атрибута INN имеет вид 1.2.643.3.131.1.1, тип атрибута INN описывается следующим образом: INN ::= NUMERIC STRING SIZE 12.

Можно попробовать проверить себя — зная OID, найти описываемый им объект. Для примера возьмем OID = 1.2.643.100.3 (СНИЛС). Обращаемся к официальному реестру идентификаторов и «прогуливаемся» по дереву:

Значение 1.2.643.100 найти уже не удается, такой OID в списках официального каталога не значится. Переходим по ссылке в национальный реестр, продолжаем поиски. Обнаруженные идентификаторы, до которых удалось «спуститься» по дереву:

– Подскажите, возможно ли на сайте oid.iitrust.ru уточнить, каким объектам соответствуют OID’ы: 1.2.643.3.131.1.1, 1.2.643.100.1, 1.2.643.100.3? В поиске они не находятся, но мы предполагаем, что это ИНН, ОГРН и СНИЛС. Как можно получить подтверждение этому?

Круг замкнулся, считаем, что проверка проведена успешно.

В нашем случае (Komarov_Aleksey_Petrovich_2017-03-31_a2ba20c4.cer) значением атрибута commonName является строка «Комитет по природным ресурсам Ленинградской области», следовательно, владелец сертификата – юридическое лицо.

Для юридического лица устанавливаем следующее соответствие объектных идентификаторов (не всех, выборочно, интересных нам) типам атрибутов:

Для простоты формализуем задачу следующим образом. Дано: файл квалифицированного сертификата в системе ограничений CER (Canonical encoding rules). Требуется: разобрать (распарсить) сертификат и извлечь значения ИНН, СНИЛС и ОГРН из поля субъекта (Subject).

Для первых набросков обращаемся к возможностям пространства имен System.Security.Cryptography.X509Certificates:

На выходе получаем:

Свойство X509Certificate.Subject возвращает имя субъекта сертификата с типом string.

На первый взгляд, можно останавливаться и несложными регулярными выражениями (пример) выбрать из строки интересующие нас значения, зная их OID’ы и типы значений. Но согласитесь, изящности такому решению явно не хватает. Кроме того, установленный криптопровайдер может заменить коды OID’ов на символьные обозначения, что приведет к лишнему усложнению кода.

StackOverflow даёт подсказку — использовать сторонние библиотеки, выбираем наиболее цитируемую — BouncyCastle.

Библиотека подключается в один клик добавлением reference в проект. Предлагаемый уровень абстракции позволяет интуитивно понятно просматривать данные в формате ASN.1. Остается только уточнить «смещение» интересующих нас значений относительно начала файла сертификата, чтобы правильно указать позицию для парсера.

Открываем сертификат в редакторе ASN.1 Editor и устанавливаем соответствие со структурой сертификата:

Нас интересует поле «Имя субъекта», в котором и записываются значения ИНН, СНИЛС и ОГРН. Если внимательно посмотреть на рисунок, можно сделать следующий вывод: поле «Имя субъекта» (325, 654) SEQUENCE представляет собой последовательность (SEQUENCE) множеств (SET), состоящих из последовательностей (SEQUENCE) пар ключ/значение.

В соответствии с этой логикой реализуем парсер:

Смотрим вывод, соглашаемся:

Подведение итогов

Итак, подытоживая проделанную работу, мы:

Спасибо за внимание!

Список источников

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

ЭЦП по ГОСТ на GNU/Linux с помощью OpenSSL

Самоподписные сертификаты кровавого энтерпрайза против вашего лампового CI/CD

Разбираем x.509 сертификат

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 16

У того самого asn1 editor, которым вы пользовались для просмотра сертификата есть обычный шарповый метод

А ещё можно обойтись коробочными решениями, там есть всё, чтобы прочитать сертификат\подпись целиком.

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

Если честно, «сложного тут вообще» было немного: «… вместо запланированных нескольких часов пришлось разбираться весь день. И еще два дня на подготовку исследования для Хабра.»

Это конечно, когда уже во всем разобрался, все кажется логичным и понятным. Но когда только начинаешь погружаться в криптографию, то понимаешь, что это ЖОПА. Ведь как думаешь в начале? Да что там, ведь столько компаний вбухивают бабла в нее, такой хайп стоит, «нескольких часов хватит», чтобы разобраться.

Пикантности ситуации добавляет тот факт, что, например в джаве, стандартным криптографическим API от Sun-овского криптопровайдера файл с сертификатом не прочитать, т.к. API требует именно структуру Certificate на входе, а вот BouncyCastle тут дает поблажку и может сам выпарсить ее из контейнера. Что на мой взгляд плохо, т.к. заставляет полагаться на неочевидное и негарантированное поведение конкретного криптопровайдера. И вот представьте, хотите вы структурировать для себя информацию, делаете демо пример, и с одним провайдером он работает, а с другим нет! И вот сиди думай, где тут ошибки — у тебя или в одной из библиотек, а если в библиотеке, то в какой именно и что гуглить.

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

Еще пару часов рыскаешь по гуглу, проникаешься разрухой. Хорошо, если к этому моменту удастся уже выйти на RFC (еще поди пойми, которое из них сейчас актуально!) с описанием всей этой криптографической мишуры. На этом этапе уже понимаешь, что BouncyCastle, в общем то, неплох — разбор ASN.1 структур там сделан неплохо. Собственно, пожалуй, только этим и можно нормально пользоваться, даже без документации, ее вышеприведенные RFC заменяет.

Автор в итоге и пришел к такому решению — используем хорошую часть библиотеки, забиваем на непонятную. Фактически при разборе сертификата нужно знать только его структуру, а она в RFC описана. Дальше только с помощью классов библиотеки парсим структуру и вытаскиваем нужное.

Ну и еще хотелось бы предостеречь читателей от статьи ASN.1 простыми словами (кодирование типа REAL). На мой взгляд, там не только простые слова, а героическое возведение и штурм укреплений, когда можно было пройти через ворота. Лучше ее не читать, только каши в голове добавит.

Да, и еще не могу не упомянуть замечательный сайт https://lapo.it/asn1js/ (у него есть и автономный режим работы — скачиваете html-ку) для декодирования ASN.1. Можно как вставлять как base64 так и hex, пробелы выкусываются автоматически

Только вот примерно все, описанное в топике, к криптографии не имеет ни малейшего отношения. Просто есть некий файл в ASN1/DER, который надо разобрать, понять, что внутри дерево, пройтись по нему и найти там нужное. Вместо ASN1 мог быть RIFF, TIFF, EBML, BSON, Protobuf, Apache Avro и т.д. — в общем, любой бинарный контейнер. Радикально ничего от этого не меняется.

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

Впрочем, соглашусь, что к академической криптографии описанное в посте действительно никак не относится. В академической криптографии вообще никаких контейнеров нет. Однако мы все же говорим о практическом применении. И форматы файлов — это тоже часть практической криптографии. Можете назвать еще хоть одну массовую, не нишевую, область, где ASN.1 используется? Сомневаюсь. Так что с практической точки зрения работа с ASN.1 почти равно криптографии. Или даже так: работа с ASN.1 почти всегда подразумевает касание криптографии.

Это не совсем так. Скажем, если вы захотите сгенерировать подпись с помощью какой-то железки, которой на вход подают массив байт и ид. ключа в этой железке, а на выходе зашифрованный приватной частью этого ключа массив этих байт, то что вы будите делать? Если вы наивно полагаете, что достаточно будет запихать в нее те данные, что вы хотите подписать и получившийся массив записать в «любой бинарный контейнер», то вы заблуждаетесь. Потому, что по RFC для вычисления подписи шифруется не ваш массив, и даже не хеш от него, а хеш от ASN.1 контейнера специального вида, куда засунут хеш от вашего массива + описание алгоритма взятия хеша, параметры этого алгоритма и еще может быть чего. И шифруется уже этот контейнер, преобразованный в массив байт вполне конкретным способом.

Я могу назвать с десяток (вроде LDAP, SNMP, H.323, UMTS, LTE, WiMAX, 3GPP и вообще очень много всего в том, что касается телекомов и вокруг них), но вы удобно скажете, что это все «нишевые области». Впрочем, чем тогда «криптография» не нишевая?

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

И вот в посте ровно пример того, где работа с ASN.1 ну совсем никак не связана с использованием криптографии. Ничего не шифруется или подписывается с целью сокрытия содержания или защиты от изменений. Сертификат используется просто как источник данных. Если бы эти данные можно было получить, обратившись в какую-нибудь БД или веб-сервис — скорее всего так бы и сделали, а не разбирали сертификаты.

Телеком — это именно что нишевая область. Криптография не нишевая, потому что это чисто утилитарная область, само по себе она никому не сдалась, нужна только вместе с чем-то. И областей, требующих для себя криптографии, вполне много.

Когда занимался такими же задачами, то вместо ASN1 Editor использовал asn1js. Который отлично работает со строками. В ASN1 есть несколько типов строк, и ASN1 Editor кириллицу отображает плохо. А доработать код на C++ для поддержки Unicode не так-то просто.

И сделал пару доработок для asn1js, чтобы отображать СНИЛС, ИНН,… и иметь удобный способ сравнивать сертификаты/подписи.

К комитам есть скриншоты, посмотрите, может пригодится:

print description — классная фича, жалко, что похоже автор pull request-ы почему-то не принимает, но отослать все равно надо бы

При попытках заверения личных документов могут возникать ситуации, при которых система не видит сертификат электронной подписи. Это вызывает неудобства, т. к. для получения той или иной услуги требуется посещение учреждений. Устранить ошибку помогает правильная настройка системы, внесение некоторых изменений в реестр Windows.

Почему компьютер не видит сертификат электронной подписи – основные причины

Возникновению такой ошибки способствуют следующие факторы:

Пошаговая инструкция решения проблемы

Если флеш-накопитель с ЭЦП не работает, выполняют такие действия:

Почему «КриптоПро CSP» может не видеть ключей

В таком случае проверяют следующие параметры:

При установке плагина выполняют следующие действия:

Если ранее файлы были установлены неправильно и перенос на новый носитель не выполняется, очищают реестр операционной системы.

Для этого в меню CSP предусмотрена клавиша «Удалить пароли». Если приложения и надстройки работают без ошибок, а Event Log выдает ложную информацию, нужно сканировать файлы с помощью функции Sfc/scannow.

После этого выполняют повторную регистрацию компонентов посредством MSIExec/regserver.

Что делать при отсутствии своего сертификата в списке на странице «Ваши сертификаты»

Если подобный объект не был установлен, переходят на интернет-страницу удостоверяющего центра, скачивают и устанавливают компоненты личной электронной подписи. Если сертификат скачан ранее, проверяют правильность его загрузки. Для этого выполняют следующие действия: