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

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

Электронная подпись реализуется на основе асимметричной криптографии, или криптографии с открытым ключом. Асимметричные криптографические алгоритмы предполагают использование пары ключей: открытого и закрытого. Закрытый ключ служит для выработки электронной подписи, открытый – для ее проверки.

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

Для решения данной задачи существует такое понятие, как «Сертификат открытого ключа электронной подписи» (или просто «цифровой сертификат»). Для выдачи, проверки действительности, отзыва и управления сертификатами необходима инфраструктура открытых ключей (Public Key Infrastructure).

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

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

Встраивание электронной подписи в прикладные системы

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

• Но реализация криптоалгоритмов с учетом высокого быстродействия, отсутствия ошибок и гарантированного выполнения требований математических преобразований – непростая задача, которой занимаются квалифицированные разработчики.
• В случае, если электронная подпись используется в критичных приложениях (например, для выполнения юридически значимых действий), реализация криптоалгоритмов в обязательном порядке проходит процесс сертификации на соответствие требованиям безопасности.
• В «западном» мире широко используется сертификация решений на соответствие Common Criteria, в России процесс сертификации средств криптографической защиты проводит ФСБ России.
• Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).
• Именно из-за сложности реализации и регуляции данного вида продукции существует рынок решений по криптографической защите информации, на котором играют различные игроки.
• С целью совместимости различных реализаций, а также упрощения их встраивания в прикладное программное обеспечение, были разработаны несколько стандартов, относящиеся к различным аспектам работы с СКЗИ и непосредственно электронной подписью.

Интерфейсы для доступа к СКЗИ

На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.

PKCS#11

PKCS#11 (Public-Key Cryptography Standard #11) – платформонезависимый программный интерфейс для работы с аппаратно реализованными СКЗИ: смарт-карты, HSM’ы, криптографические токены. Иногда PKCS#11 используется для доступа к программно реализованным криптографическим библиотекам.

PKCS#11 представляет собой довольно обширный документ, опубликованный RSA Laboratories, который описывает набор функций, механизмов, алгоритмов и их параметров для работы с криптографическими устройствами или библиотеками. В данном документе четко прописаны правила, в соответствии с которым будет работать прикладное программное обеспечение при вызове криптографических функций.

Данный стандарт поддерживается практически во всех open source-проектах, использующих криптографию. Для примера, Mozilla Firefox позволяет хранить сертификаты и закрытые ключи для аутентификации через SSL/TLS на токенах, работая с ними по PKCS#11.

Если прикладное программное обеспечение «умеет» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая наружу будет выставлять интерфейсы, описанные в стандарте, а внутри реализовывать необходимую СКЗИ логику: работа непосредственно с криптографическим устройством или реализация необходимых криптоалгоритмов программно. В этом случае прикладное программное обеспечение должно «подцепить» необходимую библиотеку и выполнять необходимые действия в соответствии с рекомендациями стандарта. Это обеспечивает заменяемость различных устройств и их библиотек для прикладного программного обеспечения и прозрачное использование СКЗИ в различных системах.

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

Microsoft Crypto API 2.0

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

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов.

Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.

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

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation).

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

В силу того, что распространенность Windows XP все еще довольно велика, CNG в прикладных системах используется крайне мало.

Проприетарные интерфейсы

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

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

Форматы электронной подписи

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

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

Для решения этой задачи также предлагается ряд стандартов.

PKCS#7

1. PKCS#7 (Public-Key Cryptography Standard #7), или CMS (Cryptographic Message Syntax) – стандарт, публикуемый и поддерживаемый все той же RSA Laboratories, описываемый синтаксис криптографических сообщений.
2. PKCS#7 также публикуется в качестве RFC с номером 2315.

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

С этой целью в PKCS#7 размещается информация об исходном сообщении (опционально), алгоритмах хеширования и подписи, параметрах криптоалгоритмов, времени подписи, сертификат ключа электронной подписи, цепочка сертификации и т. д.

Большинство атрибутов PKCS#7 являются опциональными, но их обязательность может определяться прикладной системой.

Отдельно следует отметить, что PKCS#7 позволяет ставить несколько подписей под одним документом, сохраняя всю необходимую информацию в сообщении.
Формирование и проверка PKCS#7 реализованы в криптографических «надстройках» в Microsoft Crypto API, речь о которых шла выше. Но сам формат довольно хорошо специализирован и его поддержка может быть реализована нативно.

XML-DSig

W3C разработала и опубликовала рекомендации по составлению подписанных сообщений в формате XML.

Фактически XML-DSig решает те же вопросы, что и PKCS#7. Основное отличие в том, что в PKCS#7 данные хранятся в структурах, сформированных в соответствии с разметкой ASN.1 (фактически, бинарные данные), а в XML-DSig – в текстовом формате в соответствии с правилами документа «XML Signature Syntax and Processing».

Область применения XML-DSig – веб-приложения и веб-сервисы.

Сырая подпись

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

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

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

Это позволяет значительно упростить процедуры выработки и проверки подписи, так как отсутствуют шаги формирования и разбора сообщений в соответствии с каким-либо форматом.

Заключение

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

Виды электронной подписи 63-ФЗ «Об электронной подписи»

Обновлено 15.02.2021

• Электронная подпись требуется почти во всех информационных системах для осуществления сделок и подписания электронных документов, необходима при оплате покупок через интернет, при подаче документов на портале Госуслуг, для получения информации из Росреестра, при подписании контракта на торговых площадках, при исполнении государственных и муниципальных функций в информационных системах.
• Электронная подпись позволяет идентифицировать ее владельца, придать электронному документу юридическую значимость и защитить подписанный документ от изменений.
• В России существует 3 вида электронной подписи (ЭП, ЭЦП) и каждая имеет свои особенности, область применения и юридическую значимость.
• Итак, разберем подробнее — какие виды ЭП бывают и в каких случаях они используются.

Виды электронной подписи определенные Федеральным законом № 63 «Об электронной подписи»

Простая электронная подпись (ПЭП)

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

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

Например, она может быть в виде кода в СМС или на обороте пластиковой карты, в виде логина и пароля в онлайн-сервисе. Простая ЭП также может использоваться для заверения электронного документа.

В этом случае она будет содержаться в самом электронном документе.

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

Этот документ регламентирует обязанности, правила и условия использования такой подписи для обеих сторон.

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

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

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

Усиленная неквалифицированная электронная подпись (НЭП)

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

Обычно она используется физическими лицами для подачи документов в налоговые органы через личный кабинет. Организации используют такие подписи для осуществления внутреннего документооборота и работы с порталом Росреестра.

1. Неквалифицированная электронная подпись несет функцию идентификации ее владельца и подтверждает целостность и неизменность подписанного документа.
2. Для того, чтобы подписанный такой ЭП документ был приравнен к бумажному документу с собственноручной подписью, также требуется заключение юридического соглашения между ее владельцем и органом, осуществляющим выдачу НЭП.
3. Эта подпись имеет среднюю степень защиты и более сложный алгоритм работы.
4. Для создания усиленной неквалифицированной электронной подписи используется комплект ключей: открытый (сертифкат) и закрытый ключ.

Усиленная квалифицированная электронная подпись (КЭП)

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

Усиленная квалифицированная электронная подпись (КЭП) обладает дополнительными признаками защищённости и является самым регламентированным государством видом подписи.

Она идентифицирует владельца ЭП, гарантирует неизменность подписанного документа и заменяет собственноручную подпись и печать.

Электронные документы, подписанные КЭП, автоматически приобретают юридическую силу без дополнительных предварительных соглашений в соответствии с федеральным законом № 63 «Об электронной подписи».

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

Для создания усиленной квалифицированной электронной подписи используется комплект ключей: открытый (сертифкат) и закрытый ключ.

Электронная подпись физического и юридического лица

Усиленная квалифицированная подпись может быть выпущена для физического лица или юридического лица (организации).

Если владельцем сертификата (ЭП) является физическое лицо, то в сертификате указывается ФИО, ИНН и СНИЛС данного физического лица.

В сертификате, выпущенном на должностное лицо организации, дополнительно будут содержаться сведения о наименовании организации.

Такая КЭП чаще всего используется для работы с Казначейством в системе удаленного финансового документооборота, на портале закупок согласно Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» от 05.04.2013 N 44, в ГИИС Электронный бюджет, на официальном сайте для размещения информации о государственных (муниципальных) учреждениях, для размещения информации об осуществлении государственного (муниципального) финансового аудита в сфере бюджетных правоотношений» в ГИС ЕСГФК. С помощью такой подписи можно подтвердить аккаунт физического лица на Госуслугах без всякого личного визита.

Если владельцем сертификата (ЭП) является юридическое лицо, то в сертификате указывается ИНН, ОГРН и название юридического лица.

Также может быть (но не обязательно) указано ФИО руководителя, действующего без доверенности согласно сведениям из ЕГРЮЛ (примечание: после вступления в силу поправок в Федеральный закон № 63 “Об электронной подписи”). Такой тип КЭП обычно используется для работы с некоторыми полномочиями в ГИИС Электронный бюджет Минфина, в ГИС ГМП, СБИС. Такой тип подписи используется на Госуслугах для создания аккаунта организации.

Формат электронной подписи: отсоединенная и присоединенная

Отсоединенная электронная подпись имеет расширение SIG. Она не содержится в самом документе, а является отдельным файлом к нему. То есть доказательтвом подписания документа является сам файл SIG.

Для проверки подлинности документа нужно будет открывать оба файла. Файл ЭП можно открыть с помощью КриптоАРМ, Mozila Thunderbird, ViPNet CryptoFile. Основной же документ будет открываться как обычно.

Следует учесть, что в случае, если в документ вносятся изменения после его подписания, то файл самой ЭП SIG становится неактуальным.

Формат присоединенной ЭП содержится в самом документе. После подписания документ необходимо проверять на наличие подписи специальными программами, в которых происходило подписание — КриптоПРО PDF, КриптоАРМ, плагин КриптоПро Office Signature или программы ЭДО (например Landocs).

И в заключение представим краткую таблицу, где и какую подпись можно получить.

Простая электронная подписьУсиленная неквалифицированная электронная подписьУсиленная квалифицированная электронная подпись

— Получаем в том сервисе, где она требуется. — На зайте Госуслуг, в клинт-банке, Почта России и т.д. Требуется заключение договора об ЭДО	— Получаем в неаккредитованном Удостоверяющем центре. — Для ФНС – в личном кабинете налогоплательщика. Требуется заключение договора об ЭДО.	— Получаем только в аккредитованном Минкомсвязью Удостоверяющем центре — Для работы в СУФД и на сайте закупок как заказчик по 44-ФЗ только в УЦ Федерального казначейства (по месту обслуживания) — С 01.07.2020 будут изменения

Создание и проверка электронной подписи в формате PKCS#7 с использованием квалифицированного сертификата

При осуществлении электронного документооборота требуется создание электронной подписи документа для придания ему юридической значимости.

Стандарты на ЭП являются двухуровневыми.

Первый уровень представляет собой непосредственно ЭП документа (подпись с помощью закрытого ключа).

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

В Российской Федерации приняты: стандарт ЭП первого уровня — ГОСТ 34-10.2001, второго уровня — PKCS#7 с возможностью добавления временных меток.

Это обязывает владельца квалифицированного сертификата, например, при подаче заявления в государственный орган создать электронную подпись документа в формате PKCS#7 и подать её вместе с заявлением.

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

Ключ подписи и его сертификат могут распространяться в двух формах:

• Электронный ключ (например, Rutoken или eToken).

Файл-контейнер

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

Доступ к ключу подписи, содержащемуся в файле-контейнере осуществляется при помощи программного криптопровайдера с использованием пароля (доступ к ключу подписи, содержащемуся в электронном ключе осуществляется при помощи встроенного в ключ криптопровайдера с использованием пин-кода).

Внешние программы, например Microsoft Outlook, Microsoft Word/Excel или любая программа создания и проверки электроной подписи, при вызове функций подписания или проверки обращаются к части операционной системы, отвечающей за криптографию (Microsoft Crypto API), которая в зависимости от задействованных криптографических алгоритмов вызывает соответствующий криптопровайдер. В нашем случае используется отечественная криптография. Поскольку Microsoft Windows не имеет встроенной поддержки российских алгоритмов электронной подписи, следует установить криптопровайдер отечественной криптографии.
Если сертификат подписи был заранее установлен в систему (в Хранилище сертификатов), то криптопровайдер знает, в каком контейнере от какого сертификата лежит закрытый ключ, и требует от пользователя ввода пароля от этого контейнера. Если закрытый ключ расположен на электронном ключе, криптопровайдер запрашивает пин-код. При успешном вводе пароля контейнер открывается, осуществляются операции с использованием закрытого ключа, после чего контейнер закрывается.

Про использование криптопровайдера и Microsoft Outlook/Office рассказывается в статье Использование электронного ключа доступа к порталу госуслуг для осуществления электронной подписи.

Если требуется создать электронную подпись произвольного документа, например, XML-формы запроса «Единого реестра доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено» с сайта http://zapret-info.gov.ru, необходимо программное обеспечение с соответствующим функционалом (создание электронной подписи в формате PKCS#7).

При использовании программного криптопровайдера создание подписи с использованием квалифицированного сертификата, содержащегося в файле-контейнере и на электронном ключе ничем не отличается.

При использовании ключей подписи, содержащихся на электронных ключах, есть три варианта: использовать программный криптопровайдер (рассмотрено выше), использовать общедоступное программное обеспечение, реализующее стандартный интерфейс работы с электронными ключами PKCS#11, или создавать самописное ПО, использующее API разработчика электронного ключа. Последние два варианта используют встроенный в электронный ключ криптопровайдер.

Рассмотрим частный случай второго варианта.

OpenSUSE Linux + OpenSSL + OpenSC + Rutoken ECP

Здесь будет целесообразнее изложить материал в виде пошагового HOWTO.

1. OpenSUSE 12.2, доустанавливаем недостающее ПО

zypper install openssl engine_pkcs11 pcsc-ccid libpcsclite1 libtool opensc

Включаем автостарт демона смарт-карт:

chkconfig pcscd on

2. Обеспечиваем поддержку в OpenSSL электронного ключа Aktiv Rutoken ECP

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

wget http://www.rutoken.ru/download/software/forum/pkcs11-gost-linux-2-x86.zip

Внутри архива — 4 файла:

libp11.so.2
libpkcs11_gost.so
librtpkcs11ecp.so
openssl.cnf

Добавляем в исходный файл /etc/ssl/openssl.cnf секции:

[openssl_def]
engines = engine_section

[engine_section]
pkcs11 = pkcs11_section

[gost_section]
default_algorithms = ALL

[pkcs11_section]
engine_id = pkcs11_gost
dynamic_path = /usr/lib/pkcs11-gost/libpkcs11_gost.so
MODULE_PATH = /usr/lib/pkcs11-gost/librtpkcs11ecp.so
init = 0

, а в самое начало файла — строку «openssl_conf = openssl_def»

Раскладываем библиотеки из архива по соответствующим каталогам, файл libp11.so.2 кладём в каталог /usr/lib/

Проверяем работоспособность электронного ключа:

pkcs11-tool —module /usr/lib/pkcs11-gost/librtpkcs11ecp.so -Ol

Будет запрошен пин-код электронного ключа и выдан список объектов на ключе.

3. Считываем с электронного ключа сертификат подписи

Среди объектов, хранящихся на электронном ключе нас интересуют сертификат и закрытый ключ (поле ID уникально для каждой тройки объектов: открытый ключ, закрытый ключ, сертификат):

Certificate Object, type = X.509 cert
label: ViPNet Certificate
ID: e59e26a30000000020ffbbd2567ccd01

Private Key Object; GOSTR3410
PARAMS OID: 06072a850302022400
label: ViPNet PrivateKey
ID: e59e26a30000000020ffbbd2567ccd01
Usage: decrypt, sign

Извлекаем сертификат, который будет использоваться для подписи, в файл signer_cert.crt:

pkcs11-tool —module /usr/lib/pkcs11-gost/librtpkcs11ecp.so -l -r
-y cert -d e59e26a30000000020ffbbd2567ccd01 -o signer_cert.crt

В этой команде -d e59e26a30000000020ffbbd2567ccd01 — ID сертификата.

4. Создаём электронную подпись

Имеется некий файл document.txt, для которого мы хотим создать электронную подпись.

Присоединённую:

openssl smime -engine pkcs11_gost -sign -in document.txt
-out document.txt.attached.p7s -outform der -noverify -binary
-signer certpem.crt -inkey e59e26a30000000020ffbbd2567ccd01
-keyform engine -nodetach

Отсоединённую:

openssl smime -engine pkcs11_gost -sign -in document.txt
-out document.txt.detached.p7s -outform der -noverify -binary
-signer certpem.crt -inkey e59e26a30000000020ffbbd2567ccd01
-keyform engine

Поле -inkey e59e26a30000000020ffbbd2567ccd01 определяет ID закрытого ключа, использующегося при создании подписи.

На выходе получаем файлы: document.txt.detached.p7s, который содержит электронную подпись файла document.txt, и document.txt.attached.p7s, который содержит текст документа + его электронную подпись.

5. Проверяем электронные подписи

Присоединённую:

openssl smime -verify -in document.txt.attached.p7s -noverify -inform der

Отсоединённую:

openssl smime -verify -in document.txt.attached.p7s -noverify -inform der -content document.txt

Примечание

Во всех командах openssl используется параметр -noverify — не происходит автоматическая проверка сертификата подписи на валидность.

__________________________________

17 декабря 2012 г., Лабазников Н.В., Начальник отдела сетевых технологий и информационной безопасности ООО»УЦИ»

Все права на статью принадлежат ООО «УЦИ». Разрешается копирование статьи без уведомления правообладателя. При копировании необходимо указывать ссылку на источник.