Как создать цепочку сертификатов для эцп

Обновлено: 07.07.2024

Инфраструктура открытых ключей (PKI) – достаточно популярная технология для обеспечения целостности и доказательства авторства в различных ИТ-системах. Порою о ее использовании человек, сидящий за компьютером, даже не подозревает, как и в случае проверки целостности программы при установке на компьютер.

Технология PKI не нова. Если считать от момента возникновения алгоритма Меркле по распределению ключа – то технологии уже 42 года, если считать от момента возникновения RSA – то 39 лет. Возраст в любом случае внушительный. За это время технология существенно эволюционировала и позволяет создать солидный список сервисов для других приложений и пользователей.

Сами сервисы регламентированы в ряде стандартов, в серии X.500 – это серия стандартов ITU-T (1993 г.) для службы распределенного каталога сети и серии RFC (Request for Comments) – документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и стандарты, широко используемые во Всемирной сети. Причем серия RFC первична. Основная масса RFC о PKI была выпущена компанией RSA, одной из отцов(мам)-основателей технологии PKI.

PKI и его стандарты

Отдельно следует упомянуть всякого рода национальные стандарты и нормативные требования, к примеру, в РФ это ФЗ-63, приказы ФСБ России № 795 и 796 и прочие производные от них. Следует учитывать, что многообразие стандартов RFC и описанных в них функций PKI породило несколько организационно-нормативных подходов к построению инфраструктуры PKI в отдельно взятой стране. Для иллюстрации приведу список сервисов PKI, которые описаны в стандарте X.842:

Key Management Services
1 Key Generation Service
2 Key Registration Service
3 Key Certification Service
4 Key Distribution Service
5 Key Installation Service
6 Key Storage Service
7 Key Derivation Service
8 Key Archiving Service
9 Key Revocation Service
10 Key Destruction Service
Certificate Management Services
1 Public Key Certificate Service
2 Privilege Attribute Service
3 On-line Authentication Service Based on Certificates
4 Revocation of Certificates Service
Electronic Notary Public Services
1 Evidence Generation Service
2 Evidence Storage Service
3 Arbitration Service
4 Notary Authority
5 Electronic Digital Archiving Service
Other Services
1 Directory Service
Identification and Authentication Service
1 On-line Authentication Service
2 Off-line Authentication Service
3 In-line Authentication Service
4 In-line Translation Service
Recovery Services
1 Key Recovery Services
2 Data Recovery Services
5 Personalisation Service
6 Access Control Service
7 Incident Reporting and Alert Management Service

Результатом этого многообразия стало безобразие в национальных стандартах отдельных стран. Как результат – набор проблем по совместимости между различными решениями в отдельных странах и, очень часто, невозможность построения цепочки доверия между двумя пользователями технологии PKI в разных странах.

Цепочка сертификации и цепочка доверия

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

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

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

Цепочка доверия между людьми строится при помощи построения цепочки сертификации. Делается это следующим образом: в роли третьей доверенной стороны выступает аккредитованный удостоверяющий центр. Это юридическое лицо, обладающее одним или несколькими наборами оборудования, которое реализует функции удостоверяющего центра. Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ). Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия. Что такое электронная подпись и как она работает – вопрос за рамками данной статьи, об этом можно почитать в других источниках.

Для того чтобы этот УЦ мог точно сказать, что под документом именно ваша подпись, вам надо прийти в центр регистрации этого УЦ и предоставить ваш открытый ключ, запрос на сертификат, паспорт и ряд других документов. В результате вы получите сертификат открытого ключа, подписанный на ключе данного УЦ. Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны. В электронном мире УЦ принято доверять, только если оба пользователя, которые пытаются общаться между собой, обслуживаются в этом УЦ. В случае если УЦ у каждого пользователя свой, встает проблема доверия между УЦ. Путей ее решения несколько, путь снизу подразумевает кросс-сертификацию между УЦ разных пользователей. Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.

И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ. Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван. В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США. Федеральный мостообразующий УЦ (бридж) США содержит несколько базовых служб функции которых следует разобрать в отдельной статье.

Сложности

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

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

Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ. В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев. Или же СОС подписывается ключом, который не имеет отношения к сертификату УЦ, что тоже сводит шанс построить цепочку доверия к нулю. Потихоньку возникает проблема с обработкой самих СОС, за время существования УЦ они уже стали достаточно большого размера, но дельта СОС не выпускает почти никто.

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

Сложность пятая, техническая. Иногда в программно-аппаратных комплексах УЦ все-таки находятся ошибки в логике и реализации, это также может влиять на построение цепочки доверия.

И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построится. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.

При использовании КриптоПро ЭЦП Browser plug-in могут возникать ошибки, приводящие к тому, что плагин не работает или работает некорректно, из-за чего электронная подпись не создаётся. Рассмотрим наиболее распространённые варианты ошибок и разберёмся, как их устранить.

При проверке отображается статус «Плагин загружен», но нет информации о криптопровайдере

Не удаётся построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)

При этой ошибке плагин не может сформировать запрос на создание ЭЦП. Она возникает, если по каким-то причинам нет возможности проверить статус сертификата. Например, если нет привязки к ключу или доступа к спискам отзыва. Также проблема может воспроизводиться, если не установлены корневые сертификаты.

Для устранения этой ошибки нужно привязать сертификат к закрытому ключу.

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

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

Для установки корневого сертификата необходимо:

Кликнуть правой кнопкой мыши по файлу.
В контекстном меню выбрать пункт Установить сертификат.
После запуска Мастера установки нажать Далее.
Выбрать вариант Поместить все сертификаты в выбранной хранилище и нажать Обзор.
Выбрать в списке хранилищ Доверенные корневые центры сертификации, нажать ОК, затем Далее.
Нажать Готово.

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

Если вы создаёте ЭЦП таких форматов, как CAdES-T или CAdES-X Long Type 1, ошибка может возникать из-за отсутствия доверия к сертификату оператора службы предоставления штампов времени. В этой ситуации нужно установить корневой сертификат УЦ в доверенные корневые центры.

ЭЦП создаётся с ошибкой при проверке цепочки сертификатов

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

Ошибка несоответствия версии плагина

Данная проблема может возникнуть, если ваш браузер не поддерживает установленную версию плагина. Попробуйте воспользоваться другим обозревателем.

Ошибки 0x8007064A и 0x8007065B

Ошибка возникает в связи с окончанием срока действия лицензий на КриптоПро CSP (КриптоПро TSP Client 2.0, Криптопро OCSP Client 2.0).

Чтобы создать электронную подпись с форматом CAdES-BES, необходима действующая лицензия на КриптоПро CSP. Создание ЭЦП с форматом CAdES-X Long Type 1 потребует наличия действующих лицензий:

КриптоПро CSP;
КриптоПро OCSP Client 2.0;
КриптоПро TSP Client 2.0.

После приобретения лицензии потребуется её активация.

Набор ключей не существует (0x80090016)

Возникает из-за того, что у браузера нет прав для выполнения операции. Для решения проблемы в настройках плагина добавьте сайт в Список доверенных узлов.

Отказано в доступе (0x80090010)

Возникает в связи с истечением срока действия закрытого ключа. Чтобы проверить срок действия, запустите Крипто-Про CSP, затем откройте вкладку Сервис. Далее необходимо выбрать пункт Протестировать и указать контейнер с закрытым ключом. Если в результатах тестирования вы увидите, что срок действия закрытого ключа истёк, необходимо получить новый ключ.

Ошибка: Invalid algorithm specified. (0x80090008)

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

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

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

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

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

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

Стоимость использования КриптоПро CSP

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

Технические требования для КриптоПро CSP

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

Процессор - Intel Core 2 Duo или другой схожий по производительности x86-совместимый процессор с количеством ядер 2 и более.
Объем оперативной памяти - не менее 1 Гб.
Свободное место на жестком диске - не менее 100 Мб.

Операционная система Windows - Windows Server 2003 (32-разрядная), Windows Vista (32/64-разрядная), Windows 7 (32/64-разрядная), Windows Server 2008 (32/64-разрядная), Windows Server 2008 R2 (64-разрядная), Windows 8 (32/64-разрядная), Windows Server 2012 (64-разрядная), Windows 8.1 (32/64-разрядная), Windows Server 2012 R2 (64-разрядная), Windows 10 (32/64-разрядная), Windows Server 2016 (64-разрядная).

При использовании более ранних версий Windows, чем Windows 8, на компьютере должен быть установлен накопительный пакет обновления часовых поясов KB2570791.

Для операционной системы должен быть установлен последний пакет обновлений.

Пошаговая инструкция установки ЭЦП в КриптоПро

Откройте программу КриптоПро CSP.
Во вкладке Сервис нажмите кнопку Просмотреть сертификат в контейнере.

А если закрытый ключ содержится в виде файлов?

Закрытый ключ может быть в виде шести файлов: header.key, masks.key, masks2.key, name.key, primary.key, primary2.key

И если эти файлы находятся в корневой папке (то есть, записаны непосредственно на жёсткий диск), то КриптоПро CSP их не «увидит». Соответственно, все действия нужно производить только после того, как каждый файл перенесён на флешку. Причём находиться он должен в папке первого уровня.

После выбора контейнера откроется окно Сертификаты в контейнере закрытого ключа. С помощью кнопки Установить начните установку сертификата.

Если автоматическая установка сертификата не удалась, может потребоваться ручная установка. О том, как её осуществить, читайте нашей пошаговой инструкции.

Как настроить рабочее место

После установки сертификата квалифицированной ЭЦП на персональном компьютере, потребуется настройка рабочего места. Необходимо проверить установку и работоспособность:

криптопровайдера;
физического носителя;
браузера;
Астрал плагина;
плагина Astral Toolbox;
ЭЦП на любом портале для программного продукта Астрал-ЭТ.

Проверка криптопровайдера

Чтобы проверить установку КриптоПро CSP на компьютере, необходимо зайти в «Панель управления» → «Установка и удаление программ», в других случаях «Программы и компоненты» → при одном нажатии правой кнопкой мыши на иконку программы, можно увидеть версию продукта.

Проверка ЭЦП

Необходимо убедиться, что срок действия подписи не истёк. Рассмотрим один из способов: Открываем криптопровайдер КриптоПро CSP → вкладка «Сервис» → «Просмотреть сертификаты в контейнере» → раздел «Обзор» → выбираем ЭЦП, которую хотим проверить и нажимаем «Ок» → после нажатия «Далее» появится окно с информацией о сертификате подписи. Если подпись используется с отчуждённого физического носителя, необходимо проверить устройство на внешние повреждения.

Настройка браузера

Для настройки работы браузера с ЭЦП, использующей КриптоПро, необходимо произвести установку плагина. Для каждого браузера потребуется определённое расширение. Разобраться поможет наша подробная инструкция.

Проверка плагинов

При возникновении проблем с Астрал Плагин требуется произвести его переустановку или произвести настройку межсетевого экрана или интернет-браузеров. Если используются «Астрал Онлайн» или «Астрал.ОФД», плагины Astral Toolbox уже могут быть установлены. Версии данных плагинов не совместимы с продуктом «Астрал Отчёт 5.0». Обязательно требуется установка плагина не ниже версии 2.19.2.

Удалённая настройка рабочего места

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

На этом всё! Всем, кто решил обезопасить себя и свой бизнес, используя электронную подпись взамен обычной, желаем успехов в установке!

Однако потом что-то пошло не так, кто-то оказался не готов, и использование ГОСТ Р 34.10-2001 продлили на 2019 год. Но вдруг все бросились переводить УЦ на ГОСТ Р 34.10-2012, а простых граждан переводить на новые сертификаты. У людей на руках стало по нескольку сертификатов. При проверки сертификатов или электронной подписи стали возникать вопросы, а где взять корневые сертификаты, чтобы установить в хранилища доверенных корневых сертификатов.

Это касается как хранилища сертификатов в Windows, так и хранилища сертификатов в браузерах Firefox и Google Chrome, GnuPG, LibreOffice, почтовых клиентах и даже OpenSSL. Конечно, надо было озаботиться этим при получении сертификата в УЦ и записать цепочку сертификатов на флешку. А с другой стороны у нас же цифровое общество и в любой момент должна быть возможность получить эту цепочку из сети. Как это сделать на страницах Хабра показал simpleadmin. Однако для рядового гражданина это все же сложновато (особенно, если иметь ввиду, что абсолютное их большинство сидит на Windows): нужно иметь «какой-то» openssl, утилиту fetch, которой и у меня не оказалось на компьютере, и далеко не каждый знает, что вместо нее можно использовать wget. А сколько действий нужно выполнить. Выход конечно есть, написать скрипт, но не просто скрипт поверх openssl и иже с ним, а упакованный в самодостаточный выполняемый модуль для различных платформ.

На чем писать никаких сомнений не было – на Tcl и Python. И начинаем с Tcl и вот почему:

* охренительной вики, где есть даже игрушки (там можно подсмотреть интересное :)
* шпаргалки
* нормальные сборки tclkit (1.5 — 2 Мб как плата за реальную кросс-платформенность)
* и моя любимая сборка eTcl от Evolane (бережно сохранённая с умершего сайта :(
сохраняют высокий рейтинг Tcl/Tk в моём личном списке инструментария
и, да, wiki.tcl.tk/16867 (мелкий web-сервер с cgi на Tcl, периодически используется с завидным постоянством под tclkit)
а ещё — это просто красиво и красиво :)

К этому бы я добавил наличии утилиты freewrap, которая нам и поможет собрать автономные (standalone) утилиты для Linux и MS Windows. В результате мы будем иметь утилиту chainfromcert:

В качестве параметров утилите задаются файл с пользовательским сертификатом (как в формате PEM, так и формате DER) и каталог, в котором будут сохранены сертификаты УЦ, входящие в цепочку:

А теперь рассмотрим как работает утилита.
Информация о центре сертификации, выдавшем сертификат пользователю, хранится в расширении с oid-ом 1.3.6.1.5.5.7.1.1. В этом расширении может хранится как о местонахождении сертификата УЦ (oid 1.3.6.1.5.5.7.48.2), так и информация о службе OCSP УЦ (oid 1.3.6.1.5.5.7.48.1):

А информация, например, о периоде использования ключа электронной подписи хранится в расширении с oid-ом 2.5.29.16.

Для разбора сертификата и доступа к расширениям сертификата воспользуемся пакетом pki:

Нам также потребуются пакет base64:

Пакет pki, а также подгружаемые им пакет asn, и пакет base64 и помогут нам преобразовывать сертификаты из PEM-кодировки в DER-кодировку, разобрать ASN-структуры и собственно получить доступ к информации о местонахождении сертификатов УЦ.

Работа утилиты начинается с проверки параметров и загрузки файла с сертификатом:

Здесь все понятно и отметим только одно – файл с сертификатом рассматривается как бинарный файл:

Это связано с тем, что сертификат может хранится как в формате DER (двоичный код), так и в формате PEM (base64 — кодировка).

После того как файл загружен вызывается процедура chainfromcert:

которая собственно и загружает корневые сертификаты:

К комментариям добавить нечего, но у нас осталась не рассмотренной процедура readca:

Для чтения сертификата мы используем следующую функцию:

200 Запрос успешно выполнен
206 Запрос успешно выполнен, но удалось скачать только часть файла
301 Файл перемещен в другое место
302 Файл временно перемещен в другое место
401 Требуется аутентификация на сервере
403 Доступ к этому ресурсу запрещен
404 Указанный ресурс не может быть найден
500 Внутренняя ошибка

Осталось не рассмотренной одна процедура, а именно cert_to_der:

Схема процедуры очень простая. Если это PEM-файл с сертификатом («-----BEGIN CERTIFICATE----- »), то выбирается тело этого файла и преобразуется в бинаоный код:

Если это не PEM-файл, то проверяется это «похожесть» на asn-кодировку (нулевой бит должен быть равен 0x30).

Вот собственно и все, осталось добавить завершающие строки:

Теперь все собираем в один файл с именем

Проверить работу этого файла можно с помощью интерпретарора tclsh:

В результате работы мы получили цепочку из двух сертификатов в каталоге /tmp.

Но мы хотели получить выполняемые модули для платформ Linux и Windowsи и чтобы пользователи не задумывались о каких-то интерпретаторах.

Для этой цели мы воспользуемся утилитой freewrapTCLSH. С помощью этой утилиты мы сделаем выполняемые модули нашей утилиты для платформ Linux и Windows как 32-х разрядных так и 64-х. Сборку утилит можно проводить для всех платформ на любой из платформ. Извините за тавтологию. Я буду собирать на linux_x86_64 (Mageia).

Для сборки потребуется:

1. Утилита freewrapTCLSH для платформы linux_x86_64;
2. Файл freewrapTCLSH с этой утилитой для каждой платформы:
— freewrapTCLSH_linux32
— freewrapTCLSH_linux64
— freewrapTCLSH_win32
— freewrapTCLSH_win64
3. Исходный файл нашей утилиты: chainfromcert.tcl

Итак, собираемый выполняемый файл chainfromcerty_linuxx86 для платформы Linux x86:

Сборка утилиты для платформы Windows 64-х битного выглядит так:

И т.д. Утилиты готовы к использованию. Все необходимое для их работы они вобрали в себя.
Аналогичным образом пишется код и на Python-е.

В ближайшие дни я думаю дополнить пакет fsb795 (а он написан на Python-е) функцией получения цепочки корневых сертификатов.

Читайте также: