Зачем нам нужны сертификаты
Прежде чем приступать к работе с сертификатами, необходимо понять, зачем они нам нужны. Давайте рассмотрим пару человек. Традиционно их называют Алисой и Бобом. Им необходимо общаться между собой, и единственным способом, которым они могут это сделать, является обмен сообщениями через открытый канал передачи данных:
Все используемые иконки созданы Vitaly Gorbachev на сайте Flaticon
К сожалению, поскольку канал является открытым, любой при желании может прослушивать и даже изменять сообщения, которыми обмениваются Алиса и Боб:
Эта ситуация называется атакой “Человек посередине” (Man in the Middle).
Как Алисе и Бобу защититься от этой опасности? На помощь приходит шифрование. Наиболее древними и распространёнными системами шифрования являются системы с симметричным ключом. В этом случае Алиса и Боб должны оба обладать абсолютно одинаковым (поэтому он и называется симметричным) ключом, который неизвестен никому более.
Правда у хакера остаётся возможность повторить отправку одного или нескольких сообщений, переданных ранее. В ряде случаев это может так же представлять собой серьёзную опасность (представьте себе, что хакер может повторить запрос на перевод денег с одного счёта на другой).
Но вернёмся к нашим Алисе и Бобу. Кажется, что проблема решена. Но не тут-то было. Загвоздка в том, как обоим нашим участникам получить одинаковые ключи шифрования так, чтобы этот ключ не узнал никто другой. Ведь общаться они могут только по открытому каналу.
Что же делать? На помощь приходит асимметричное шифрование или шифрование с открытым ключом. Суть его состоит в следующем. Пусть Алиса хочет передать сообщение Бобу. Боб теперь генерирует не один, а два ключа – открытый и закрытый.
Открытый ключ не представляет секрета. Его Боб свободно раздаёт всем желающим общаться с ним. А вот закрытый ключ Боб хранит в тайне и не показывает никому, даже Алисе. Хитрость заключается в том, что если зашифровать сообщение с помощью открытого ключа, то расшифровать его можно только с помощью закрытого ключа. И наоборот, сообщение, зашифрованное закрытым ключом, расшифровывается открытым ключом.
Теперь ясно, как Алиса и Боб должны действовать. Каждый из них генерирует свои открытый и закрытый ключи. Затем они обмениваются открытыми ключами через их канал связи. Поскольку открытые ключи не представляют собой секрета, их можно передавать через открытые каналы.
Закрытые ключи они хранят у себя в тайне. Пусть теперь Боб хочет послать сообщение Алисе. Он шифрует его открытым ключом Алисы и посылает сообщение по каналу. Расшифровать сообщение может только обладатель закрытого ключа, т. е. только Алиса. Хакер этого сделать не может.
На самом деле всё чуть сложнее. Дело в том, что шифрование с открытым ключом работает намного медленнее симметричного шифрования. Шифровать таким способом большие объёмы данных представляется неудобным. Поэтому, когда Боб хочет общаться с Алисой, он поступает следующим образом.
Он генерирует новый ключ для системы симметричного шифрования (его обычно называют сеансовым ключом). Потом он шифрует этот сеансовый ключ открытым ключом Алисы и посылает его ей. Теперь у Алисы и Боба есть ключ симметричного шифрования, который неизвестен больше никому. С этого момента они свободно могут пользоваться быстрыми алгоритмами симметричного шифрования.
Казалось бы, проблема решена. Но всё не так просто. Хакеру, контролирующему канал связи, есть что нам сказать. Проблема снова кроется в механизме распространения ключей, но теперь уже открытых ключей. Давайте посмотрим, что может произойти.
Пусть Алиса сгенерировала пару из открытого и закрытого ключа. Теперь она хочет передать свой открытый ключ Бобу. Она посылает этот ключ по каналу передачи данных. В этот момент хакер перехватывает этот ключ, не давая ему достичь Боба. Вместо этого хакер генерирует свою пару из открытого и закрытого ключа.
Да, теперь у нас фигурирует масса различных ключей. Давайте разберёмся, как всё это работает. Пусть Боб хочет послать сообщение Алисе. Он шифрует его открытым ключом, который, как он думает, принадлежит Алисе. Но на самом деле ключ этот принадлежит хакеру.
Хакер перехватывает это сообщение, не давая ему достигнуть Алисы. Поскольку сообщение зашифровано открытым ключом хакера, то он может расшифровать его своим закрытым ключом, прочитать и изменить так, как сочтёт нужным. После этого он зашифровывает сообщение настоящим открытым ключом Алисы (помните, что он сохранил этот ключ у себя) и отправляет его ей.
Что же можно сделать, чтобы избежать подобного развития ситуации? И здесь мы подбираемся вплотную к сертификатам. Представьте себе, что Алиса распространяет по открытому каналу не просто свой открытый ключ, а ключ с прикреплённой к нему биркой, на которой написано, что этот ключ принадлежит Алисе. На бирке так же содержится подпись некоего уважаемого лица, которому доверяют как Алиса, так и Боб:
Считается, что ключ и бирка на нём составляют единое целое. Бирку нельзя отсоединить от одного ключа и присоединить к другому. Тогда, если хакер не может подделать подпись, то он не может подделать и ключ. Боб, получив ключ с биркой, на которой написано, что это ключ Алисы, и стоит подпись, которой он доверяет, может быть уверен, что это именно ключ Алисы, а не кого-то другого.
Можно считать, что ключ с такой биркой и представляют собой сертификат. Но как на самом деле он устроен в цифровом мире?
В цифровом мире всё, что угодно, можно представить в виде последовательности бит (нулей и единиц). Это относится и к нашим ключам. Что же нужно сделать, чтобы создать цифровую подпись для такой последовательности бит? Такая подпись должна обладать следующими свойствами:
Как же создать такую подпись? Можно поступить так. Сначала для нашей последовательности бит считается так называемый хеш. Вы передаёте вашу последовательность бит на вход некоторой функции (называемой функцией хеширования), и она возвращает вам другую последовательность бит, но уже очень короткую. Эта выходная последовательность и называется хешем. Все современные функции хеширования обладают следующими свойствами:
Для входной последовательности любой длины они всегда генерируют хеш одной и той же длины. Обычно эта длина не превышает нескольких десятков байт. Помните, что наша подпись должна быть короткой. Именно это свойство хеша и делает его удобным для использования в подписи.
Зная только хеш, вы не можете сказать, из какой последовательности бит он был получен. Т. е. восстановление этой последовательности из хеша невозможно.
Если у вас есть значение хеша некоторой последовательности бит, то вам очень трудно указать другую последовательность бит, дающую такой же хеш. Действительно, различных файлов длиной в 1 ГБайт очень много. Но для каждого из них можно посчитать хеш длиной, скажем, всего в 32 байта. Различных последовательностей бит длиной в 32 байта намного меньше, чем различных файлов длиной в 1 ГБайт. Это значит, что обязательно будут существовать два различных файла длиной в 1 ГБайт, дающие один и тот же хеш. И тем не менее, зная один такой файл и его хеш, очень сложно узнать другой файл, дающий такой же хеш.
С хешами разобрались. Но, к сожалению, сам по себе хеш не подходит на роль подписи. Да, он короткий, но его может посчитать любой. Хакер может сам вычислить хеш для своего открытого ключа, ничто не препятствует ему сделать это. Как же нам сделать хеш устойчивым к подделке? Здесь на помощь нам снова приходит шифрование с открытым ключом.
Помните, я говорил, что и Алиса, и Боб должны доверять подписи, которая стоит на бирке ключа. Пусть Алиса и Боб доверяют подписи Очень Важного Человека. Как же Очень Важный Человек может подписать ключ? Он генерирует свою пару из открытого и закрытого ключа.
Открытый ключ он передаёт Алисе и Бобу, а закрытый хранит у себя. Когда ему нужно подписать открытый ключ Алисы, он поступает так. Сначала он считает хеш ключа Алисы, а затем шифрует этот хеш своим закрытым ключом. Именно хеш, зашифрованный закрытым ключом Очень Важного Человека (его обычно называют certificate authority) и является подписью. Поскольку никто не знает закрытого ключа Очень Важного Человека, то никто и не может подделать его подпись.
С созданием подписи мы разобрались. Осталось понять, как проверить её подлинность, как проверить то, что подпись не была подделана. Итак, Боб получил некоторый ключ, на бирке которого написано, что это открытый ключ Алисы. А также там присутствует подпись вроде бы Очень Важного Человека.
Как это проверить? Во-первых, Боб вычисляет хеш полученного открытого ключа. Помните, что это может сделать любой. Затем Боб расшифровывает подпись с помощью открытого ключа Очень Важного Человека. Мы помним, что подпись представляет собой тот же зашифрованный хеш.
После этого Боб сравнивает два хеша: посчитанный им самостоятельно и тот, который он получил при расшифровке подписи. Если они совпадают, то всё в порядке, можно верить тому, что это ключ Алисы. Если же хеши отличаются, то доверять такому ключу нельзя. Поскольку хакер не может создать правильную подпись он не может и подсунуть Бобу другой ключ.
Итак, как я уже сказал, сертификат, в сущности, представляет собой ключ и подпись к нему. На практике в него добавляется масса иной информации:
Хеш и подпись строятся по всей совокупности этих данных, чтобы хакер не мог подделать ничего из них.
Однако в нашей строгой схеме всё ещё существует одна брешь. Надеюсь, вы уже поняли к чему я веду. А каким образом Алиса и Боб получают открытый ключ Очень Важного Человека? Ведь если хакер сможет подсунуть им вместо настоящего ключа свой ключ, то всё пропало.
Ну конечно же открытый ключ Очень Важного Человека распространяется так же с помощью сертификата, но теперь уже подписанного Очень-Очень Важным Человеком. Хм… А как же распространяется открытый ключ Очень-Очень Важного Человека? Ну конечно же тоже сертификатом. Ну вы поняли… там сертификаты до самого дна.
Но шутки в сторону. Действительно, сертификат Алисы может быть подписан сертификатом Очень Важного Человека, а тот – сертификатом Очень-Очень Важного Человека. Это называется цепочкой доверия. Но эта цепочка не бесконечна. Обычно она заканчивается корневым сертификатом.
Этот сертификат никем не подписан, а точнее, он подписан сам собой (self-signed certificate). Обычно корневые сертификаты принадлежат очень надёжным компаниям, которые, собственно, и занимаются тем, что подписывают другие сертификаты с помощью своих корневых сертификатов.
Раньше эти компании брали деньги за подписывание сертификатов. Теперь появились сервисы типа Let’s Encrypt, которые делают это бесплатно. Я думаю, что многие большие компании осознали, что лучше предоставлять сертификаты бесплатно и тем самым сделать Интернет более защищённым пространством, нежели иметь массу слабо защищённых сайтов, которые могут быть взломаны и использованы как площадки для атаки на эти же большие компании.
Но вернёмся к сертификатам. Осталось рассмотреть последний вопрос. Почему же мы доверяем корневым сертификатам? Что мешает хакеру подменить их? А всё дело в способе их доставки на компьютеры Боба и Алисы. Дело в том, что основные корневые сертификаты не распространяются по открытому каналу, а устанавливаются вместе с операционной системой. Недавно некоторые браузеры так же стали устанавливаться со своим набором доверенных сертификатов.
Вот и всё, что я сегодня хотел сказать о сертификатах. С ними связана ещё масса интересных вещей, например, механизмы устаревания и отзыва сертификатов, но мы не будем касаться этого здесь. Пора нам перейти к практическим вещам.
Как пользоваться openssl (команды openssl)
Команды OpenSSL не столько сложные, сколько запутанные.
Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.
Синтаксис использования команд OpenSSL:
openssl КОМАНДА ОПЦИИ
Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.
Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:
man openssl-КОМАНДА # ИЛИ man КОМАНДА
Например:
man openssl-req man openssl-x509 man openssl-genpkey man openssl-enc man openssl-rsa # ИЛИ man req man x509 man genpkey man enc man rsa
При этом если по аналогии попытаться использовать в командной строке openssl-req или req, то такие команды будет не найдены (нужно использовать openssl req …).
Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.
На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.
Перечень команд OpenSSL, которые мы будем использовать:
- genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
- req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
- x509 — утилита для подписи сертификатов и для показа свойств сертификатов
- rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
- enc — различные действий с симметричными шифрами
- pkcs12 — создаёт и парсит файлы PKCS#12
- crl2pkcs7 — программа для конвертирования CRL в PKCS#7
- pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
- verify — программа для проверки цепей сертификатов
- s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
- ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
- rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
- rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
- smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME
Чтобы увидеть полный список команд выполните:
openssl list -commands
Пример вывода:
asn1parse ca ciphers cms crl crl2pkcs7 dgst dhparam dsa dsaparam ec ecparam enc engine errstr gendsa genpkey genrsa help list nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand rehash req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp storeutl ts verify version x509
Симметричное шифрование файлов в openssl
Данный вид шифрования выполняется командой enc. Кстати она также задействуется при создании ключей, если выбрано их шифрование — это шифрование выполняется с помощью enc.
Для шифрования используется команда следующего вида:
openssl enc -ШИФР -in ДЛЯ-ШИФРОВАНИЯ -out ЗАШИФРОВАНЫЕ-ДАННЫЕ
Для расшифровки похожая команда, но с опцией -d, также ЗАШИФРОВАНЫЕ-ДАННЫЕ теперь являются входными, а на выходе РАСШИФРОВАННЫЕ-ДАННЫЕ:
openssl enc -ШИФР -d -in ЗАШИФРОВАНЫЕ-ДАННЫЕ -out РАСШИФРОВАННЫЕ-ДАННЫЕ
В качестве ШИФРА рекомендуют aes-256-cbc, а полный список шифров вы можете посмотреть командой:
openssl enc -list
Ещё настоятельно рекомендуется использовать опцию -iter ЧИСЛО. Она использует указанное ЧИСЛО итераций для пароля при получении ключа шифрования. Высокие значения увеличивают время, необходимое для взлома пароля брут-форсом зашифрованного файла.
Эта опция включает использование алгоритма PBKDF2 для получения ключа. Указывать можно высокие значения — десятки и сотни тысяч. В разделе «Как создать базу данных KeePass» при создании базы данных используется такой же алгоритм (первая версия), там для 1 секундной задержки я выставлял значение в 25 миллионов инераций.
Пример шифрования файла art.txt шифром aes-256-cbc, зашифрованные данные будут помещены в файл с именем art.txt.enc, при получении ключа шифрования используется десять миллионов итераций (на моём железе выполнение команды заняло несколько секунд):
openssl enc -aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000
Введите, а затем подтвердите пароль для шифрования:
В результате будет создан зашифрованный файл art.txt.enc.
Для расшифровки файла art.txt.enc и сохранения данных в файл art-new.txt:
openssl enc -aes-256-cbc -d -in art.txt.enc -out art-new.txt -iter 10000000
Если файл успешно расшифрован, то не будет выведена никакая дополнительная информация.
В случае неудачной расшифровки будет показано примерно следующее:
bad decrypt 140381536523584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:583:
Возможные причины ошибки:
- неверный пароль
- неверный алгоритм для расшифровки
- неправильно указано количество итераций с опцией -iter
- неверно указан файл для расшифровки
Обратите внимание, что для расшифровки также нужно указать опцию -iter с тем же самым значением, которое было указано при шифровании. Конечно, можно не использовать опцию -iter при шифровании (а, следовательно, и при расшифровке), но в этом случае шифрование считается ненадёжным!
Не рекомендуется пропускать опцию. Если у вас слабое железо ИЛИ если файл будет расшифровываться на слабом железе, то вам необязательно использовать такие большие значения -iter — укажите хотя бы десятки или сотни тысяч (например, полмиллиона).
Предыдущие команды для шифрования и расшифровки могут запускаться чуть иначе:
openssl ШИФР
Например:
openssl aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000
То есть пропускается слово enc, и перед шифром убирается дефис. Обе команды равнозначны.
Зашифрованный файл представляет собой бинарные данные, которые не получится передать, например, в текстовом сообщении (в чате). Используя опцию -a (или её псевдоним -base64), можно закодировать зашифрованные данные в кодировку Base64:
openssl enc -aes-256-cbc -in art.txt -out art.txt.b64 -iter 10000000 -a
Содержимое полученного файла art.txt.b64 можно открыть любым текстовым редактором и переслать в мессенджере или в чате.
Для расшифровки также нужно указать опцию -a:
openssl enc -aes-256-cbc -d -in art.txt.b64 -out art-new.txt -iter 10000000 -a
Чтобы просто закодировать бинарный файл в кодировку base64:
openssl enc -base64 -in file.bin -out file.b64
Чтобы раскодировать этот файл:
openssl enc -base64 -d -in file.b64 -out file.bin
Чтобы зашифровать файл используя указанный ПАРОЛЬ в команде (не интерактивный режим):
openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt -pass pass:ПАРОЛЬ
Зашифровать файл, затем закодировать его с помощью base64 (например, его можно отправить по почте), используя AES-256 в режиме CTR и с получением производной ключа PBKDF2:
openssl enc -aes-256-ctr -pbkdf2 -a -in file.txt -out file.aes256
Декодировать файл из Base64 , затем расшифровывать его, используя пароль, указанный в файле:
openssl enc -aes-256-ctr -pbkdf2 -d -a -in file.aes256 -out file.txt -pass file:<ФАЙЛ-С-ПАРОЛЕМ>
Установка ssl сертификата на все компьютеры домена с помощью групповых политик | windows для системных администраторов
Рассмотрим процедуру централизованной установки сертификата на компьютеры домена и добавление его в список доверенных корневых сертификатов с помощью групповых политик. После распространения сертификата все клиентские устройства будут доверять сервисам, которые подписаны данным сертификатом. В нашем случае, мы распространим самоподписанный SSL сертификат Exchange (роль Active Directory Certificate Services в доменен не развернута) на компьютеры пользователей в Active Directory.
Если вы используете самоподписанный SSL сертификат для своего сервера Exchange, то на клиентах, при первом запуске Outlook будет появляться сообщение, что сертификат не доверенный и пользоваться им небезопасно.
Чтобы убрать это предупреждение, нужно на компьютере пользователя добавить сертификат Exchange в список доверенных сертификатов системы. Это можно сделать вручную (либо путем интеграции сертификата в корпоративный образ ОС), но гораздо более проще и эффективнее автоматически распространить сертификат с помощью возможностей групповых политик (GPO). При использовании такой схемы распространения сертификатов, все необходимые сертификат будет автоматически устанавливаться на все старые и новые компьютеры домена.
В первую очередь, нам нужно экспортировать самоподписанный сертификат с нашего Exchange сервера. Для этого на сервере откройте консоль mmc.exe и добавьте в нее оснастку Certificates (для локального компьютера).
Перейдите в раздел Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates.
В правом разделе найдите ваш сертификат Exchange и в контекстном меню выберите AllTasks ->Export.
В мастере экспорта выберите формат DER encoded binary X.509 (.CER) и укажите путь к файлу сертификата.
Итак, вы экспортировали SSL сертификат Exchange в CER файл. Нужно поместить сертификат в сетевой каталог, куда у всех пользователей должен быть доступ на чтение (вы можете ограничить доступ к каталогу с помощью NTFS разрешений, или дополнительно скрыть его с помощью ABE). К примеру, пусть путь к файлу сертификата будет таким: \msk-fs01GroupPolicy$Certificates. 
Перейдем к созданию политики распространения сертификата. Для этого, откройте консоль управления доменными политиками Group Policy Management (gpmc.msc). Чтобы создать новую политику, выберите OU на который она будет действовать (в нашем примере это OU с компьютерами, т.к. мы не хотим, чтобы сертификат устанавливался на сервера и технологические системы) и в контекстном меню выберите Create a GPO in this domain and Link it here…
Укажите имя политики (Install-Exchange-Cert) и перейдите в режим ее редактирования.
В редакторе GPO перейдите в раздел Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities (Конфигурация компьютера –> Конфигурация Windows –> Параметры безопасности –> Политики открытого ключа –> Доверенные корневые центры сертификации).
В левой части окна редактора GPO щелкните ПКМ и выберите пункт меню Import.
Укажите путь к импортируемому файлу сертификата, который мы разместили в сетевом каталоге.
В соответствующем шаге мастера (Place all certificates in the following store) обязательно укажите, что сертификат нужно разместить в разделе TrustedRootCertificationAuthorities (Доверенные корневые центры сертификации).
Политика распространения сертификатов создана. Возможно более точно нацелить ( таргетировать) политику на клиентов с помощью Security Filtering (см. ниже) или WMI фильтрации GPO.
Протестируйте политику, выполнив на клиенте обновление политик командой (gpupdate /force). Проверьте что ваш сертификат появился в списке доверенных сертификатов. Это можно сделать в оснастке управления сертификатами (раздел Trusted Root Certification Authorities -> Certificates) или в настройках Internet Explorer (Internet Options -> Content ->Certificates-> Trusted Root Certification Authorities или Свойства обозревателя -> Содержание -> Сертификаты -> Доверенные корневые центры сертификации).
Вы можете проверить, что в браузере при открытии вашего HTTPS сайта (в нашем примере это Exchange OWA) больше не появляется предупреждение о недоверенном SSL сертификате. Теперь при настройке Outlook на ваш почтовый сервер Exchange (в Outlook 2021 ручная настройки почтового сервера возможна только через реестр) в программе перестанет появляться окно с предупреждением о недоверенном сертификате.
Если вы хотите, чтобы политика распространения сертификата применялась только к компьютерам (пользователям) в определенной группе безопасности, выберите в консоли Group Policy Management вашу политику Install-Exchange-Cert. На вкладке Scope в секции Security Filtering удалите группу Authenticated Users и добавьте вашу группу безопасности (например, AllowAutoDeployExchCert). Если прилинковать эту политику на корень домена, ваш сертификат будет автоматически распространен на все компьютеры, добавленные в группу безопасности.
Одной политикой вы можете распространить сразу несколько клиентских SSL сертификатов. Подробную информацию о сертификатах, которые распространяются вашей политикой можно посмотреть в консоли GPMC на вкладке Settings. Как вы видите, отображаются поля сертификата Issued To, Issued By, Expiration Date и Intended Purposes.
Если на компьютерах нет доступа в интернет, таким образом вы можете распространить на все устройства домена доверенные корневые сертификаты. Но есть более простой и правильный способ обновления корневых и отозванных сертификатов в изолированных доменах.
Итак, вы настроили политику автоматического распространения сертификата на все компьютеры домена (на определенный организационной юнит или группу безопасности домена). Сертификат будет автоматически устанавливаться на все новые компьютеры, не требуя от служб техподдержки никаких ручных действий (в целях безопасности желательно периодически проверять списки доверенных сертификатов на клиентах на поддельные и отозванные).
Установка сертификатов используя криптопро в linux
Описание процесса установки приведено на примере дистрибутива семейства Debian (x64).
Названия файлов и директорий могут варьироваться от системы к системе.
При установке личных сертификатов не нужны права суперпользователя, и наоборот, при установке сертификатов УЦ
(корневых и промежуточных) могут потребоваться такие права.
Подключите USB носитель с ключевыми контейнерами и проверьте результат команды:
/opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -fqcn -verifyc
CSP (Type:80) v4.0.9009 KC1 Release Ver:4.0.9797 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 16188003
\.FLASHivanov\.FLASHpetrov\.FLASHsidorov\.FLASHvasiliev\.FLASHsmirnov
OK.
Total: SYS: 0,020 sec USR: 0,060 sec UTC: 0,180 sec
Можно сразу установить личные сертификатов из всех доступных контейнеров одной командой:
/opt/cprocsp/bin/amd64/csptestf -absorb -certs
Произойдет установка сертификатов, находящихся во всех доступных в момент запуска команды контейнерах
(съемных флэш-носителях, жесткого диска и т. д.) в хранилище uMy.
При необходимости скопируйте ключевой контейнер \.FLASH.sidorov на жесткий диск:
/opt/cprocsp/bin/amd64/csptest -keycopy -contsrc '\.FLASHsidorov' -contdest '\.HDIMAGEsidor'
CSP (Type:80) v4.0.9009 KC1 Release Ver:4.0.9797 OS:Linux CPU:AMD64 FastCode:READY:AVX.
CryptAcquireContext succeeded.HCRYPTPROV: 38556259
CryptAcquireContext succeeded.HCRYPTPROV: 38770755
Total: SYS: 0,000 sec USR: 0,100 sec UTC: 14,920 sec
[ErrorCode: 0x00000000]
Наличие [ErrorCode: 0x00000000] в завершении каждой команды КриптоПРО говорит о ее успешном выполнении.
Проверьте наличие нового контейнера \.HDIMAGEsidor:
/opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -fqcn -verifyc
CSP (Type:80) v4.0.9009 KC1 Release Ver:4.0.9797 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 34554467
\.FLASHivanov
\.FLASHpetrov
\.FLASHsidorov
\.FLASHvasiliev
\.FLASHsmirnov
\.HDIMAGEsidor
OK.
Total: SYS: 0,010 sec USR: 0,050 sec UTC: 0,130 sec
[ErrorCode: 0x00000000]
Установите личный сертификат:
/opt/cprocsp/bin/amd64/certmgr -inst -cont '\.HDIMAGEsidor'
Certmgr 1.0 (c) "CryptoPro", 2007-2021.
program for managing certificates, CRLs and stores
Install:
=============================================================================
1-------
Issuer : OGRN=1234567890123, INN=1234567890, STREET=Арбат, E=info@berkut.ru, C=RU, S=77 г.Москва, L=Москва, O=ООО 'Беркут', OU=Удостоверяющий центр, CN=UCESTP
Subject : SNILS=12345678901, OGRN=1234567890123, INN=0011234567890, E=sidorov@mail.ru, C=RU, S=10 Республика Карелия, L=Петрозаводск, O=ООО Ромашка, CN=Сидоров Николай Павлович, T=Администратор, G=Николай Павлович, SN=Сидоров
Serial : 0x12C40953000000000019
SHA1 Hash : 0xdd0ea8db46a372571c55315cd7e4d8e2de8fb9b6
SubjKeyID : 5fc37e578cce0abe739c4da227f68a2f9abcb128
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2001 (512 bits)
Not valid before : 09/08/2021 06:07:00 UTC
Not valid after : 09/11/2021 06:17:00 UTC
PrivateKey Link : No
CA cert URL : http://cert1.ucestp.ru/estp.crt
Extended Key Usage : 1.3.6.1.5.5.7.3.4
1.3.6.1.5.5.7.3.2
=============================================================================
[ErrorCode: 0x00000000]
Скачайте корневой сертификат по ссылке выше (из поля CA cert URL):
http://cert1.ucmy-sertif.ru/estp.crt
и перенесите его, например, в домашнюю папку:
cp ~/Загрузки/estp.crt ~/estp.crtУстановите корневой сертификат (возможно потребуются права суперпользователя):
/opt/cprocsp/bin/amd64/certmgr -inst -store uroot -file ~/estp.crt
Certmgr 1.0 (c) "CryptoPro", 2007-2021.
program for managing certificates, CRLs and stores
Install:
=============================================================================
1-------
Issuer : OGRN=1234567890123, INN=1234567890, STREET=Арбат, E=info@berkut.ru, C=RU, S=77 г.Москва, L=Москва, O=ООО 'Беркут', OU=Удостоверяющий центр, CN=UCESTP
Subject : OGRN=1234567890123, INN=1234567890, STREET=Арбат, E=info@berkut.ru, C=RU, S=77 г.Москва, L=Москва, O=ООО 'Беркут', OU=Удостоверяющий центр, CN=UCESTP
Serial : 0x50D7BC0E4A3EC9994454EB83013EE5F5
SHA1 Hash : 0xd2144a3e098b6f2decb224257f48e2b7c6d85209
SubjKeyID : 07b753cd561dee8e5e83407be4575ecc05bfec14
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2001 (512 bits)
Not valid before : 17/06/2021 13:15:21 UTC
Not valid after : 17/06/2021 13:25:01 UTC
PrivateKey Link : No
=============================================================================
[ErrorCode: 0x00000000]
Проверьте установку личного сертификата:
/opt/cprocsp/bin/amd64/certmgr -list -store uMy
Certmgr 1.0 (c) "CryptoPro", 2007-2021.
program for managing certificates, CRLs and stores
=============================================================================
1-------
Issuer : OGRN=1234567890123, INN=1234567890, STREET=Арбат, E=info@berkut.ru, C=RU, S=77 г.Москва, L=Москва, O=ООО 'Беркут', OU=Удостоверяющий центр, CN=UCESTP
Subject : SNILS=12345678901, OGRN=1234567890123, INN=0011234567890, E=sidorov@mail.ru, C=RU, S=10 Республика Карелия, L=Петрозаводск, O=ООО Ромашка, CN=Сидоров Николай Павлович, T=Администратор, G=Николай Павлович, SN=Сидоров
Serial : 0x12C40953000000000019
SHA1 Hash : 0xdd0ea8db46a372571c55315cd7e4d8e2de8fb9b6
SubjKeyID : 5fc37e578cce0abe739c4da227f68a2f9abcb128
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2001 (512 bits)
Not valid before : 09/08/2021 06:07:00 UTC
Not valid after : 09/11/2021 06:17:00 UTC
PrivateKey Link : Yes
Container : HDIMAGE\sidor.0002B01
Provider Name : Crypto-Pro GOST R 34.10-2021 KC1 CSP
Provider Info : ProvType: 80, KeySpec: 1, Flags: 0x0
CA cert URL : http://cert1.ucestp.ru/estp.crt
Extended Key Usage : 1.3.6.1.5.5.7.3.4
1.3.6.1.5.5.7.3.2
=============================================================================
[ErrorCode: 0x00000000]