- Firefox
- Google chrome / chromium
- Mozilla network security services (nss)
- Rosa crypto tool
- Thunderbird
- Trusted esign
- Добавление реального сертификата
- Добавление реального сертификата с привязкой к закрытому ключу и возможностью подписывать документы
- Добавление сертификатов в базу данных nss
- Добавление тестового сертификата
- Как добавить корневой сертификат в доверенные в linux в веб браузеры
- Как добавить корневой сертификат в доверенные в linux на уровне системы
- Корневые сертификаты
- Лицензия
- Настройка «криптопро» csp
- Настройка работы с рутокен эцп 2.0
- Общесистемные корневые ca сертификаты
- Подписание документа эцп
- Подпись средствами «криптопро csp»
- Получаем тестовый сертификат
- Получение исходного файла
- Пример установки отдельно взятого сертификата из контейнера
- Проверка подписи эцп
- Проверка сертификата
- Проверка содержимого csr
- Просмотр всех атрибутов сертификата
- Просмотр содержимого ключей и сертификатов
- Резюме
- С жесткого диска
- Создание корневого приватного ключа
- Создание самоподписанного корневого сертификата
- Создание файла с запросом на подпись сертификата (csr)
- Список установленных сертификатов
- Способ с дискетой или флешкой
- Установка сертификатов используя криптопро в linux
- Экспорт сертификатов на другую машину
Firefox
Поскольку Firefox принадлежит Mozilla, то этот веб браузер, конечно, также использует Mozilla Network Security Services (NSS).
Стандартными расположениями папок с базами данных NSS являются:
- ~/.pki/nssdb (на уровне пользователей)
- /etc/pki/nssdb (на общесистемном уровне, может отсутствовать)
Firefox НЕ использует ни одно из этих стандартных расположений, база данных хранится в профиле пользователя, который имеет общий вид ~/.mozilla/firefox/СЛУЧАЙНЫЕ-БУКВЫ-ЦИФРЫ.default/cert9.db, например, ~/.mozilla/firefox/3k0r4loh.default/cert9.db.
Посмотреть корневые сертификаты CA которые использует Firefox в Linux можно следующей командой:
certutil -L -d ~/.mozilla/firefox/*.default/
У Firefox-esr это папка:
certutil -L -d ~/.mozilla/firefox/*.default-esr/
Также вы можете просмотреть корневые CA сертификаты в настройках браузера:
Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:
Google chrome / chromium
Как уже было сказано, при работе на Linux, Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для выполнения верификации сертификатов.
Корневые CA сертификаты, которые добавил пользователь, хранятся в файле ~/.pki/nssdb/cert9.db, их можно просмотреть командой:
certutil -L -d ~/.pki/nssdb
Поскольку Chrome не может удалить сертификаты из хранилища NSS, то если вы отключите некоторые из них в настройках веб браузера (Privacy and security → Manage certificates → Authorities), то в том же файле, где хранятся добавленные пользователем корневые CA сертификаты, будут сохранены изменения о полномочиях отключённого сертификата:
Используемые в Google Chrome / Chromium корневые CA сертификаты в Linux можно посмотреть следующим причудливым способом:
1. Найдите расположение файла libnssckbi.so (как было сказано в предыдущем разделе, в нём NSS хранит доверенные корневые сертификаты):
locate libnssckbi.so
Примеры расположений этого файла:
- /usr/lib/libnssckbi.so
- /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
2. Теперь выполните команду вида:
ln -s /ПУТЬ/ДО/libnssckbi.so ~/.pki/nssdb
Например:
ln -s /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so ~/.pki/nssdb
2. Затем запустите команду:
certutil -L -d sql:$HOME/.pki/nssdb/ -h 'Builtin Object Token'
Вы увидите доверенные корневые сертификаты, которые использует Google Chrome в Linux.
Также вы можете просмотреть корневые CA сертификаты в настройках браузера:
Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации, на английском это Privacy and security → Manage certificates → Authorities.
Mozilla network security services (nss)
Network Security Services (NSS) это набор библиотек, разработанных для поддержки кросс-платформенной разработки защищенных клиентских и серверных приложений. Приложения построенные с использование NSS могут использовать SSL v2 и v3, TLS, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, сертификаты X.509 v3 и другие стандарты обеспечения безопасности.
В отличие от OpenSSL, NSS использует файлы базы данных в качестве хранилища сертификатов.
NSS начинается с жёстко закодированного списка доверенных сертификатов CA внутри файла libnssckbi.so. Этот список можно просмотреть из любого приложения, использующего NSS, способного отображать (и манипулировать) хранилищем доверенных сертификатов, например, Chrome-совместимые или Firefox-совместимые браузеры.
Некоторые приложения, использующие библиотеку NSS, используют хранилище сертификатов, отличное от рекомендованного. Собственный Firefox от Mozilla является ярким примером этого.
В вашем дистрибутиве скорее всего уже установлен пакет NSS, в некоторых дистрибутивах он называется libnss3 (Debian и производные) в некоторых — nss (Arch Linux, Gentoo и производные).
Если вы хотите просматривать и изменять хранилища сертификатов NSS, то понадобиться утилита certutil. В Arch Linux эта утилита входит в пакет nss и, следовательно, предустановлена в Arch Linux. А в Debian и производные установка делается так:
sudo apt install libnss3-tools
Rosa crypto tool
Как следует из названия, это утилита для работы с электронной подписью и шифрованием для дистрибутива ROSA Linux. В данный момент утилита доступна в репозиториях Rosa Linux и Alt Linux.
Эта утилита разрабатывается одним человеком – Михаилом Вознесенским. У нее простой, но удобный интерфейс. На данный момент утилита находится в активной разработке – с ноября 2021 года мне удалось протестировать три версии. Последняя версия, доступная на момент написание статьи — 0.2.2.
Что внутри? Утилита написана на Python с использованием PyQt4 для графического интерфейса.
Установить ее можно, использовав «Управление программами» в Rosa Linux.
Вставляем токен и запускаем утилиту.
Видим, что токен определился успешно и был найден наш сертификат.
Интерфейс программы настолько прост, что описывать и показывать в статье все его функции не имеет смысла. Попробуем только подписать файл.
Выбираем файл и жмем “Подписать файл”. Получаем вот такое предупреждение.
Нажимаем «OK» и получаем информацию о том, что файл был подписан успешно.
Основное достоинство этой утилиты в том, что она совершенно бесплатная, в отличии нашего следующего продукта.
По сравнению с использованием «КриптоПро CSP» из консоли:
На порядок проще использовать− Отсутствуют различные параметры подписи
Исходный код программы доступен в публичном репозитории на ABF:abf.io/uxteam/rosa-crypto-tool-develСистема контроля версий, которую использует «НТЦ ИТ РОСА», интегрирована в сборочную среду и базируется на Git. Можно вполне использовать любой клиент git.
Надеюсь, разработчики других отечественных дистрибутивов Linux, таких как Astra Linux, GosLinux и другие добавят в свои дистрибутивы пакеты с rosa-crypto-tool.
Thunderbird
Чтобы просмотреть, каким CA доверяет Thunderbird:
certutil -L -d ~/.thunderbird/*.default/
Чтобы найти все файлы cert9.db выполните команду:
find ~/ -name "cert9.db"
Trusted esign
Второй продукт, про который мы поговорим, это Trusted eSign от компании «Цифровые технологии». Она известна на российском рынке ИБ как разработчик средства по работе с подписью и шифрованием для ОС Windows – «КриптоАРМ».
Главное, не путать этот продукт с Trusted.eSign – web-сервисом по работе с подписью этой же компании.
Добавление реального сертификата
Добавить только сертификат (только проверка ЭЦП):
Добавление реального сертификата с привязкой к закрытому ключу и возможностью подписывать документы
Закрытый ключ состоит из шести key-файлов:
Добавление сертификатов в базу данных nss
Некоторые приложения используют базу данных NSS, и у вас может быть необходимость добавить доверенные CA в неё.
Последующие изменения повлияют только на приложения, использующие базу данных NSS и учитывающие файл /etc/pki/nssdb.
1. Сначала создайте структуру каталогов для системных файлов базы данных NSS:
sudo mkdir -p /etc/pki/nssdb
Затем создайте новый набор файлов базы данных. Пароль нужен для того, чтобы базу данных могли редактировать только люди, которые его знают. Если все пользователи в системе (и с доступом к резервным копиям) заслуживают доверия, этот пароль можно оставить пустым.
sudo certutil -d sql:/etc/pki/nssdb -N
2. Убедитесь, что файлы базы данных доступны для чтения всем:
sudo chmod go r /etc/pki/nssdb/*
3. Теперь, когда доступны файлы базы данных NSS, добавьте сертификат в хранилище следующим образом:
sudo certutil -d sql:/etc/pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"
Например:
sudo certutil -d sql:/etc/pki/nssdb -A -i ./HackWareCA.crt -n "HackWare CA" -t "C,,"
Биты доверия, используемые в приведённом выше примере, помечают сертификат как надёжный для подписи сертификатов, используемых для связи SSL/TLS. Имя (указывается после опции -n), используемое в команде, можно выбрать любое, но убедитесь, что его легко отличить от других сертификатов в магазине.
Для проверки:
certutil -L -d /etc/pki/nssdb
Аналогичные инструкции можно использовать для включения сертификата только в базу данных NSS конкретного пользователя:
certutil -d sql:$HOME/.pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"
Удаление из файлов базы данных NSS
Чтобы удалить сертификат из любой базы данных NSS, используйте команду certutil следующим образом. В этом примере используется общесистемное расположение базы данных NSS, но его можно легко изменить на пользовательское ~/.pki/nssdb местоположение.
sudo certutil -d sql:/etc/pki/nssdb -D -n "certificateName"
Добавление тестового сертификата
Ввести пароль на контейнер test123 .
Ввести пароль на контейнер. По-умолчанию: 12345678
Как добавить корневой сертификат в доверенные в linux в веб браузеры
Chrome, Chromium, Firefox и созданные на их основе веб браузеры доверяют корневым сертификатам, установленным на уровне системы. То есть вам достаточно добавить в доверенные CA сертификат как это показано в предыдущем разделе.
Причём эти браузеры хотя и используют NSS, они игнорируют общесистемные сертификаты NSS, которые можно добавить в файл /etc/pki/nssdb!
Тем не менее приложения, которые используют NSS (такие как Firefox, Thunderbird, Chromium, Chrome) хранят свои списки доверенных сертификатов в файлах cert9.db. Чтобы добавить свой сертификат в каждый из этих файлов можно использовать скрипт.
Сохранить следующий код в файл CAtoCert9.sh:
#!/bin/bash certfile="root.cert.pem" certname="My Root CA" for certDB in $(find ~/ -name "cert9.db") do certdir=$(dirname ${certDB}); certutil -A -n "${certname}" -t "TCu,Cu,Tu" -i ${certfile} -d sql:${certdir} done
В этом файле измените значение certfile на имя файла вашего сертификата и значение certname на имя вашего сертификата, сохраните и закройте файл.
Затем запустите его следующим образом:
bash ./CAtoCert9.sh
В результате в домашней папке пользователя будут найдены все файлы cert9.db и в каждый из них будет добавлен указанный CA сертификат.
Вы можете добавить CA сертификаты в графическом интерфейсе каждого браузера.
- В настройках Chrome: Конфиденциальность и безопасность → Безопасность → Настроить сертификаты → Центры сертификации
- В настройках Chromium: Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации
Нажмите кнопку «Импорт»:
Выберите файл с сертификатом.
Укажите, какие полномочия вы даёте этому сертификату:
- В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:
Нажмите кнопку «Импортировать»:
Выберите файл с сертификатом.
Укажите, какие полномочия вы даёте этому сертификату:
Как добавить корневой сертификат в доверенные в linux на уровне системы
Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:
Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.
Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:
sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt
Например:
sudo gcr-viewer ./HackWareCA.crt
Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.
Суть метода очень проста:
- Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
- Запустить программу для обновления общесистемного списка сертификатов.
Пути и команды в разных дистрибутивах Linux чуть различаются.
Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:
1. Проверьте, существует ли директория /usr/local/share/ca-certificates:
ls -l /usr/local/share/ca-certificates
Если её ещё нет, то создайте:
sudo mkdir /usr/local/share/ca-certificates
Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.
2. Скопируйте ваш сертификат командой вида:
sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/
Например:
sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/
3. Запустите следующую команду для обновления общесистемного списка:
sudo update-ca-certificates
Пример вывода:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:HackWareCA.pem done. done.
Проверим наличие нашего CA сертификата среди доверенных:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Сертификат успешно найден:
Чтобы его удалить:
sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt sudo update-ca-certificates
Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:
1. Выполните команду вида:
sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/
Например:
sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/
2. Обновите общесистемный список доверенных CA:
sudo update-ca-trust
Чтобы удалить этот сертификат:
sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt sudo update-ca-trust
Корневые сертификаты
Просмотр корневых сертификатов
Добавление корневых сертификатов (под root) из файла cacer.p7b
Необходимо последовательно добавить все сертификаты
Лицензия
Для установки другой лицензии (под root):
Настройка «криптопро» csp
Несмотря на то, что есть несколько неплохих статей по настройке «КриптоПро CSP» под Linux (например, тут или тут), я опишу здесь свой вариант. Основная причина в том, что большинство инструкций написаны для «Крипто Про CSP» версии 3.x. А современная версия «КриптоПро CSP» 4.
Приступаем к настройке.
Настройка работы с рутокен эцп 2.0
Сделаем небольшое отступление. Для работы с электронной подписью и шифрованием нам не обойтись без ключевых пар и сертификатов. Надежное хранение закрытых ключей – один из основных факторов безопасности. А более надежных средств хранения, чем токен или смарт-карта, человечество пока не придумало.
Для работы с токенами в ОС Linux есть масса различных средств и драйверов. Для описания всех этих средств понадобится отдельная статья. Поэтому я не буду подробно описывать, как это работает, и почему нам нужны именно эти пакеты.
Устанавливаем пакеты для работы с Рутокен ЭЦП 2.0:
apt-get install libpcsclite1 pcscd libccid
Нам также необходимо установить пакеты КриптоПро CSP для поддержки работы с токенами:
dpkg -i ./cprocsp-rdr-gui-gtk-64_4.0.0-4_amd64.deb ./cprocsp-rdr-rutoken-64_4.0.0-4_amd64.deb ./cprocsp-rdr-pcsc-64_4.0.0-4_amd64.deb ./lsb-cprocsp-pkcs11-64_4.0.0-4_amd64.deb
Общесистемные корневые ca сертификаты
Консолидированный файл, включающий в себя все корневые сертификаты CA операционной системы, находится в файле /etc/ssl/certs/ca-certificates.crt. Этот файл может быть символической ссылкой на фактическое расположение сертификатов в файлах /etc/ssl/cert.pem или /etc/ca-certificates/extracted/tls-ca-bundle.pem.
Корневые CA сертификаты в виде отдельных файлов расположены в директории /etc/ssl/certs, в этой директории могут быть ссылки на фактическое расположение сертификатов, например, в /etc/ca-certificates/extracted/cadir/.
Для просмотра Subject всех корневых CA сертификатов в системе:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
Эти сертификаты используются утилитоми curl, wget и другими. Веб-браузеры Chromium и Firefox используют свои собственные хранилища корневых CA сертификатов.
Чтобы узнать, где веб браузеры хранять корневые CA сертификаты в Linux, нам нужно познакомиться с NSS.
Подписание документа эцп
Пример создания ЭЦП (по SHA1 Hash):
[ReturnCode: x] | Описание | Возвращаемый код завершения в баше $? |
---|---|---|
успешно | ||
0x8010006b | Введен неправильный PIN | 107 |
0x2000012d | Сертификат не найден | 45 |
0x20000065 | Не удалось открыть файл | 101 |
Подпись средствами «криптопро csp»
В составе «КриптоПро CSP» есть утилита csptestf, позволяющая выполнять различные криптографические операции. Как я уже писал выше, у этой утилиты есть 2 недостатка:
- Отсутствие хорошей документации;
- Отсутствие графического интерфейса.
Подписать можно с помощью команды:
csptestf –sfsign –sign –in <имя файла> -out <имя файла> -my ‘Trusted eSign Test’ –detached –alg GOST94_256
Более подробную информацию о возможных параметрах вы можете получить, выполнив команду:
csptestf –sfsign
Такой интерфейс отлично подходит для подготовленного пользователя или для автоматизации операций в скриптах.
Поговорим теперь об утилитах, которые облегчают жизнь обычным пользователям при работе с подписью и шифрованием в Linux.
Получаем тестовый сертификат
Перед тем как перейти непосредственно к работе с подписью, надо сгенерировать ключевую пару и создать сертификат электронной подписи. Если у вас уже есть Рутокен с контейнером «КриптоПро», то эту часть можно смело пропустить.
Получение исходного файла
Получение исходного файла (сообщения):
Будет ругаться на сертификат (так как не будет проверки), но подпись удалит. Вариант с проверкой:
Пример установки отдельно взятого сертификата из контейнера
При необходимости скопируйте ключевой контейнер \.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]
Установите личный сертификат:
Проверка подписи эцп
Для верифицирования сертификатов нужен сертификат удостоверяющего центра и актуальный список отзыва сертификатов,
либо настроенный для этого revocation provider.
Корневой сертификат УЦ, список отзыва сертификата является одним из реквизитов самого сертификата.
Контрагенты когда открывают подписи в КриптоАРМ используют revocation provider, он делает проверки отзыва сертификата онлайн.
Как реализована проверка в Шарепоинте не знаю. Знаю только что используется библиотека Крипто.Net
cryptcp -verify-nochain
Проверка конкретной подписи из локального хранилища по его хешу:
cryptcp -verify-thumbprint 255c249150efe3e48f1abb3bc1928fc8f99980c4 -nochain test.txt.sig
Проверить, взяв сертификат из file1.sig
, подпись файла file2.sig
. Практически, надо использовать один и тот же файл:
cryptcp -verify-norev-f file1.sig file2.sig
Ответ:
Certificates found: 2 Certificate chains are checked. Folder './': file.xls.sig... Signature verifying... Signer: Старший инженер, Иванов Иван Иванович, Отдел закупок, ООО «Верес», Москва, RU, [email protected] Signature's verified. Signer: Генеральный директор, Сидоров Иван Петрович, Руководство, ООО «Кемоптика», Москва, RU, [email protected] Signature's verified. [ReturnCode: 0]
Результат:
Проверка сертификата
certmgr -list-f file.sig
Ответ:
1------- Issuer : [email protected], C=RU, L=Москва, O=ООО КРИПТО-ПРО, CN=УЦ KPИПTO-ПPO Subject : [email protected], C=RU, L=г. Москва, O="ООО ""Верес""", OU=Руководство, CN=Иванов Иван Иванович, T=Генеральный директор Serial : 0x75F5C86A000D00016A5F SHA1 Hash : 0x255c249150efe3e48f1abb3bc1928fc8f99980c4 Not valid before : 08/12/2021 09:04:00 UTC Not valid after : 08/12/2021 09:14:00 UTC PrivateKey Link : No
Проверка содержимого csr
После создания CSR используйте его, чтобы подписать собственный сертификат и/или отправить его в общедоступный центр сертификации и попросить его подписать сертификат. Оба подхода описаны в следующих разделах. Но прежде чем сделать это, неплохо бы ещё раз проверить правильность CSR. Это делается так:
Просмотр всех атрибутов сертификата
В cryptcp нет необходимых инструментов для получения всех атрибутов сертификата. Поэтому следует использовать openssl , но настроив его.
Получаем SHA 1 хеши:
В цикле извлекаем сертификаты:
Настройка openssl для поддержки ГОСТ:
В файл /etc/ssl/openssl.cnf
Просмотр содержимого ключей и сертификатов
Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.
В следующих командах используются тестовые файлы со следующими именами:
Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.
Все эти файлы являются текстовыми:
cat rootCA.key
Там мы увидим примерно следующее:
-----BEGIN PRIVATE KEY----- MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDJBKkr6XzzAcXD eyDQdvB0SWE2Fl3nqlX/c2RgqMgScXtgidEzOu9ms3Krju5UKLokkQJrZFPMtiIL MuPJFdYjVyfkfnqlZiouBVgJ60s8NQBBI8KnyyAoJCIFdASoW4Kv5C5LT8pX9eRa /huJaRJL5XsFUGnTOLvW2ZLN52iAux9CoZlmH6ZF4nuQpblwN0MHULAhze52VNFT ………………………………………………….. ………………………………………………….. ………………………………………………….. ………………………………………………….. ………………………………………………….. ………………………………………………….. -----END PRIVATE KEY-----
Резюме
Подведем итог. В конце 2021 – начале 2021 года наметился неплохой прогресс в средствах по работе с электронной подписью под Linux. Информационная безопасность начинает поворачиваться к пользователю лицом, и с каждым годом требуется все меньше действий для такого простого действия, как подписать или зашифровать файл с использованием отечественных алгоритмов.
Хочется дополнительно отметить такое развитие отечественных продуктов, учитывая современный тренд на замену Windows на Linux в государственных и муниципальных организациях. В рамках этого тренда становится актуальным использование средств криптографической защиты информации под Linux.
Такое развитие не может не радовать, особенно когда это происходит под Linux.
С жесткого диска
Скопировать приватный ключ в хранилище (контейнер), где — имя пользователя linux:
Поставить «минимальные» права:
Узнать реальное название контейнера:
Ассоциировать сертификат с контейнером, сертификат попадет в пользовательское хранилище My :
Если следующая ошибка, нужно узнать реальное название контейнера (см. выше):
Установить сертификат УЦ из-под пользователя root командой:
Создание корневого приватного ключа
Внимание: этот ключ используется для подписи запросов сертификатов, любой, кто получил этот ключ, может подписывать сертификаты от вашего имени, поэтому храните его в безопасном месте:
Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):
openssl genpkey -algorithm RSA -out rootCA.key
Опция -out указывает на имя файла для сохранения, без этой опции файл будет выведен в стандартный вывод (на экран). Имя выходного файла не должно совпадать с именем входного файла.
Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу “hello” (-pass pass:hello):
openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello
Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.
Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):
man enc
Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):
openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096
Создание самоподписанного корневого сертификата
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
Здесь мы использовали наш корневой ключ для создания корневого сертификата (файл rootCA.crt), который должен распространяться на всех компьютерах, которые нам доверяют. А приватный ключ (файл rootCA.key) должен быть секретным, поскольку он будет использоваться для подписи сертификатов серверов.
Создание сертификатов (делается для каждого домена) включает в себя несколько этапов. Эту процедуру необходимо выполнить для каждого домена/сервера, которым требуется доверенный сертификат от нашего ЦС.
Создание файла с запросом на подпись сертификата (csr)
Получив закрытый ключ, вы можете приступить к созданию запроса на подпись сертификата — Certificate Signing Request (CSR). Это официальный запрос к CA о подписании сертификата, который содержит открытый ключ объекта, запрашивающего сертификат, и некоторую информацию об объекте.
Создание CSR обычно представляет собой интерактивный процесс, в ходе которого вы будете предоставлять элементы отличительного имени сертификата (вводить информацию о стране, городе, организации, email и т.д.). Внимательно прочитайте инструкции, предоставленные инструментом openssl; если вы хотите, чтобы поле было пустым, вы должны ввести одну точку (.) в строке, а не просто нажать «Enter».
Если вы сделаете последнее, OpenSSL заполнит соответствующее поле CSR значением по умолчанию. (Такое поведение не имеет никакого смысла при использовании с конфигурацией OpenSSL по умолчанию, что и делают практически все. Это имеет смысл, когда вы осознаете, что можете изменить значения по умолчанию, либо изменив конфигурацию OpenSSL, либо предоставив свои собственные конфигурации в файлах).
В запросе на подпись сертификата вы указываете информацию для сертификата, который хотите сгенерировать. Этот запрос будет обработан владельцем корневого ключа (в данном случае вы его создали ранее) для генерации сертификата.
Важно: имейте в виду, что при создании запроса на подпись важно указать Common Name, предоставляющее IP-адрес или доменное имя для службы, в противном случае сертификат не может быть проверен.
Я опишу здесь два способа:
Список установленных сертификатов
certmgr -list
, например:
1------- Issuer : [email protected], C=RU, L=Moscow, O=CRYPTO-PRO LLC, CN=CRYPTO-PRO Test Center 2 Subject : CN=test2 Serial : 0x120007E4E683979B734018897B00000007E4E6 SHA1 Hash : 0x71b59d165ab5ea39e4cd73384f8e7d1e0c965e81 Not valid before : 07/09/2021 10:41:18 UTC Not valid after : 07/12/2021 10:51:18 UTC PrivateKey Link : Yes. Container : HDIMAGE\test2.000F9C9 2------- Issuer : [email protected], C=RU, L=Moscow, O=CRYPTO-PRO LLC, CN=CRYPTO-PRO Test Center 2 Subject : CN=webservertest Serial : 0x120007E47F1FD9AE0EDE78616600000007E47F SHA1 Hash : 0x255c249150efe3e48f1abb3bc1928fc8f99980c4 Not valid before : 07/09/2021 09:56:10 UTC Not valid after : 07/12/2021 10:06:10 UTC PrivateKey Link : Yes. Container : HDIMAGE\webserve.0012608
Способ с дискетой или флешкой
Скопировать в корень дискеты или флэшки сертификат и приватный ключ (из каталога 999996.000 , 999996 — название (alias) контейнера):
Выполнить команду по копированию ключа с флэшки на диск, ключ попадет в пользовательское хранилище My .
Установка сертификатов используя криптопро в linux
Сен042020
Описание процесса установки приведено на примере дистрибутива семейства 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.
Экспорт сертификатов на другую машину
Закрытые ключи к сертификатам находятся тут: /var/opt/cprocsp/keys . Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.
Экспорт самих сертификатов (если их 14):
Переносим эти файлы на машину и смотрим, какие контейнеры есть:
И как обычно, связываем сертификат и закрытый ключ:
Если закрытый ключ и сертификат не подходят друг к другу, будет выведена ошибка:
Если все успешно:
Если нет закрытого ключа, то просто ставим сертификат: