При использовании сервиса «1С-Отчетность» необходимо иметь ключ ЭЦП и программу для чтения и поддержки криптографии. В основном используется программа КриптоПро CSP. При первичном подключении или обновлении программы КриптоПро CSP может быть установлена актуальная, а не сертифицированная версия.
На данный момент (май, 2023 года) актуальная версия имеет код 5.0.12600, а сертифицированная — 5.0.12000. Некоторые сборки «1С:Предприятие» не могут работать на актуальной версии программы КриптоПро CSP, так же и большинство ключей ЭЦП некорректно читаются актуальной версией программы криптографии.
Если же установлена актуальная версия программы, то в «1С:Предприятие» будет показана такая ошибка:
Рисунок 1 — Ошибка Язык описания абстрактного синтаксиса данных
Некорректное чтение ключа ЭЦП при проверке контейнера сертификата выглядит так:
Рисунок 2 — Проверка контейнера ключа ЭЦП
Для исправления данной ошибки требуется установить сертифицированную версию КриптоПро CSP версии 5.0.12000. Её можно скачать с оффициального сайта www.cryptopro.ru.
Рисунок 3 — Скачивание сертифицированной версии КриптоПро CSP
Для установки скачанной программы необходимо удалить с ПК установленную версию и выполнить чистую установку программы. После установки рекомендуется проверить запись ключей ЭЦП на ПК.
При правильном выполнении инструкции ошибка Язык описания абстрактного синтаксиса данных пропадет и ключ ЭЦП будет работать корректно.
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
X86 версия 1с c отключённой службой xtacache должна работать. Пробовали? |
|
Знания в базе знаний, поддержка в техподдержке |
|
 |
WWW |
|
Jumuro |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 1 раз |
Автор: Максим Коллегин X86 версия 1с c отключённой службой xtacache должна работать. Пробовали? Да, пробовал. Перед запуском 1С (x86) останавливал (но не отключал поностью) службу. |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Если предоставите удаленный доступ — посмотрю. |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
|
Jumuro
оставлено 07.06.2022(UTC) |
1 пользователь поблагодарил Максим Коллегин за этот пост.|
Jumuro |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 1 раз |
Автор: Jumuro Здравствуйте, коллеги! Уже в который раз пытаюсь заставить работать следующую связку: В самой оснастке криптопро всо ок — шифруется и расшифровывается без проблем. Цитата: Язык описания абстрактного синтаксиса данных. Базовый код ошибки кодирования сертификата. 1С:Предприятие 8.3 (8.3.20.1838) (пробовал и x86 и x64) Автор: Максим Коллегин Если предоставите удаленный доступ — посмотрю. Проблема была решена, за что огромное спасибо Максиму Коллегину. |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Мы перевыложили дистрибутив, проблема должна уйти, единственное, если была установлена очень старая версия CSP — желательно перед установкой CSP её деинсталлировать. |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
docent_963 |
|
|
Статус: Новичок Группы: Участники
|
Возникла идентичная проблема на 11 Винде. Платформа 20.1914 |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
1С — 32-х битная? CSP установлен с нуля? |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
docent_963 |
|
|
Статус: Новичок Группы: Участники
|
Платформа х64. CSP скачал поставил (версия дэмо. Кл в процессе приобретения). Что такое xtacache ? |
|
|
|
|
Максим Коллегин |
|
|
Статус: Сотрудник Группы: Администраторы Сказал «Спасибо»: 21 раз |
Прочитайте пожалуйста первое сообщение в этой теме. |
|
Знания в базе знаний, поддержка в техподдержке |
|
|
|
WWW |
|
docent_963 |
|
|
Статус: Новичок Группы: Участники
|
Автор: docent_963 Платформа х64. CSP скачал поставил (версия дэмо. Кл в процессе приобретения). Что такое xtacache ? Оказывается при переносе с VIPNET надо было сертификат копировать с форматом шифрования AES. Скопировал заново, передобавил в Крипто про, перезапустил 2 раза базу и заработало. Теперь другие ошибки, но это уже надеюсь не крипто про. |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Ошибка ЭДО
Добрый день всем. При создании электронного документа выдает такую ошибку.
1С:Предприятие 8.3 (8.3.12.1685)
Бухгалтерия предприятия, редакция 3.0 (3.0.67.43)
Режим : Серверный, PostgreSQL
Не удается создать электронный документ, выдает ошибку: «Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
Подробности см. в журнале регистрации.»
Сообщения из журнала регистрации:
Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
: Ошибка при вызове метода контекста (Установить)
ОбъектXDTO.Установить(ИмяСвойства, Значение);
по причине:
Несоответствие типов XDTO
по причине:
Ошибка проверки данных XDTO:
Значение: ‘20%’ не соответствует простому типу:
Значение не соответствует значениям фасета перечисления
Выполнение операции: Формирование ЭД.
: Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
Создаем свой ЯЗЫК ПРОГРАММИРОВАНИЯ. Лексер, Парсер, Абстрактное синтаксическое дерево (AST)
ВызватьИсключение ЭлектронноеВзаимодействиеСлужебный.СоединитьОшибки(Ошибки);
Помогите пожалуйста, может кто сталкивался с данной проблемой
Источник: buh.ru
Windows 10, PowerShell: файл сертификата открытого ключа (X.509) изнутри
Раньше я не уделял внимания формату файла сертификата открытого ключа. Теперь я немного покопался в этом формате и нашел там для себя много нового и интересного. В этой статье я не ставлю себе цель описать формат файла сертификата во всей полноте (это слишком большая работа; кроме того, эта работа уже сделана в тексте соответствующего стандарта), но хочу отметить некоторые интересные моменты.
Стандарты
Формат сертификата открытого ключа описан в стандарте «X.509», который создан «Международным союзом электросвязи» (сокращенно «МСЭ», по-английски «ITU»). Точнее, над стандартом работали и работают в отделе (секторе) стандартизации электросвязи этой организации (по-английски «ITU-T», в прошлом веке он назывался «CCITT»).
Первая версия (редакция) этого стандарта появилась в 1988 году, а сейчас актуальна версия 9 от 2019 года. Над стандартом продолжают работать. Однако, насколько я понимаю, сейчас в интернете больше ориентируются на документ «RFC 5280» (над документами «RFC» работает «Инженерный совет Интернета», по-английски «IETF»), адаптирующий стандарт «X.509» к реалиям интернета. Вроде бы, именно из документа «RFC 5280» появился термин «PKIX» (инфраструктура открытых ключей [PKI] на базе стандарта «X.509»). Документ «RFC 5280» вышел в 2008 году, в нем идет речь о реализации версии 3 стандарта «X.509» (эта версия разрабатывалась в период 1997-2004 годов).
Файл для анализа и инструменты анализа
Я создал из диспетчера веб-сервера IIS самозаверенный сертификат открытого ключа для тестирования работы с локальным сайтом по протоколу HTTPS. Этот файл я и буду тут анализировать.
Ошибка построения пути сертификации
В качестве инструмента для анализа я в основном использую программу-оболочку «PowerShell» версии 7. Напомню, я работаю в операционной системе «Windows 10».
Иногда заглядываю в сохраненные консоли «certlm.msc» (хранилище сертификатов компьютера, для работы требуются права администратора компьютера) и «certmgr.msc» (хранилище сертификатов текущего пользователя, для работы достаточно прав текущего пользователя). Их легко можно вызвать прямо из командной строки из любого местоположения с помощью команд certlm и certmgr , так как эти файлы хранятся в системной папке %windir%System32 . Файлы сохраненных консолей с расширением «.msc» по умолчанию привязаны (их имена при запуске передаются в качестве входного параметра) к исполняемому файлу «mmc.exe» (компонента «Консоль управления Microsoft» операционной системы), который тоже хранится в системной папке %windir%System32 .
Просмотр хранилищ сертификатов и сертификатов в них из «PowerShell»
В файловых системах операционных систем «Windows» обычно бывает несколько «корней» (в отличие от Unix-подобных операционных систем; там в файловой системе один «корень»), которые обозначают латинскими буквами с двоеточием (например, «A:», «C:», «D:» и так далее) и называют «логическими дисками» (или «томами»), по-английски «logical drive» (или «volume»).
В принципе, слово «том» кажется теперь более правильным, потому что слова «диск» и «привод» тянутся со времен, когда запоминающие устройства (накопители) были в основном с магнитными дисками и с подвижными частями, которые приводились в движение «приводами». У нас сейчас многие переводят с английского языка слово «drive» как «диск», хотя «drive» — это «привод». Во многих случаях буквенные обозначения томов соответствуют реальным физическим устройствам-накопителям, поэтому их часто называют словом «drive».
В документации программы-оболочки «PowerShell» буквенные обозначения томов называют «file system drive» (том файловой системы).
По принципу томов файловой системы в языке «PowerShell» существуют так называемые «провайдеры» или «поставщики» (по-английски «provider»). У этих провайдеров тоже есть «приводы»: это короткие слова или даже части слов (или аббревиатуры), которые используются для предоставления (обеспечения, поставки) быстрого и простого доступа к данным или компонентам, доступ к которым другими способами затруднен. Например, для доступа к переменным среды можно использовать привод «Env:» провайдера переменных среды, для доступа к реестру Windows можно использовать приводы «HKLM:» и «HKCU:» провайдера реестра и так далее. См. статью «about_Providers» документации программы-оболочки «PowerShell».
Для доступа к хранилищам сертификатов и сертификатам в этих хранилищах можно использовать привод Cert: провайдера сертификатов. При этом с хранилищами сертификатов можно работать так же, как с обычными папками файловой системы (напомню, хранилища сертификатов не соответствуют какой-либо папке файловой системы, это просто что-то вроде фильтра, инструмента, который собирает сведения о цифровых сертификатах, физически хранящихся в разных местах на компьютере), а с сертификатами можно работать так же, как с обычными файлами в файловой системе. Удобно продолжать использовать псевдонимы cd (сменить папку) и dir (показать список файлов и папок в текущей папке) командлетов Set-Location и Get-ChildItem соответственно. См. статью «about_Certificate_Provider» документации «PowerShell».
Итак, в командной строке программы-оболочки «PowerShell» перейдем в том Cert: и выведем список хранилищ сертификатов. Вот как это выглядит у меня:
PS C:> cd Cert: PS Cert:> dir Location : CurrentUser StoreNames : Location : LocalMachine StoreNames :
Это те самые два главных хранилища сертификатов, которые описаны, к примеру, в статье «Working with Certificates» на сайте компании «Microsoft»: хранилище сертификатов текущего пользователя и хранилище сертификатов компьютера. Под названием каждого из этих хранилищ виден массив названий подхранилищ (каждый массив завершается многоточием, которое обозначает то, что все названия из массива не влезли в отведенную строку).
Теперь можно последовательно перейти к нужному хранилищу (подхранилищу) сертификатов, либо можно сразу перейти к нужному подхранилищу, набрав полный путь (если вы уже сразу знаете нужный путь целиком):
PS C:> cd Cert:LocalMachineMy PS Cert:LocalMachineMy> dir PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy Thumbprint Subject EnhancedKeyUsageList ———- ——- ——————— D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 CN=IlyaComp Проверка подлинности сервера
Как видно из кода выше, в подхранилище Cert:LocalMachineMy есть только один сертификат открытого ключа. Команда dir уже вывела таблицу с тремя свойствами этого сертификата в окно терминала.
Но следует понимать, что у сертификата гораздо больше свойств, чем три. Просто остальные свойства не поместились по ширине в окно терминала. Для вывода всех свойств сертификата есть более удобные способы, чем способ по умолчанию.
Просмотр всех свойств сертификата из «PowerShell»
К конкретному сертификату можно обратиться по его так называемому «отпечатку» (thumbprint). Как видно из кода выше, отпечаток представляет собой довольно длинное шестнадцатеричное число. Очевидно, что при использовании его лучше скопировать, а не набирать вручную.
Итак, для удобства сохраним нужный объект сертификата в переменную $c , чтобы не обращаться каждый раз к длиннющему отпечатку сертификата. Затем через оператор конвейера (pipeline) | передадим объект сертификата командлету Format-List , который выведет все свойства сертификата в окно терминала в виде списка (символ звездочки * обозначает вывод всех свойств сертификата, но этому командлету можно передать ограниченный список свойств, чтобы вывести только те, которые нужны в данный момент):
PS Cert:LocalMachineMy> $c = Get-Item D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PS Cert:LocalMachineMy> $c | Format-List *
PSPath : Microsoft.PowerShell.Security Certificate::LocalMachineMy D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PSParentPath : Microsoft.PowerShell.SecurityCertificate::LocalMachineMy PSChildName : D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PSDrive : Cert PSProvider : Microsoft.PowerShell.SecurityCertificate PSIsContainer : False EnhancedKeyUsageList : DnsNameList : SendAsTrustedIssuer : False EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty PolicyId : Archived : False Extensions : FriendlyName : localhost HasPrivateKey : True PrivateKey : IssuerName : System.Security.Cryptography.X509Certificates.X500DistinguishedName NotAfter : 20.10.2023 3:00:00 NotBefore : 20.10.2022 17:56:04 PublicKey : System.Security.Cryptography.X509Certificates.PublicKey RawData : SerialNumber : 4931C370DB54C8B8426A88B0D254E17E SignatureAlgorithm : System.Security.Cryptography.Oid SubjectName : System.Security.Cryptography.X509Certificates.X500DistinguishedName Thumbprint : D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 Version : 3 Handle : 2125934225808 Issuer : CN=IlyaComp Subject : CN=IlyaComp
Как видно из кода выше, для некоторых свойств, которые попроще, в списке сразу выводятся значения этих свойств. Для свойств, в которых записана ссылка на объект, выводится только тип объекта. Чтобы просмотреть записанный в таком свойстве объект, нужно забираться поглубже. Значением некоторых свойств является массив байтов, в этом случае значения байтов в массиве выводятся через запятую. В некоторые свойства не записано никакого значения, поэтому их значение равно значению $null (в списке выше напротив названий таких свойств после двоеточия ничего не выведено).
В свойстве Version записано значение 3 . Насколько я понимаю, тут подразумевается версия 3 стандарта «X.509», о которой упоминалось в начале данной статьи.
В этот раз меня в первую очередь интересовали свойства, в которых может содержаться информация об именах и названиях: DnsNameList , Extensions , FriendlyName , IssuerName , SubjectName , Issuer и Subject .
При анализе значений свойств сертификата может понадобиться умение читать содержимое массивов байтов. Это не очень сложно, если знать, по каким стандартам эти байтовые массивы в значениях свойств сертификата организованы и где можно удобно просмотреть стандарты, почитать соответствующие справочники. Ниже я покажу, как можно это делать, на примере свойства IssuerName («имя издателя», то есть имя сущности, создавшей и заверившей данный сертификат открытого ключа).
Читаем байтовый массив
Как видно из списка свойств сертификата выше, свойство IssuerName содержит ссылку на объект класса System.Security. Cryptography. X509Certificates. X500DistinguishedName . Просмотрим список свойств со значениями для этого объекта:
PS Cert:LocalMachineMy> $c.IssuerName | Format-List * Name : CN=IlyaComp Oid : System.Security.Cryptography.Oid RawData :
Очевидно, что значение свойства Issuer сертификата в данном случае совпадает со значением поля Name свойства IssuerName сертификата. Но мне стало интересно, что содержится в поле RawData свойства IssuerName сертификата. Видно, что там содержится массив байтов. Но что они означают?
Сначала я предположил, что там записано то же самое, что в поле Name . И действительно, часть байтового массива содержит строку IlyaComp в кодировке UTF-8. Но там есть и что-то еще. С налета разобраться в этом не получилось, поэтому я приступил к подробному анализу. Получим в окно терминала полное содержимое разбираемого массива байтов:
PS Cert:LocalMachineMy> «» + $c.IssuerName.RawData 48 19 49 17 48 15 6 3 85 4 3 19 8 73 108 121 97 67 111 109 112
По умолчанию программа-оболочка «PowerShell» выводит массив «вертикально», то есть выделяя для каждого элемента массива отдельную строку. Это неудобно. Для вывода элементов массива «горизонтально» (в одной строке) я применяю в коде выше конкатенацию пустой строки и анализируемого массива.
Следует иметь в виду, что по умолчанию значения байтов выводятся в десятичной системе счисления. Это неудобно. Для анализа байтовых массивов принято пользоваться значениями в шестнадцатеричной системе счисления. Выведем значения байтов из байтового массива в виде чисел в шестнадцатеричной системе счисления. В языке PowerShell это сделать несложно:
PS Cert:LocalMachineMy> «» + ($c.IssuerName.RawData | ForEach-Object ToString x2) 30 13 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70
В вышеприведенном коде передаем элементы массива байтов через конвейер (pipeline) | командлету ForEach-Object , который применяет к каждому входящему элементу массива (байту) метод System.Byte.ToString . Этот метод преобразует значение байта (целое число) в строку в указанном формате. В данном случае в качестве указания формата в метод System.Byte.ToString передаем строку x2 .
В этой строке формата латинская буква х указывает на вывод числа в шестнадцатеричной системе счисления (регистр буквы х в данном случае имеет значение, от него зависит регистр букв, которыми будут обозначены шестнадцатеричные цифры a, b, c, d, e, f). Число 2 указывает на число цифр в выводимых шестнадцатеричных числах. Очевидно (если вы понимаете, как сочетаются двоичная и шестнадцатеричная системы счисления), что для обозначения значения каждого байта нужно шестнадцатеричное число из двух цифр. (Тут подробнее про настройку форматирования чисел в строке.)
Язык ASN.1, способ сериализации DER и дерево идентификаторов объектов OID
Как оказалось, заполнение байтовых массивов в значениях сертификата открытого ключа по стандарту «X.509» выполняется на языке описания абстрактного синтаксиса данных «ASN.1» (расшифровывается как «Abstract Syntax Notation One»). Я немного о нем почитал и он мне понравился. Тут речь об «абстрактном синтаксисе» потому, что этот язык описывает любые структуры данных, независимо от конкретного языка программирования. Этот язык был создан в 1984 году и до сих пор разрабатывается уже упоминавшейся выше организацией «ITU-T».
Кроме описания структур данных в этом языке описаны разные способы сериализации полученного описания данных. Под словом «сериализация» подразумевают перевод данных в последовательность байтов (или в «серию» байтов, откуда и произошел термин «сериализация»). Там описано более десятка разных способов. Для сертификатов открытого ключа по стандарту «X.509» применяется способ сериализации DER (Distinguished Encoding Rules). Тут подробнее: раздел «Encodings» англоязычной статьи википедии «ASN.1», про способ сериализации DER в англоязычной статье википедии про стандарт «X.690», статья «A Warm Welcome to ASN.1 and DER» на сайте «Let’s Encrypt».
Давайте посмотрим, как это работает на практике на примере байтового массива, который я получил выше.
При сериализации по методу «DER» согласно языка «ASN.1» применяется известный метод записи данных «TLV» (расшифровывается как «type-length-value» или «tag-length-value»). По-русски название этого метода можно озвучить как «тип-длина-значение». Согласно этого метода данные (в том числе вложенные) записываются в указанном порядке: сначала тип данных, потом — длина данных в байтах, и, наконец, значение (собственно, сами данные).
Будем последовательно применять это правило для расшифровки вышеуказанного массива байтов. Возьмем первые два байта:
30 13 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 30 — SEQUENCE (тип данных) 13 — размер данных: 19₁₀ байтов данные: 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70
Первый байт нашего массива со значением 30 в языке «ASN.1» означает тип данных «SEQUENCE» (набор данных разных типов; например, в языке Си эквивалентом этого типа данных является тип struct ). Кстати, для быстрого ознакомления с языком «ASN.1» рекомендую ознакомиться с большой обзорной статьей «A Warm Welcome to ASN.1 and DER» на сайте известного бесплатного центра сертификации «Let’s Encrypt». Эта статья очень удобна для начинающих, там есть разные таблицы соответствия, например, значений байтов и типов данных.
Как видно из кода выше, в нашем случае в байтовом массиве записана структура данных типа «SEQUENCE», имеющая размер в 13 (шестнадцатеричная система) байтов или 19 (десятичная система) байтов. Данными являются 19 байтов, идущие после байта, указывающего размер данных. Если посчитать, получается, что весь остаток массива, кроме первых двух байт, имеет размер в 19 байт, следовательно, кроме структуры данных «SEQUENCE» в наш массив больше ничего не записано.
Продолжим расшифровку. Возьмем следующие два байта.
SEQUENCE
Тип данных «SET» в языке «ASN.1», в принципе, похож на «SEQUENCE», только в данных типа «SEQUENCE» (последовательность) порядок вложенных элементов сохраняется (важен), а в данных типа «SET» (множество) порядок вложенных элементов не сохраняется (не имеет значения). Перейдем к следующим двум байтам (думаю, принцип действия метода «type-length-value» к этому моменту уже должен был проясниться).
SEQUENCE < SET < 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 30 — SEQUENCE (тип данных) 0f — размер данных: 15₁₀ байтов данные: 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 >>
SEQUENCE < SET < SEQUENCE < 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 06 — OBJECT IDENTIFIER (тип данных) 03 — размер данных: 3₁₀ байта данные: 55 04 03 13 — PrintableString (тип данных) 08 — размер данных: 8₁₀ байтов данные: 49 6c 79 61 43 6f 6d 70 >> >
На этом шаге расшифровки получилось, что в структуру данных типа «SEQUENCE» входит сразу два вложенных элемента данных: типа «OBJECT IDENTIFIER» и типа «PrintableString». Второй из них — это тип данных, эквивалентный обычной строке. В данном случае в 8 байтах 49 6c 79 61 43 6f 6d 70 закодировано имя IlyaComp в кодировке UTF-8.
Под типом данных «OBJECT IDENTIFIER» (сокращенно «OID») подразумевают стандартизированное уже несколько раз упоминавшейся организацией «ITU» и международной организацией по стандартизации «ISO/IEC» дерево идентификаторов объектов. В интернете есть ряд сайтов, предоставляющих возможность просмотреть это дерево объектов и найти нужный объект. Например: http://oidref.com.
Каждый идентификатор объекта представляет собой набор номеров пунктов (веток дерева, целых чисел) через точку. В нашем случае в трех байтах 55 04 03 закодирован идентификатор объекта из четырех чисел. Первые два числа X и Y идентификатора объекта кодируются по формуле 40₁₀ * X + Y в первый байт данных, представляющих идентификатор объекта. Раскодируем идентификатор объекта:
В идентификаторе объекта все пункты имеют определенное значение:
- 2 — ветка дерева, общая для организаций «ISO» и «ITU-T»;
- 2.5 — ветка дерева, представляющая службы каталогов;
- 2.5.4 — ветка дерева, представляющая типы атрибутов (свойств) объектов в службах каталогов;
- 2.5.4.3 — ветка дерева, представляющая тип «Common name» атрибута (сокращенно «CN»).
Результат расшифровки байтового массива:
SEQUENCE < SET < SEQUENCE < OBJECT IDENTIFIER: 2.5.4.3 (Common name) PrintableString: «IlyaComp» >> >
Это же коротко записано как CN=IlyaComp и в виде строки содержится в поле Name свойства IssuerName сертификата открытого ключа, а также в свойствах Issuer и Subject сертификата.
Источник: habr.com
Абстрактное описание синтаксиса
ASN.1 обеспечивает стандартный способ представления данных и кодирования их для передачи по сети. Основу модели SNMP составляет множество объектов, которые станции управления могут считывать и записывать при помощи агентов.
ASN.1 обеспечивает стандартный способ представления данных и кодирования их для передачи по сети.
Основу модели SNMP составляет множество объектов, которые станции управления могут считывать и записывать при помощи агентов. Чтобы устройства различных производителей могли сообщать и понимать управляющую информацию, объекты должны быть определены стандартным, не зависящим от производителя образом. Кроме того, они должны единообразно кодироваться при передаче по сети.
Иными словами, SNMP необходим стандартный язык описания объектов вместе с правилами кодирования. Этот язык — абстрактное описание синтаксиса (Abstract Syntax Notation One, ASN.1) — разработчики SNMP заимствовали из стандартов OSI. ASN.1 представляет собой высокоуровневый язык описания типов данных и определяет формат сообщений SNMP при передаче их между агентами и станциями управления. Как и большая часть OSI, он обширен, сложен и не очень эффективен.
Сам язык описания данных определен в стандарте Международной организации по стандартизации (International Standard Organization, ISO) за номером 8824 под названием «Спецификация абстрактного описания синтаксиса, один», а правила кодирования закреплены в стандарте 8825 под названием «Спецификация базовых правил кодирования для ASN.1». Абстрактный синтаксис ASN.1 позволяет определять базовые объекты и затем объединять их в более сложные. Декларации в ASN.1 с функциональной точки зрения схожи с декларациями из файлов-заголовков для программ на С.
АБСТРАКТНЫЙ СИНТАКСИС
SNMP вводит свои условные обозначения, несколько отличные от ASN.1. Базовые типы данных записывают строчными буквами (например, целочисленный тип данных — как INTEGER). Определяемые пользователем типы данных начинаются со строчной буквы, но при этом они должны содержать по крайней мере один символ, отличный от строчной буквы.
Идентификаторы переменных начинаются с прописной буквы, при этом они могут содержать прописные и строчные буквы, цифры и дефисы. Пробелы (знаки табуляции, переноса строки и т. п.) не учитываются. Комментарии начинаются с «- -» (двойного дефиса) и заканчиваются либо вместе с концом строки, либо той же последовательностью символов «- -«.
Допустимые в SNMP базовые типы данных ASN.1 приведены в Таблице 1. Переменная типа INTEGER может в теории принимать любое целочисленное значение, но область ее значений ограничивают другие правила SNMP. В качестве примера использования типов мы рассмотрим, как переменная counter типа INTEGER декларируется и (если необходимо) инициализируется значением, равным 0.
counter INTEGER ::= 0
Очень часто переменную требуется ограничить конкретными значениями или конкретным диапазоном. Это можно сделать посредством определения необходимого подтипа следующим образом:
Status ::= INTEGER < on(1), off(2), unknown(3) >
PacketSize ::= INTEGER (0..1023)
Переменные типа BIT STRING и OCTET STRING представляют собой строку из 0 и более бит или байт, соответственно. Для обоих типов пользователь может задать длину строки и начальное значение. Тип OBJECT IDENTIFIER позволяет идентифицировать объекты. Любой объект в любом официальном стандарте может быть идентифицирован уникальным образом.
Данная цель достигается за счет введения дерева стандартов, при этом каждый объект соответствующего стандарта получает свое место в дереве. Верхний уровень дерева составляют наиболее важные в мире (с точки зрения ISO) организации, а именно ISO и CCITT (теперь ITU), а также их объединение.
Нас интересует прежде всего четвертая ветвь ISO с идентификатором identified-organization(3) (признанные организации по стандартизации), далее dod(6) (Министерство обороны США), а затем internet(1). Ветвь internet содержит четыре ветви. Объекты базы управляющей информации находятся под ветвью mgmt (см. Рисунок 1).
Помимо текстового идентификатора (label) каждая ветвь имеет свой числовой идентификатор (number). Объект может записываться с использованием текстовых или числовых идентификаторов в любой их комбинации. Как видно из описанной структуры, все объекты базы управляющей информации имеют общий префикс
iso.identified-organization.
dod.internet.mgmt.mib-2
или
или
и т. п. Таким образом, любой объект может быть представлен с помощью идентификатора объекта.
Рисунок 1. Каждый объект может быть идентифицирован уникальным образом.
ASN.1 описывает несколько способов создания новых типов данных. Прежде всего, это использование простых составных типов данных (SNMP задействует только три из них). SEQUENCE — это упорядоченный список типов, подобный структуре в С, SEQUENCE OF — одномерный массив переменных одного типа, а CHOICE — объединение из заданного списка типов.
Другой способ состоит в назначении тэгов имеющимся типам данных. Тэги подразделяются на четыре класса или категории: универсальный (universal), общеприкладной (application-wide), контекстно-зависимый (context-specific) и частный (private). Каждый тэг состоит из метки и целочисленного идентификатора, например:
IpAddress ::= [APPLICATION 0] OCTET STRING (SIZE (4))
определяет общеприкладной тип данных в виде строки байт длиной в 4 октета.
ASN.1 описывает сложный механизм макросов, активно используемый в SNMP. Макрос может служить в качестве своего рода прототипа для создания множества новых типов и значений, каждого со своим собственным синтаксисом. Каждый макрос определяет несколько (возможно, необязательных) ключевых слов, используемых при вызове для идентификации параметров (иными словами, параметры макроса идентифицируются не по местоположению, а по ключевому слову).
БАЗОВЫЕ ПРАВИЛА КОДИРОВАНИЯ
Транспортный синтаксис ASN.1 определяет однозначный способ преобразования значений переменных допустимых типов в последовательность байт для передачи по сети. В ASN.1 он называется базовыми правилами кодирования (Basic Encoding Rules, BER). Правила являются рекурсивными, так что кодирование составных объектов представляет собой составление в цепочку закодированных последовательностей составляющих объектов.
Каждое передаваемое значение — как базового, так и производного типа — состоит из трех полей:
- идентификатор;
- длина поля данных (в байтах);
- поле данных.
В отличие от ASN.1, протокол SNMP требует всегда указывать длину поля данных, поэтому флаг конца поля данных не используется.
Первое поле состоит в действительности из трех полей (см. Рисунок 2). Два старших бита идентифицируют тип тэга (или, в иной терминологии, класса). Значения поля 00, 01, 10 и 11 соответствуют тэгам Universal, Application, Context-specific и Private. Следующий бит определяет принадлежность переменной к базовому или производному типу данных — 0 для базового, 1 — для производного.
Оставшиеся 5 бит могут использоваться для кодирования значения тэга (кода), не превышающего 30. Если значение тэга равно 31 или больше, то пять младших бит содержат одни единицы (11111), а реальное значение дается в следующем байте или байтах.
Рисунок 2. Первый байт всякого передаваемого элемента данных в соответствии с синтаксисом ASN.1.
Используемые правила для кодирования значений, больших 30, позволяют справляться с произвольно большими числами. Каждый последующий байт содержит 7 бит данных, а старший бит задается равным 0 во всех байтах, за исключением последнего. Таким образом, значения тэга до 27-1 могут быть переданы с помощью двух байт.
| Тип переменной | Описание | Код |
| INTEGER | Целое число произвольной длины | 2 |
| BIT STRING | Строка из 0 или более бит | 3 |
| OCTET STRING | Строка из 0 или более байт | 4 |
| NULL | Держатель места | 5 |
| OBJECT IDENTIFIER | Официально определенный тип данных | 6 |
Таблица 1 — Базовые типы переменных, допустимые в SNMP
Значение третьего поля зависит от значения первого поля. Например, базовые и простые составные типы данных принадлежат к классу Universal. Каждый базовый тип имеет свой код, как указано в третьей колонке в Таблице 1, SEQUENCE и SEQUENCE OF имеют один и тот же код 16, а CHOICE не имеет своего кода, так как реальное значение всегда принадлежит к определенному типу. Именно присвоенный код указывается в третьем поле.
Поле длины данных указывает, сколько байт занимают данные. Если данные короче 128 байт, то их длина может быть выражена при помощи одного байта, при этом значение крайнего левого бита будет равно 0. Если данные оказываются длиннее, то первый байт содержит 1 в старшем бите и длину поля длины данных (до 127 байт) в младших 7 битах. Например, если длина данных равна 1000 байт, то первый байт поля длины данных будет содержать 130, т. е. он сообщает принимающей стороне о том, что за ним следует еще два байта поля длины данных. Последующие два байта содержат действительное значение длины данных — 1000, при этом старший байт идет первым.
Кодирование поля данных зависит от конкретного типа данных. Целые числа кодируются при помощи дополнительного кода. Положительное целое число менее 128 кодируется при помощи одного байта и т. д. Старший значащий байт передается первым.
Строки бит передаются, как есть. Единственная проблема в том, что поле длины данных указывает длину в байтах, а не в битах. Принятое решение состоит во вставке одного байта перед строкой битов с указанием, сколько бит последнего байта не используются. Например, строка «010011111» длиной 9 бит будет иметь вид 07, 4F, 80 (в шестнадцатеричном представлении).
Строка байт передается справа налево — сначала старшие, а потом младшие байты. Нулевое значение указывается посредством задания поля длины данных равным 0. Никакое числовое значение реально не передается.
OBJECT IDENTIFIER кодируется в виде последовательности целых чисел, из которых он состоит. Например, ветвь mib-2 имеет префикс . Однако, поскольку первое число всегда равно 0, 1 или 2, а второе — меньше 40 (как определено ISO), первые два числа, х и y, кодируются с помощью одного байта в виде 40x+y. Таким образом, для mib-2 первый байт равен 43. Числа более 127 кодируются с помощью нескольких байт, первый бит числа задается равным 1, а количество следующих байт — в оставшихся 7 битах.
Оба типа SEQUENCE передаются следующим образом: сначала тип или тэг, затем общая длина всех последующих полей и, наконец, сами поля по порядку. Кодирование значения переменной типа CHOICE производится в соответствии с реальным передаваемым типом данных.
СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ
Выше мы кратко рассмотрели только те части ASN.1, что используются в SNMP. В действительности документы по SNMP организованы иным образом. Так, в RFC 1442 вначале говорится, что структуры данных в SNMP будут описываться с помощью ASN.1, а затем на более чем 50 страницах перечисляются неиспользуемые части ASN.1 и вводятся новые определения.
В частности, RFC 1442 определяет четыре основных макроса и восемь новых типов данных, активно используемых в SNMP. Это своего рода надподмножество ASN.1 известно под именем структуры управляющей информации (Structure of Management Information, SMI). Оно и применяется на практике для определения структур данных SNMP.
На самом нижнем уровне переменные SNMP определяются как отдельные объекты. Взаимосвязанные объекты объединяются в группы, а группы собираются в модули. Например, объекты IP и объекты TCP имеют каждый свою группу.
Маршрутизатор может поддерживать группу IP, так как он должен предоставлять информацию, например, о потерянных пакетах, но не группу TCP, так как он функционирует на более низком уровне. Если какое-то устройство поддерживает определенную группу, то оно должно поддерживать и все объекты из этой группы. Однако поддержка производителем определенного модуля не налагает на него ответственности по поддержке всех групп этого модуля, так как не все они могут иметь отношение к конкретному устройству.
Модули MIB запускаются посредством вызова макроса MODULE-IDENTITY. Его параметры сообщают имя и адрес разработчика, данные о версии и другую информацию. За ним обычно следует вызов макроса OBJECT-TYPE, сообщающего реальные используемые переменные и их свойства.
Источник: www.osp.ru
Русские Блоги
Структура сертификата X.509 состоит в том, чтобы описать структуру данных с ASN1 (абстрактным синтаксическим обозначением) и кодирует использование синтаксиса ASN1.
Опишите грамматику ASN.1 следующим образом:
Certificate::=SEQUENCE
Где алгоритм подписи является CA tbsCertificate Алгоритм, используемый для подписей; Algorithm Identifier Грамматическое описание ASN.1 выглядит следующим образом:
AlgorithmIdentifier::=SEQUENCE
Содержание сертификата — это информация, которая должна быть подписана CA, а синтаксис ASN.1 выглядит следующим образом:
TBSCertificate::=SEQUENCE
среди них, issuerUniqueID с участием subjectUniqueID Может появиться только в версии 2 или 3; extensions Может появиться только в версии 3.
ASN1 использует блок данных для описания всей структуры данных, каждый из которых состоит из четырех частей:
1. Тип данных ID (один байт)
Простой тип больше не разложимый тип, такой как целочисленная, битовая строка, ветку октета, идентификатор объекта, дата (NUTCTIME) и т. Д.;
Структурный тип объединяется простым типом и структурным типом, таким как последовательность, последовательность, выберите тип (выбор), сбор и так далее.
- Значение блока передачи данных последовательности типа состоит из последовательных последовательных значений блока данных элементов;
- Выбор значения блока данных выбранного типа Выбирает значение блока данных в нескольких типах блоков данных элементов;
- Установленный тип блока данных построен одним или несколькими значениями типа блока данных элементов.
2. Длина блока данных (1-128 байт)
- Если длина меньше или равно 127, используйте байт;
- Если длина превышает 127, используются множество байтов. Первый байт до 1, а оставшиеся семь битов дают фактическую длину байта, начать хранение от второго байта;
- Если длина равна 128, определите патч длины блока данных, требующий идентификации конца блока данных, чтобы завершить блоку данных.
3. Значение блоков данных
Конкретные кодировки отличаются от типа блока данных.
4. Идентификация конца блока данных (необязательно)
Завершить поле маркера, два байта (0x0000), только тогда, когда значение длины неопределенно.
Структура данных кода
// Информация содержит продолжительность информации и указатель информации о информации, ISMALLC используется для отпускания контента до конца программы. struct info bool ismallc; int length; unsigned char* data; >; / / / Хранить аналитическую информацию vectorinfo>certInfo;
Объясните функцию обработки длины блока данных:
// Эта функция обрабатывает длину блока данных (1-128 байт) (Len — это длина, прочитанная из сертификата) int getLength(ifstream 128if (len 0x7F) return len; > // > 128 int lengthOflen = len ^ 0x80; unsigned char* bytes = new unsigned char[lengthOflen]; file.read((char*)bytes, lengthOflen); int length = 0; for(int i=0; ilengthOflen; i++) length = (length <8) + int(bytes[i]); > delete []bytes; return length; >
Результаты теста
Используйте команду Makecert для создания сертификата под Windows:
> makecert.exe -r -pe -$ individual -n «CN=liuyh73» -sky exchange -sr currentuser -ss my liuyh73.crt
[Примечание] При открытии исходного кода обратите внимание на использование формата кодирования GB2312, в противном случае он приведет к искажению.
Источник: russianblogs.com
AleXxX_lag
14.01.21
✎
20:01
Привет всем! Подскажите плиз как победить ошибку CBynaryData: ошибка кодирования/декодирования.
Конфа ЗИКГУ 3.1 1с отчетность. крипто про 4 и личный сертификат установлены.
Волшебник
14.01.21
✎
20:17
пишется Binary
Скорее всего, там другая ошибка
AleXxX_lag
14.01.21
✎
20:32
Волшебник,буква в букву написано. скриншот как приложить?
Когда писал стартовый пост забыл уточнить что ось убунту.
Сказочный
14.01.21
✎
21:32
Звони в 1С отчетность, они помогут
Anttonnio
10.02.21
✎
12:36
Задал такой вопрос Калуге Астрал и они ответили следующее:
Здравствуйте!
Попробуйте установить локаль ru_RU.CP1251, например, для Ubuntu вызовами:
sudo /usr/share/locales/install-language-pack ru_RU.CP1251
sudo locale-gen ru_RU.CP1251
И это помогло=)
Ошибка ЭДО
Добрый день всем. При создании электронного документа выдает такую ошибку.
1С:Предприятие 8.3 (8.3.12.1685)
Бухгалтерия предприятия, редакция 3.0 (3.0.67.43)
Режим : Серверный, PostgreSQL
Не удается создать электронный документ, выдает ошибку: «Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
Подробности см. в журнале регистрации.»
Сообщения из журнала регистрации:
Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
: Ошибка при вызове метода контекста (Установить)
ОбъектXDTO.Установить(ИмяСвойства, Значение);
по причине:
Несоответствие типов XDTO
по причине:
Ошибка проверки данных XDTO:
Значение: ‘20%’ не соответствует простому типу:
Значение не соответствует значениям фасета перечисления
Выполнение операции: Формирование ЭД.
: Выполнение операции: Заполнение XDTO.
Ошибка установки значения свойства «НалСт».
Создаем свой ЯЗЫК ПРОГРАММИРОВАНИЯ. Лексер, Парсер, Абстрактное синтаксическое дерево (AST)
ВызватьИсключение ЭлектронноеВзаимодействиеСлужебный.СоединитьОшибки(Ошибки);
Помогите пожалуйста, может кто сталкивался с данной проблемой
Источник: buh.ru
Windows 10, PowerShell: файл сертификата открытого ключа (X.509) изнутри
Раньше я не уделял внимания формату файла сертификата открытого ключа. Теперь я немного покопался в этом формате и нашел там для себя много нового и интересного. В этой статье я не ставлю себе цель описать формат файла сертификата во всей полноте (это слишком большая работа; кроме того, эта работа уже сделана в тексте соответствующего стандарта), но хочу отметить некоторые интересные моменты.
Стандарты
Формат сертификата открытого ключа описан в стандарте «X.509», который создан «Международным союзом электросвязи» (сокращенно «МСЭ», по-английски «ITU»). Точнее, над стандартом работали и работают в отделе (секторе) стандартизации электросвязи этой организации (по-английски «ITU-T», в прошлом веке он назывался «CCITT»).
Первая версия (редакция) этого стандарта появилась в 1988 году, а сейчас актуальна версия 9 от 2019 года. Над стандартом продолжают работать. Однако, насколько я понимаю, сейчас в интернете больше ориентируются на документ «RFC 5280» (над документами «RFC» работает «Инженерный совет Интернета», по-английски «IETF»), адаптирующий стандарт «X.509» к реалиям интернета. Вроде бы, именно из документа «RFC 5280» появился термин «PKIX» (инфраструктура открытых ключей [PKI] на базе стандарта «X.509»). Документ «RFC 5280» вышел в 2008 году, в нем идет речь о реализации версии 3 стандарта «X.509» (эта версия разрабатывалась в период 1997-2004 годов).
Файл для анализа и инструменты анализа
Я создал из диспетчера веб-сервера IIS самозаверенный сертификат открытого ключа для тестирования работы с локальным сайтом по протоколу HTTPS. Этот файл я и буду тут анализировать.
Ошибка построения пути сертификации
В качестве инструмента для анализа я в основном использую программу-оболочку «PowerShell» версии 7. Напомню, я работаю в операционной системе «Windows 10».
Иногда заглядываю в сохраненные консоли «certlm.msc» (хранилище сертификатов компьютера, для работы требуются права администратора компьютера) и «certmgr.msc» (хранилище сертификатов текущего пользователя, для работы достаточно прав текущего пользователя). Их легко можно вызвать прямо из командной строки из любого местоположения с помощью команд certlm и certmgr , так как эти файлы хранятся в системной папке %windir%System32 . Файлы сохраненных консолей с расширением «.msc» по умолчанию привязаны (их имена при запуске передаются в качестве входного параметра) к исполняемому файлу «mmc.exe» (компонента «Консоль управления Microsoft» операционной системы), который тоже хранится в системной папке %windir%System32 .
Просмотр хранилищ сертификатов и сертификатов в них из «PowerShell»
В файловых системах операционных систем «Windows» обычно бывает несколько «корней» (в отличие от Unix-подобных операционных систем; там в файловой системе один «корень»), которые обозначают латинскими буквами с двоеточием (например, «A:», «C:», «D:» и так далее) и называют «логическими дисками» (или «томами»), по-английски «logical drive» (или «volume»).
В принципе, слово «том» кажется теперь более правильным, потому что слова «диск» и «привод» тянутся со времен, когда запоминающие устройства (накопители) были в основном с магнитными дисками и с подвижными частями, которые приводились в движение «приводами». У нас сейчас многие переводят с английского языка слово «drive» как «диск», хотя «drive» — это «привод». Во многих случаях буквенные обозначения томов соответствуют реальным физическим устройствам-накопителям, поэтому их часто называют словом «drive».
В документации программы-оболочки «PowerShell» буквенные обозначения томов называют «file system drive» (том файловой системы).
По принципу томов файловой системы в языке «PowerShell» существуют так называемые «провайдеры» или «поставщики» (по-английски «provider»). У этих провайдеров тоже есть «приводы»: это короткие слова или даже части слов (или аббревиатуры), которые используются для предоставления (обеспечения, поставки) быстрого и простого доступа к данным или компонентам, доступ к которым другими способами затруднен. Например, для доступа к переменным среды можно использовать привод «Env:» провайдера переменных среды, для доступа к реестру Windows можно использовать приводы «HKLM:» и «HKCU:» провайдера реестра и так далее. См. статью «about_Providers» документации программы-оболочки «PowerShell».
Для доступа к хранилищам сертификатов и сертификатам в этих хранилищах можно использовать привод Cert: провайдера сертификатов. При этом с хранилищами сертификатов можно работать так же, как с обычными папками файловой системы (напомню, хранилища сертификатов не соответствуют какой-либо папке файловой системы, это просто что-то вроде фильтра, инструмента, который собирает сведения о цифровых сертификатах, физически хранящихся в разных местах на компьютере), а с сертификатами можно работать так же, как с обычными файлами в файловой системе. Удобно продолжать использовать псевдонимы cd (сменить папку) и dir (показать список файлов и папок в текущей папке) командлетов Set-Location и Get-ChildItem соответственно. См. статью «about_Certificate_Provider» документации «PowerShell».
Итак, в командной строке программы-оболочки «PowerShell» перейдем в том Cert: и выведем список хранилищ сертификатов. Вот как это выглядит у меня:
PS C:> cd Cert: PS Cert:> dir Location : CurrentUser StoreNames : Location : LocalMachine StoreNames :
Это те самые два главных хранилища сертификатов, которые описаны, к примеру, в статье «Working with Certificates» на сайте компании «Microsoft»: хранилище сертификатов текущего пользователя и хранилище сертификатов компьютера. Под названием каждого из этих хранилищ виден массив названий подхранилищ (каждый массив завершается многоточием, которое обозначает то, что все названия из массива не влезли в отведенную строку).
Теперь можно последовательно перейти к нужному хранилищу (подхранилищу) сертификатов, либо можно сразу перейти к нужному подхранилищу, набрав полный путь (если вы уже сразу знаете нужный путь целиком):
PS C:> cd Cert:LocalMachineMy PS Cert:LocalMachineMy> dir PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy Thumbprint Subject EnhancedKeyUsageList ———- ——- ——————— D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 CN=IlyaComp Проверка подлинности сервера
Как видно из кода выше, в подхранилище Cert:LocalMachineMy есть только один сертификат открытого ключа. Команда dir уже вывела таблицу с тремя свойствами этого сертификата в окно терминала.
Но следует понимать, что у сертификата гораздо больше свойств, чем три. Просто остальные свойства не поместились по ширине в окно терминала. Для вывода всех свойств сертификата есть более удобные способы, чем способ по умолчанию.
Просмотр всех свойств сертификата из «PowerShell»
К конкретному сертификату можно обратиться по его так называемому «отпечатку» (thumbprint). Как видно из кода выше, отпечаток представляет собой довольно длинное шестнадцатеричное число. Очевидно, что при использовании его лучше скопировать, а не набирать вручную.
Итак, для удобства сохраним нужный объект сертификата в переменную $c , чтобы не обращаться каждый раз к длиннющему отпечатку сертификата. Затем через оператор конвейера (pipeline) | передадим объект сертификата командлету Format-List , который выведет все свойства сертификата в окно терминала в виде списка (символ звездочки * обозначает вывод всех свойств сертификата, но этому командлету можно передать ограниченный список свойств, чтобы вывести только те, которые нужны в данный момент):
PS Cert:LocalMachineMy> $c = Get-Item D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PS Cert:LocalMachineMy> $c | Format-List *
PSPath : Microsoft.PowerShell.Security Certificate::LocalMachineMy D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PSParentPath : Microsoft.PowerShell.SecurityCertificate::LocalMachineMy PSChildName : D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 PSDrive : Cert PSProvider : Microsoft.PowerShell.SecurityCertificate PSIsContainer : False EnhancedKeyUsageList : DnsNameList : SendAsTrustedIssuer : False EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty PolicyId : Archived : False Extensions : FriendlyName : localhost HasPrivateKey : True PrivateKey : IssuerName : System.Security.Cryptography.X509Certificates.X500DistinguishedName NotAfter : 20.10.2023 3:00:00 NotBefore : 20.10.2022 17:56:04 PublicKey : System.Security.Cryptography.X509Certificates.PublicKey RawData : SerialNumber : 4931C370DB54C8B8426A88B0D254E17E SignatureAlgorithm : System.Security.Cryptography.Oid SubjectName : System.Security.Cryptography.X509Certificates.X500DistinguishedName Thumbprint : D4A1741E3ACC4C8A89E5F7AA7901D8FE1C95C013 Version : 3 Handle : 2125934225808 Issuer : CN=IlyaComp Subject : CN=IlyaComp
Как видно из кода выше, для некоторых свойств, которые попроще, в списке сразу выводятся значения этих свойств. Для свойств, в которых записана ссылка на объект, выводится только тип объекта. Чтобы просмотреть записанный в таком свойстве объект, нужно забираться поглубже. Значением некоторых свойств является массив байтов, в этом случае значения байтов в массиве выводятся через запятую. В некоторые свойства не записано никакого значения, поэтому их значение равно значению $null (в списке выше напротив названий таких свойств после двоеточия ничего не выведено).
В свойстве Version записано значение 3 . Насколько я понимаю, тут подразумевается версия 3 стандарта «X.509», о которой упоминалось в начале данной статьи.
В этот раз меня в первую очередь интересовали свойства, в которых может содержаться информация об именах и названиях: DnsNameList , Extensions , FriendlyName , IssuerName , SubjectName , Issuer и Subject .
При анализе значений свойств сертификата может понадобиться умение читать содержимое массивов байтов. Это не очень сложно, если знать, по каким стандартам эти байтовые массивы в значениях свойств сертификата организованы и где можно удобно просмотреть стандарты, почитать соответствующие справочники. Ниже я покажу, как можно это делать, на примере свойства IssuerName («имя издателя», то есть имя сущности, создавшей и заверившей данный сертификат открытого ключа).
Читаем байтовый массив
Как видно из списка свойств сертификата выше, свойство IssuerName содержит ссылку на объект класса System.Security. Cryptography. X509Certificates. X500DistinguishedName . Просмотрим список свойств со значениями для этого объекта:
PS Cert:LocalMachineMy> $c.IssuerName | Format-List * Name : CN=IlyaComp Oid : System.Security.Cryptography.Oid RawData :
Очевидно, что значение свойства Issuer сертификата в данном случае совпадает со значением поля Name свойства IssuerName сертификата. Но мне стало интересно, что содержится в поле RawData свойства IssuerName сертификата. Видно, что там содержится массив байтов. Но что они означают?
Сначала я предположил, что там записано то же самое, что в поле Name . И действительно, часть байтового массива содержит строку IlyaComp в кодировке UTF-8. Но там есть и что-то еще. С налета разобраться в этом не получилось, поэтому я приступил к подробному анализу. Получим в окно терминала полное содержимое разбираемого массива байтов:
PS Cert:LocalMachineMy> «» + $c.IssuerName.RawData 48 19 49 17 48 15 6 3 85 4 3 19 8 73 108 121 97 67 111 109 112
По умолчанию программа-оболочка «PowerShell» выводит массив «вертикально», то есть выделяя для каждого элемента массива отдельную строку. Это неудобно. Для вывода элементов массива «горизонтально» (в одной строке) я применяю в коде выше конкатенацию пустой строки и анализируемого массива.
Следует иметь в виду, что по умолчанию значения байтов выводятся в десятичной системе счисления. Это неудобно. Для анализа байтовых массивов принято пользоваться значениями в шестнадцатеричной системе счисления. Выведем значения байтов из байтового массива в виде чисел в шестнадцатеричной системе счисления. В языке PowerShell это сделать несложно:
PS Cert:LocalMachineMy> «» + ($c.IssuerName.RawData | ForEach-Object ToString x2) 30 13 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70
В вышеприведенном коде передаем элементы массива байтов через конвейер (pipeline) | командлету ForEach-Object , который применяет к каждому входящему элементу массива (байту) метод System.Byte.ToString . Этот метод преобразует значение байта (целое число) в строку в указанном формате. В данном случае в качестве указания формата в метод System.Byte.ToString передаем строку x2 .
В этой строке формата латинская буква х указывает на вывод числа в шестнадцатеричной системе счисления (регистр буквы х в данном случае имеет значение, от него зависит регистр букв, которыми будут обозначены шестнадцатеричные цифры a, b, c, d, e, f). Число 2 указывает на число цифр в выводимых шестнадцатеричных числах. Очевидно (если вы понимаете, как сочетаются двоичная и шестнадцатеричная системы счисления), что для обозначения значения каждого байта нужно шестнадцатеричное число из двух цифр. (Тут подробнее про настройку форматирования чисел в строке.)
Язык ASN.1, способ сериализации DER и дерево идентификаторов объектов OID
Как оказалось, заполнение байтовых массивов в значениях сертификата открытого ключа по стандарту «X.509» выполняется на языке описания абстрактного синтаксиса данных «ASN.1» (расшифровывается как «Abstract Syntax Notation One»). Я немного о нем почитал и он мне понравился. Тут речь об «абстрактном синтаксисе» потому, что этот язык описывает любые структуры данных, независимо от конкретного языка программирования. Этот язык был создан в 1984 году и до сих пор разрабатывается уже упоминавшейся выше организацией «ITU-T».
Кроме описания структур данных в этом языке описаны разные способы сериализации полученного описания данных. Под словом «сериализация» подразумевают перевод данных в последовательность байтов (или в «серию» байтов, откуда и произошел термин «сериализация»). Там описано более десятка разных способов. Для сертификатов открытого ключа по стандарту «X.509» применяется способ сериализации DER (Distinguished Encoding Rules). Тут подробнее: раздел «Encodings» англоязычной статьи википедии «ASN.1», про способ сериализации DER в англоязычной статье википедии про стандарт «X.690», статья «A Warm Welcome to ASN.1 and DER» на сайте «Let’s Encrypt».
Давайте посмотрим, как это работает на практике на примере байтового массива, который я получил выше.
При сериализации по методу «DER» согласно языка «ASN.1» применяется известный метод записи данных «TLV» (расшифровывается как «type-length-value» или «tag-length-value»). По-русски название этого метода можно озвучить как «тип-длина-значение». Согласно этого метода данные (в том числе вложенные) записываются в указанном порядке: сначала тип данных, потом — длина данных в байтах, и, наконец, значение (собственно, сами данные).
Будем последовательно применять это правило для расшифровки вышеуказанного массива байтов. Возьмем первые два байта:
30 13 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 30 — SEQUENCE (тип данных) 13 — размер данных: 19₁₀ байтов данные: 31 11 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70
Первый байт нашего массива со значением 30 в языке «ASN.1» означает тип данных «SEQUENCE» (набор данных разных типов; например, в языке Си эквивалентом этого типа данных является тип struct ). Кстати, для быстрого ознакомления с языком «ASN.1» рекомендую ознакомиться с большой обзорной статьей «A Warm Welcome to ASN.1 and DER» на сайте известного бесплатного центра сертификации «Let’s Encrypt». Эта статья очень удобна для начинающих, там есть разные таблицы соответствия, например, значений байтов и типов данных.
Как видно из кода выше, в нашем случае в байтовом массиве записана структура данных типа «SEQUENCE», имеющая размер в 13 (шестнадцатеричная система) байтов или 19 (десятичная система) байтов. Данными являются 19 байтов, идущие после байта, указывающего размер данных. Если посчитать, получается, что весь остаток массива, кроме первых двух байт, имеет размер в 19 байт, следовательно, кроме структуры данных «SEQUENCE» в наш массив больше ничего не записано.
Продолжим расшифровку. Возьмем следующие два байта.
SEQUENCE
Тип данных «SET» в языке «ASN.1», в принципе, похож на «SEQUENCE», только в данных типа «SEQUENCE» (последовательность) порядок вложенных элементов сохраняется (важен), а в данных типа «SET» (множество) порядок вложенных элементов не сохраняется (не имеет значения). Перейдем к следующим двум байтам (думаю, принцип действия метода «type-length-value» к этому моменту уже должен был проясниться).
SEQUENCE < SET < 30 0f 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 30 — SEQUENCE (тип данных) 0f — размер данных: 15₁₀ байтов данные: 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 >>
SEQUENCE < SET < SEQUENCE < 06 03 55 04 03 13 08 49 6c 79 61 43 6f 6d 70 06 — OBJECT IDENTIFIER (тип данных) 03 — размер данных: 3₁₀ байта данные: 55 04 03 13 — PrintableString (тип данных) 08 — размер данных: 8₁₀ байтов данные: 49 6c 79 61 43 6f 6d 70 >> >
На этом шаге расшифровки получилось, что в структуру данных типа «SEQUENCE» входит сразу два вложенных элемента данных: типа «OBJECT IDENTIFIER» и типа «PrintableString». Второй из них — это тип данных, эквивалентный обычной строке. В данном случае в 8 байтах 49 6c 79 61 43 6f 6d 70 закодировано имя IlyaComp в кодировке UTF-8.
Под типом данных «OBJECT IDENTIFIER» (сокращенно «OID») подразумевают стандартизированное уже несколько раз упоминавшейся организацией «ITU» и международной организацией по стандартизации «ISO/IEC» дерево идентификаторов объектов. В интернете есть ряд сайтов, предоставляющих возможность просмотреть это дерево объектов и найти нужный объект. Например: http://oidref.com.
Каждый идентификатор объекта представляет собой набор номеров пунктов (веток дерева, целых чисел) через точку. В нашем случае в трех байтах 55 04 03 закодирован идентификатор объекта из четырех чисел. Первые два числа X и Y идентификатора объекта кодируются по формуле 40₁₀ * X + Y в первый байт данных, представляющих идентификатор объекта. Раскодируем идентификатор объекта:
В идентификаторе объекта все пункты имеют определенное значение:
- 2 — ветка дерева, общая для организаций «ISO» и «ITU-T»;
- 2.5 — ветка дерева, представляющая службы каталогов;
- 2.5.4 — ветка дерева, представляющая типы атрибутов (свойств) объектов в службах каталогов;
- 2.5.4.3 — ветка дерева, представляющая тип «Common name» атрибута (сокращенно «CN»).
Результат расшифровки байтового массива:
SEQUENCE < SET < SEQUENCE < OBJECT IDENTIFIER: 2.5.4.3 (Common name) PrintableString: «IlyaComp» >> >
Это же коротко записано как CN=IlyaComp и в виде строки содержится в поле Name свойства IssuerName сертификата открытого ключа, а также в свойствах Issuer и Subject сертификата.
Источник: habr.com
Абстрактное описание синтаксиса
ASN.1 обеспечивает стандартный способ представления данных и кодирования их для передачи по сети. Основу модели SNMP составляет множество объектов, которые станции управления могут считывать и записывать при помощи агентов.
ASN.1 обеспечивает стандартный способ представления данных и кодирования их для передачи по сети.
Основу модели SNMP составляет множество объектов, которые станции управления могут считывать и записывать при помощи агентов. Чтобы устройства различных производителей могли сообщать и понимать управляющую информацию, объекты должны быть определены стандартным, не зависящим от производителя образом. Кроме того, они должны единообразно кодироваться при передаче по сети.
Иными словами, SNMP необходим стандартный язык описания объектов вместе с правилами кодирования. Этот язык — абстрактное описание синтаксиса (Abstract Syntax Notation One, ASN.1) — разработчики SNMP заимствовали из стандартов OSI. ASN.1 представляет собой высокоуровневый язык описания типов данных и определяет формат сообщений SNMP при передаче их между агентами и станциями управления. Как и большая часть OSI, он обширен, сложен и не очень эффективен.
Сам язык описания данных определен в стандарте Международной организации по стандартизации (International Standard Organization, ISO) за номером 8824 под названием «Спецификация абстрактного описания синтаксиса, один», а правила кодирования закреплены в стандарте 8825 под названием «Спецификация базовых правил кодирования для ASN.1». Абстрактный синтаксис ASN.1 позволяет определять базовые объекты и затем объединять их в более сложные. Декларации в ASN.1 с функциональной точки зрения схожи с декларациями из файлов-заголовков для программ на С.
АБСТРАКТНЫЙ СИНТАКСИС
SNMP вводит свои условные обозначения, несколько отличные от ASN.1. Базовые типы данных записывают строчными буквами (например, целочисленный тип данных — как INTEGER). Определяемые пользователем типы данных начинаются со строчной буквы, но при этом они должны содержать по крайней мере один символ, отличный от строчной буквы.
Идентификаторы переменных начинаются с прописной буквы, при этом они могут содержать прописные и строчные буквы, цифры и дефисы. Пробелы (знаки табуляции, переноса строки и т. п.) не учитываются. Комментарии начинаются с «- -» (двойного дефиса) и заканчиваются либо вместе с концом строки, либо той же последовательностью символов «- -«.
Допустимые в SNMP базовые типы данных ASN.1 приведены в Таблице 1. Переменная типа INTEGER может в теории принимать любое целочисленное значение, но область ее значений ограничивают другие правила SNMP. В качестве примера использования типов мы рассмотрим, как переменная counter типа INTEGER декларируется и (если необходимо) инициализируется значением, равным 0.
counter INTEGER ::= 0
Очень часто переменную требуется ограничить конкретными значениями или конкретным диапазоном. Это можно сделать посредством определения необходимого подтипа следующим образом:
Status ::= INTEGER < on(1), off(2), unknown(3) >
PacketSize ::= INTEGER (0..1023)
Переменные типа BIT STRING и OCTET STRING представляют собой строку из 0 и более бит или байт, соответственно. Для обоих типов пользователь может задать длину строки и начальное значение. Тип OBJECT IDENTIFIER позволяет идентифицировать объекты. Любой объект в любом официальном стандарте может быть идентифицирован уникальным образом.
Данная цель достигается за счет введения дерева стандартов, при этом каждый объект соответствующего стандарта получает свое место в дереве. Верхний уровень дерева составляют наиболее важные в мире (с точки зрения ISO) организации, а именно ISO и CCITT (теперь ITU), а также их объединение.
Нас интересует прежде всего четвертая ветвь ISO с идентификатором identified-organization(3) (признанные организации по стандартизации), далее dod(6) (Министерство обороны США), а затем internet(1). Ветвь internet содержит четыре ветви. Объекты базы управляющей информации находятся под ветвью mgmt (см. Рисунок 1).
Помимо текстового идентификатора (label) каждая ветвь имеет свой числовой идентификатор (number). Объект может записываться с использованием текстовых или числовых идентификаторов в любой их комбинации. Как видно из описанной структуры, все объекты базы управляющей информации имеют общий префикс
iso.identified-organization.
dod.internet.mgmt.mib-2
или
или
и т. п. Таким образом, любой объект может быть представлен с помощью идентификатора объекта.
Рисунок 1. Каждый объект может быть идентифицирован уникальным образом.
ASN.1 описывает несколько способов создания новых типов данных. Прежде всего, это использование простых составных типов данных (SNMP задействует только три из них). SEQUENCE — это упорядоченный список типов, подобный структуре в С, SEQUENCE OF — одномерный массив переменных одного типа, а CHOICE — объединение из заданного списка типов.
Другой способ состоит в назначении тэгов имеющимся типам данных. Тэги подразделяются на четыре класса или категории: универсальный (universal), общеприкладной (application-wide), контекстно-зависимый (context-specific) и частный (private). Каждый тэг состоит из метки и целочисленного идентификатора, например:
IpAddress ::= [APPLICATION 0] OCTET STRING (SIZE (4))
определяет общеприкладной тип данных в виде строки байт длиной в 4 октета.
ASN.1 описывает сложный механизм макросов, активно используемый в SNMP. Макрос может служить в качестве своего рода прототипа для создания множества новых типов и значений, каждого со своим собственным синтаксисом. Каждый макрос определяет несколько (возможно, необязательных) ключевых слов, используемых при вызове для идентификации параметров (иными словами, параметры макроса идентифицируются не по местоположению, а по ключевому слову).
БАЗОВЫЕ ПРАВИЛА КОДИРОВАНИЯ
Транспортный синтаксис ASN.1 определяет однозначный способ преобразования значений переменных допустимых типов в последовательность байт для передачи по сети. В ASN.1 он называется базовыми правилами кодирования (Basic Encoding Rules, BER). Правила являются рекурсивными, так что кодирование составных объектов представляет собой составление в цепочку закодированных последовательностей составляющих объектов.
Каждое передаваемое значение — как базового, так и производного типа — состоит из трех полей:
- идентификатор;
- длина поля данных (в байтах);
- поле данных.
В отличие от ASN.1, протокол SNMP требует всегда указывать длину поля данных, поэтому флаг конца поля данных не используется.
Первое поле состоит в действительности из трех полей (см. Рисунок 2). Два старших бита идентифицируют тип тэга (или, в иной терминологии, класса). Значения поля 00, 01, 10 и 11 соответствуют тэгам Universal, Application, Context-specific и Private. Следующий бит определяет принадлежность переменной к базовому или производному типу данных — 0 для базового, 1 — для производного.
Оставшиеся 5 бит могут использоваться для кодирования значения тэга (кода), не превышающего 30. Если значение тэга равно 31 или больше, то пять младших бит содержат одни единицы (11111), а реальное значение дается в следующем байте или байтах.
Рисунок 2. Первый байт всякого передаваемого элемента данных в соответствии с синтаксисом ASN.1.
Используемые правила для кодирования значений, больших 30, позволяют справляться с произвольно большими числами. Каждый последующий байт содержит 7 бит данных, а старший бит задается равным 0 во всех байтах, за исключением последнего. Таким образом, значения тэга до 27-1 могут быть переданы с помощью двух байт.
| Тип переменной | Описание | Код |
| INTEGER | Целое число произвольной длины | 2 |
| BIT STRING | Строка из 0 или более бит | 3 |
| OCTET STRING | Строка из 0 или более байт | 4 |
| NULL | Держатель места | 5 |
| OBJECT IDENTIFIER | Официально определенный тип данных | 6 |
Таблица 1 — Базовые типы переменных, допустимые в SNMP
Значение третьего поля зависит от значения первого поля. Например, базовые и простые составные типы данных принадлежат к классу Universal. Каждый базовый тип имеет свой код, как указано в третьей колонке в Таблице 1, SEQUENCE и SEQUENCE OF имеют один и тот же код 16, а CHOICE не имеет своего кода, так как реальное значение всегда принадлежит к определенному типу. Именно присвоенный код указывается в третьем поле.
Поле длины данных указывает, сколько байт занимают данные. Если данные короче 128 байт, то их длина может быть выражена при помощи одного байта, при этом значение крайнего левого бита будет равно 0. Если данные оказываются длиннее, то первый байт содержит 1 в старшем бите и длину поля длины данных (до 127 байт) в младших 7 битах. Например, если длина данных равна 1000 байт, то первый байт поля длины данных будет содержать 130, т. е. он сообщает принимающей стороне о том, что за ним следует еще два байта поля длины данных. Последующие два байта содержат действительное значение длины данных — 1000, при этом старший байт идет первым.
Кодирование поля данных зависит от конкретного типа данных. Целые числа кодируются при помощи дополнительного кода. Положительное целое число менее 128 кодируется при помощи одного байта и т. д. Старший значащий байт передается первым.
Строки бит передаются, как есть. Единственная проблема в том, что поле длины данных указывает длину в байтах, а не в битах. Принятое решение состоит во вставке одного байта перед строкой битов с указанием, сколько бит последнего байта не используются. Например, строка «010011111» длиной 9 бит будет иметь вид 07, 4F, 80 (в шестнадцатеричном представлении).
Строка байт передается справа налево — сначала старшие, а потом младшие байты. Нулевое значение указывается посредством задания поля длины данных равным 0. Никакое числовое значение реально не передается.
OBJECT IDENTIFIER кодируется в виде последовательности целых чисел, из которых он состоит. Например, ветвь mib-2 имеет префикс . Однако, поскольку первое число всегда равно 0, 1 или 2, а второе — меньше 40 (как определено ISO), первые два числа, х и y, кодируются с помощью одного байта в виде 40x+y. Таким образом, для mib-2 первый байт равен 43. Числа более 127 кодируются с помощью нескольких байт, первый бит числа задается равным 1, а количество следующих байт — в оставшихся 7 битах.
Оба типа SEQUENCE передаются следующим образом: сначала тип или тэг, затем общая длина всех последующих полей и, наконец, сами поля по порядку. Кодирование значения переменной типа CHOICE производится в соответствии с реальным передаваемым типом данных.
СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ
Выше мы кратко рассмотрели только те части ASN.1, что используются в SNMP. В действительности документы по SNMP организованы иным образом. Так, в RFC 1442 вначале говорится, что структуры данных в SNMP будут описываться с помощью ASN.1, а затем на более чем 50 страницах перечисляются неиспользуемые части ASN.1 и вводятся новые определения.
В частности, RFC 1442 определяет четыре основных макроса и восемь новых типов данных, активно используемых в SNMP. Это своего рода надподмножество ASN.1 известно под именем структуры управляющей информации (Structure of Management Information, SMI). Оно и применяется на практике для определения структур данных SNMP.
На самом нижнем уровне переменные SNMP определяются как отдельные объекты. Взаимосвязанные объекты объединяются в группы, а группы собираются в модули. Например, объекты IP и объекты TCP имеют каждый свою группу.
Маршрутизатор может поддерживать группу IP, так как он должен предоставлять информацию, например, о потерянных пакетах, но не группу TCP, так как он функционирует на более низком уровне. Если какое-то устройство поддерживает определенную группу, то оно должно поддерживать и все объекты из этой группы. Однако поддержка производителем определенного модуля не налагает на него ответственности по поддержке всех групп этого модуля, так как не все они могут иметь отношение к конкретному устройству.
Модули MIB запускаются посредством вызова макроса MODULE-IDENTITY. Его параметры сообщают имя и адрес разработчика, данные о версии и другую информацию. За ним обычно следует вызов макроса OBJECT-TYPE, сообщающего реальные используемые переменные и их свойства.
Источник: www.osp.ru
Русские Блоги
Структура сертификата X.509 состоит в том, чтобы описать структуру данных с ASN1 (абстрактным синтаксическим обозначением) и кодирует использование синтаксиса ASN1.
Опишите грамматику ASN.1 следующим образом:
Certificate::=SEQUENCE
Где алгоритм подписи является CA tbsCertificate Алгоритм, используемый для подписей; Algorithm Identifier Грамматическое описание ASN.1 выглядит следующим образом:
AlgorithmIdentifier::=SEQUENCE
Содержание сертификата — это информация, которая должна быть подписана CA, а синтаксис ASN.1 выглядит следующим образом:
TBSCertificate::=SEQUENCE
среди них, issuerUniqueID с участием subjectUniqueID Может появиться только в версии 2 или 3; extensions Может появиться только в версии 3.
ASN1 использует блок данных для описания всей структуры данных, каждый из которых состоит из четырех частей:
1. Тип данных ID (один байт)
Простой тип больше не разложимый тип, такой как целочисленная, битовая строка, ветку октета, идентификатор объекта, дата (NUTCTIME) и т. Д.;
Структурный тип объединяется простым типом и структурным типом, таким как последовательность, последовательность, выберите тип (выбор), сбор и так далее.
- Значение блока передачи данных последовательности типа состоит из последовательных последовательных значений блока данных элементов;
- Выбор значения блока данных выбранного типа Выбирает значение блока данных в нескольких типах блоков данных элементов;
- Установленный тип блока данных построен одним или несколькими значениями типа блока данных элементов.
2. Длина блока данных (1-128 байт)
- Если длина меньше или равно 127, используйте байт;
- Если длина превышает 127, используются множество байтов. Первый байт до 1, а оставшиеся семь битов дают фактическую длину байта, начать хранение от второго байта;
- Если длина равна 128, определите патч длины блока данных, требующий идентификации конца блока данных, чтобы завершить блоку данных.
3. Значение блоков данных
Конкретные кодировки отличаются от типа блока данных.
4. Идентификация конца блока данных (необязательно)
Завершить поле маркера, два байта (0x0000), только тогда, когда значение длины неопределенно.
Структура данных кода
// Информация содержит продолжительность информации и указатель информации о информации, ISMALLC используется для отпускания контента до конца программы. struct info bool ismallc; int length; unsigned char* data; >; / / / Хранить аналитическую информацию vectorinfo>certInfo;
Объясните функцию обработки длины блока данных:
// Эта функция обрабатывает длину блока данных (1-128 байт) (Len — это длина, прочитанная из сертификата) int getLength(ifstream 128if (len 0x7F) return len; > // > 128 int lengthOflen = len ^ 0x80; unsigned char* bytes = new unsigned char[lengthOflen]; file.read((char*)bytes, lengthOflen); int length = 0; for(int i=0; ilengthOflen; i++) length = (length <8) + int(bytes[i]); > delete []bytes; return length; >
Результаты теста
Используйте команду Makecert для создания сертификата под Windows:
> makecert.exe -r -pe -$ individual -n «CN=liuyh73» -sky exchange -sr currentuser -ss my liuyh73.crt
[Примечание] При открытии исходного кода обратите внимание на использование формата кодирования GB2312, в противном случае он приведет к искажению.
Источник: russianblogs.com