В ПОИСКАХ КВАЛИФИЦИРОВАННЫХ СЕРТИФИКАТОВ X 509 МЫ РАЗБИРАЕМСЯ С НОМЕРАМИ ИНН И ОГРН

Время на прочтение

Чудище обло, озорно, огромно, стозевно и лаяй.

Набор технологий, который мы по привычке именуем сертификатами SSL, представляет из себя здоровенный айсберг, на вершине которого зеленый замочек слева от доменного имени в адресной строке вашего браузера. Правильное название X.509 сертификат, который восходит к X.500 стандарту ITU-T DAP (Directory Access Protocol). D AP не взлетел, в IETF его посчитали неудобным для использования со всеми этими OSI нагромождениями и вместо него придумали LDAP, Lightweight DAP где первая буква обозначает «легковесный». Те, кому пришлось настраивать, или что хуже производить его отладку могут оценить иронию в полной мере. Никогда еще первая буква аббревиатуры так не лгала, не считая SNMP.

Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.

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

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

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

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

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

Сертификат ключа подписи – документ, который может быть как в бумажном виде, так и в электронном. Обязательно содержит в себе открытый ключ и сведения о владельце подписи, а также об удостоверяющем центре, выдавшем ключ. Общепринятый формат информации, содержащейся в сертификате, называется Х509.

На основании и должен удовлетворять требованиям:

Каждый СКПЭП должен содержать следующие атрибуты и расширения (в указанном порядке):

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

3 Состав имени субъекта

Обязательными полями имени субъекта являются следующие:

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

4 Состав имени издателя СКПЭП

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

Приложение 1. Формат ФИО.

Приложение 2. Формат названия субъекта федерации.

Приложение 3. Формат названия населенного пункта.

Приложение 4. Формат наименования организации.

Приложение 5. Формат подразделения организации.

Приложение 6. Формат должности.

Приложение 7. Формат ОГРН.

Приложение 8. Формат ОГРНИП.

Приложение 9. Формат СНИЛС.

Приложение 10. Формат ИНН.

Приложение 11. Набор разрешенных символов.

Приложение 12. Дополнение «Политики сертификата».

Приложение 13. Пример корневого сертификата УЦ.

Приложение 14.    Пример сертификата ЮЛ (должностное лицо)

Приложение 15.    Пример сертификата ЮЛ (автомат)

Приложение 16.    Пример сертификата ФЛ

Приложение 17.    Пример сертификата ИП

Усиленная квалифицированная электронная подпись – это электронная подпись, обладающая дополнительными признаками защищённости: ключом проверки и подтверждёнными средствами электронной подписи (п. 4 ст. 5 Федерального закона «Об электронной подписи»).

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

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

Усиленная квалифицированная электронная подпись создается с привлечением криптографических средств, подтвержденных компетентными органами, а именно ФСБ РФ. Гарантом подлинности в данном случае выступает специальный сертификат, выданный аккредитованным удостоверяющим центром. Электронный документ, подписанный УКЭП, имеет такую же юридическую силу, как и бумажный, который подписан собственноручно.

Для получения электронной подписи необходимо обратиться в любой аккредитованный удостоверяющий центр.

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

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

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

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

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

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

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

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

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

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

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

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

(0, 2254) SEQUENCE – корневая последовательность, в скобках здесь и далее (смещение, длина)
(4, 2173) SEQUENCE – сертификат
(8, 3) CONTEXT SPECIFIC – версия сертификата
(13, 17) INTEGER – серийный номер
(32, 8) SEQUENCE – идентификатор алгоритма подписи
(42, 248) SEQUENCE – имя издателя
(293, 30) SEQUENCE – период действия
(325, 654) SEQUENCE – имя субъекта

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

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

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

Откуда берутся сертификаты?

Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.

Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

Конвертируем связку ключей из проприетарного формата в PKCS12.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

Смотрим на результат:

keytool -list -v -alias selfsigned -storepass password -keystore keystore.jks

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

LetsEncrypt

Можно бесплатно получить X.509 сертификат LetsEncrypt и для этого не нужно даже заходить на вебсайт, достаточно установить certbot.

sudo emerge -av certbot #для Gentoo
sudo apt-get install certbot -t stretch-backports #Debian
sudo dnf install certbot #Fedora
sudo certbot certonly —standalone -d example.com -d www.example.com

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

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

Комаров Алексей Петрович: взгляд изнутри

——НАЧАТЬ СЕРТИФИКАТ——
MIIIzjCCCH2gAwIBAgIRAJ6w9zrKuNKX5xH+FfdJYxwwCAYGKoUDAgIDMIH4MRww
GgYJKoZIhvcNAQkBFg11ZGNAbGVucmVnLnJ1MRgwFgYFKoUDZAESDTExMjQ3MDMw
MDAzMzMxGjAYBggqhQMDgQMBARIMMDA0NzAzMTI1OTU2MQswCQYDVQQGEwJSVTEs
MCoGA1UECAwjNzgg0LMu0KHQsNC90LrRgi3Qn9C10YLQtdGA0LHRg9GA0LMxJjAk
BgNVBAcMHdCh0LDQvdC60YIt0J/QtdGC0LXRgNCx0YPRgNCzMR0wGwYDVQQKDBTQ
k9Ca0KMg0JvQniAi0J7QrdCfIjEgMB4GA1UEAwwX0KPQpiDQk9Ca0KMg0JvQniDQ
ntCt0J8wHhcNMTcwMzMxMTayODEwWhcNMTgwMzMxMTAYODEwWjCCAO4xIzAhBgkq
hkiG9w0BCQEWFGFwX2tvbWFyb3ZAbGVucmVnLnJ1MRowGAYICoUDA4EDAQESDDAW
Nzg0MjM1NDk2NjEWMBQGBSqFA2QDEgswNzMxMTk5NjY2ODEYMBYGBSqFA2QBEg0x
MDc3ODQ3MTkyNjA5MSwwKgYDVQQMDCPQk9C70LDQstC90YvQuSDRgdC/0LXRhtC4
0LDQu9C40YHRgjFBMD8GA1UECww40JTQtdC/0LDRgNGC0LDQvNC10L3RgiDQu9C1
0YHQvdC+0LPQviDQutC+0LzQv9C70LXQutGB0LAxajBoBgNVBAoMYdCa0L7QvNC4
0YLQtdGCINC/0L4g0L/RgNC40YDQvtC00L3Ri9C8INGA0LXRgdGD0YDRgdCw0Lwg
0JvQtdC90LjQvdCz0YDQsNC00YHQutC+0Lkg0L7QsdC70LDRgdGC0LgxKjAoBgNV
BAkMIdGD0Lsu0KLQvtGA0LbQutC+0LLRgdC60LDRjywg0LQuNDEmMCQGA1UEBwwd
0KHQsNC90LrRgi3Qn9C10YLQtdGA0LHRg9GA0LMxLDAqBgNVBAgMIzc4INCzLtCh
0LDQvdC60YIt0J/QtdGC0LXRgNCx0YPRgNCzMQswCQYDVQQGEwJSVTEoMCYGA1UE
Kgwf0JDQu9C10LrRgdC10Lkg0J/QtdGC0YDQvtCy0LjRhzEXMBUGA1UEBAwO0JrQ
vtC80LDRgNC+0LIxajBoBgNVBAMMYdCa0L7QvNC40YLQtdGCINC/0L4g0L/RgNC4
0YDQvtC00L3Ri9C8INGA0LXRgdGD0YDRgdCw0Lwg0JvQtdC90LjQvdCz0YDQsNC0
0YHQutC+0Lkg0L7QsdC70LDRgdGC0LgwYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH
KOUDAGIeAQNDAARA2jaQisiN++YQULAiW4b8Llik90VIKNPqUcEOVlrfplASb2W/
qc9giz+rP1/VvQXAmRKPaL3dM33MExypCJOlGaOCBEUwggRBMA4GA1UdDwEB/wQE
AwIDqDAdBgNVHQ4EFgQU7SOIwRLKC8mDQV/q2KtCaTA06Q8wNQYJKwYBBAGCNxUH
BCgwJgYeKoUDAgIyAQmDx+sNh/eeXoXlhVqDn/dWgZtags1fAgEBAgeAMIIBYwYD
VR0jBIIBWjCCAvaAFNGDmDS2EE52TJ+tKf2SJRHjAFYJoYIBKaSCASUwggEhMRow
GAYIKoUDA4EDAQESDDAwNzcxMDQ3NDM3NTEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2
NzAxMR4wHAYJKoZIhvcNAQkBFg9kaXRAbWluc3Z5YXoucnUxPDA6BgNVBAkMMzEy
NTM3NSDQsy4g0JzQvtGB0LrQstCwINGD0LsuINCi0LLQtdGA0YHQutCw0Y8g0LQu
NzEsMCoGA1UECgwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40Lgx
FTATBgNVBAcMDNCc0L7RgdC60LLQsDEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC6
0LLQsDELMAkGA1UEBhMCulUxGzAZBgNVBAMMETCj0KYgMSDQmNChINCT0KPQpoIR
BKgeQAWpGF6C5hHB/EETxEYwOQYDVR0lBDIwMAYIKwYBBQUHAwIGCCsGAQUFBwME
BggqhQMFARgCLAYIKoUDBQEYAgYGBiqFA2QCATBJBgkrBgeAYI3FQoEPDA6MAoG
CCsGAQUFBwMCMAoGCCsGAQUFBwMEMAoGCCqFAwUBGAIsMAoGCCqFAwUBGAIGMAgG
BiqFA2QCATATBgNVHSAEDDAKMAgGBiqFA2RxATCCAQYGBSqFA2RwBIH8MIH5DCsi
0JrRgNC40L/RgtC+0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyA0LjApDCoi0JrR
gNC40L/RgtC+0J/QoNCeINCj0KYiINCy0LXRgNGB0LjQuCAyLjAMTtCh0LXRgNGC
0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJbQodCkLzEy
NC0zMDEwINC+0YIgMzAuMTIuMjAxNgxO0KHQtdGA0YLQuNGE0LjQutCw0YIg0YHQ
vtC+0YLQstC10YLRgdGC0LLQuNGPIOKEltCh0KQvMTI4LTI5ODMg0L7RgiAxOC4x
MS4yMDE2MDgGBSqFA2RvBC8MLSLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQ
tdGA0YHQuNGPIDMUNi4xKTBWBgNVHR8ETzBNMCWgI6Ahhh9odHRwOi8vY2EubGVu
b2JsLnJ1L2UtZ292LTUuY3JsMCSgIqAghh5odHRwOi8vdWNsby5zcGIucnUvZS1n
b3YtNS5jcmwwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzAChh9odHRwOi8vY2Eu
bGVub2JsLnJ1L2UtZ292LTUuY2VyMAgGBiqFAwICAwnNBAEEe1iKkhV4BQcDsBSAJa
кВтfh5tNaPIp/jFc+HZtpmgJoGU8CpOdX3I5YAgJTx9O+Q4ylHwJl68rfCD44s0Q4
wqE=
——КОНЕЦ СЕРТИФИКАТА——

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

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

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

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

Сценарий №2 — использую subjectAltnName, Люк

Вот представьте вам приложение, использующее веб-сервер: вики, WordPress или Cacti. Вы построили доступ по https, приобрели или сами создали и подтвердили сертификат. Все должно быть в порядке, но зеленой замочки все равно нет. Браузер подозревает, что сертификат подготовили неправильные пчелы, из-за того, что полное доменное имя сервера и имя хоста, указанные в адресной строке, не соответствуют. Так иногда бывает, что DNS-сервер указывает на mars.domain.com, а веб-сервер настроен на venus.domain.com.

Если администратору в силе перфекционизма нужны за пределами проезда нужны еще и шашечки — вожделенный зеленый замочек, то нужно переделать сертификат X.509, определив в нем subjectAltName.

Откройте файл openssl.cnf и в разделе req следующие строки.

А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.

openssl genrsa -out private.key 3072
openssl req -new -x509 -key private.key -sha256 -out certificate.pem -days 730

Использованные материалы

Определение X.509 сертификатов есть в архиве ITU-T

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.

Номенклатура сертификатов

Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.

По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.

Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:

Более подробно можно прочитать в Хабрапоспе компании TutHost. Также атрибут subject X.509 EV сертификата содержит значения jurisdictionOfIncorporationCountryName, businessCategory, и serialNumber.

По свои свойствам сертификаты бывают следующих типов.

В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.

Шаг 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 — International Organization for Standardization (ISO)
1.2 — ISO Member Bodies
1.2.643 — Russian federation

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

1.2.643.100 (часть OID’а 1.2.643.100.1, соответствующего ОГРНу, и OID’а 1.2.643.100.3, соответствующего СНИЛСу) — Дополнительные идентификаторы
1.2.643.3.131 (часть OID’а 1.2.643.3.131.1.1, соответствующего ИННу) — ФГУП ГНИВЦ ФНС РОССИИ

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

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

– День добрый! Указанные Вами OID утверждены приказом № 795 ФСБ России от 27.12.2011.

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

Продолжаем изучать Приказ ФСБ РФ от 27 декабря 2011 г. № 795 и обращаем внимание на то, что заполнение полей и их атрибутов зависит от владельца квалифицированного сертификата — физического или юридического лица. К примеру, описание заполнения атрибута commonName (общее имя):

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

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

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

2.5.4.3 – Наименование юридического лица
2.5.4.8 — Наименование субъекта Российской Федерации
1.2.643.3.131.1.1 – ИНН
1.2.643.100.1 – ОГРН
1.2.643.100.3 – СНИЛС представителя юридического лица
1.2.840.113549.1.9.1 – Адрес электронной почты

Сценарий №1 — найти следующего в связке

Связка сертификатов — Объединение нескольких X.509 сертификатов в один файл, чаще всего в формате PEM. Связка передается по сети в момент протокола рукопожатия SSL/TLS.

Самый сок начинается, когда имеете дело со связкой сертификатов, a. k. a certificate chain. Часто просматривая лапшу в связке ключей jks непросто понять как найти родительский сертификат, когда там россыпь новых и старых сертификатов на несколько доменных имен.

Рассмотрим связку сертификатов *.novell.com. Расширение Authority Key Identifier (AKI) должно совпадать с Subject Key Identifier (SKI) старшего в связке.

Certificate Authority Key Identifier
Size: 20 Bytes / 160 Bits
51 68 ff 90 af 02 07 75 3c cc d9 65 64 62 a2 12 b8 59 72 3b

Так и есть, SKI сертификат DigiCert имеет то же значение.

Certificate Subject Key ID
Size: 20 Bytes / 160 Bits
51 68 ff 90 af 02 07 75 3c cc d9 65 64 62 a2 12 b8 59 72 3b

Для корневого сертификата AKI = SKI, а также isCa=true

Certificate Basic Constraints
Critical
Is a Certificate Authority

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

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

В расчетах по времени произошла ошибка — вместо запланированных нескольких часов пришлось разбираться весь день. И еще два дня на подготовку исследования для Хабра.

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