Linux хранилище сертификатов другие пользователи

Работа с КриптоПро на linux сервере

Ссылки

Лицензия

Для установки другой лицензии (под root):

Корневые сертификаты

Просмотр корневых сертификатов

Добавление корневых сертификатов (под root) из файла cacer.p7b

Необходимо последовательно добавить все сертификаты

Сертификаты

Список установленных сертификатов

certmgr -list , например:

Добавление реального сертификата

Добавить только сертификат (только проверка ЭЦП):

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

Закрытый ключ состоит из шести key-файлов:

Способ с дискетой или флешкой

Скопировать в корень дискеты или флэшки сертификат и приватный ключ (из каталога 999996.000 , 999996 — название (alias) контейнера):

Выполнить команду по копированию ключа с флэшки на диск, ключ попадет в пользовательское хранилище My .

gate@example.com — то, что прописано в поле E сертификата (можно посмотреть командой keytool —printcert -file /path/to/cert/client.cer ):

С жесткого диска

Скопировать приватный ключ в хранилище (контейнер), где — имя пользователя linux:

Поставить «минимальные» права:

Узнать реальное название контейнера:

Ассоциировать сертификат с контейнером, сертификат попадет в пользовательское хранилище My :

Если следующая ошибка, нужно узнать реальное название контейнера (см. выше):

Установить сертификат УЦ из-под пользователя root командой:

Проверка успешности установки закрытого ключа

Добавление тестового сертификата

Ввести пароль на контейнер test123 .

Ввести пароль на контейнер. По-умолчанию: 12345678

Удаление сертификата

Проверка сертификата

Просмотр всех атрибутов сертификата

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

Получаем SHA 1 хеши:

В цикле извлекаем сертификаты:

Настройка openssl для поддержки ГОСТ:

В файл /etc/ssl/openssl.cnf

Экспорт сертификатов на другую машину

Закрытые ключи к сертификатам находятся тут: /var/opt/cprocsp/keys . Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.

Экспорт самих сертификатов (если их 14):

Переносим эти файлы на машину и смотрим, какие контейнеры есть:

И как обычно, связываем сертификат и закрытый ключ:

Если закрытый ключ и сертификат не подходят друг к другу, будет выведена ошибка:

Если все успешно:

Если нет закрытого ключа, то просто ставим сертификат:

Подписание документа ЭЦП

Пример создания ЭЦП (по SHA1 Hash):

[ReturnCode: x]	Описание	Возвращаемый код завершения в баше $?
0	успешно	0
0x8010006b	Введен неправильный PIN	107
0x2000012d	Сертификат не найден	45
0x20000065	Не удалось открыть файл	101

Проверка подписи ЭЦП

Для верифицирования сертификатов нужен сертификат удостоверяющего центра и актуальный список отзыва сертификатов, либо настроенный для этого revocation provider.

Корневой сертификат УЦ, список отзыва сертификата является одним из реквизитов самого сертификата.

Контрагенты когда открывают подписи в КриптоАРМ используют revocation provider, он делает проверки отзыва сертификата онлайн. Как реализована проверка в Шарепоинте не знаю. Знаю только что используется библиотека Крипто.Net

Проверка конкретной подписи из локального хранилища по его хешу:

Проверить, взяв сертификат из file1.sig , подпись файла file2.sig . Практически, надо использовать один и тот же файл:

[ReturnCode: x]	Текст	Описание	Возвращаемый код завершения в баше $?
0	Успешно	0
0x80091004	Invalid cryptographic message type	Неправильный формат файла	4
0x80091010	The streamed cryptographic message is not ready to return data	Пустой файл	16

Получение исходного файла

Получение исходного файла (сообщения):

Будет ругаться на сертификат (так как не будет проверки), но подпись удалит. Вариант с проверкой:

Источник

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Добавление в Linux корневых сертификатов X.509 локального корпоративного Центра сертификации

Некоторые службы и приложения в Linux могут использовать в своей работе сетевые соединения, защищаемые с помощью SSL/TLS. Иногда требуется, чтобы цифровой сертификат, используемый для защиты соединений и предоставляемый каким-то удалённым сервером из локальной сети, принимался локальной Linux-системой как доверенный. Для этого в Linux-систему может потребоваться добавить корневой сертификат Центра сертификации (ЦС), которым были выданы сертификаты, используемые для защиты соединений. Типичный пример, когда локальная Linux-система для механизмов аутентификации и авторизации подключается с помощью ldap-клиента (например OpenLDAP) к контроллеру домена Active Directory (AD) и контроллер домена предоставляет ldap-клиенту для защиты соединения сертификат, выданным локальным корпоративным ЦС.

Здесь мы рассмотрим простой пример того, как в Linux-систему добавить корневые сертификаты локального корпоративного ЦС.

О том, как «выуживать» корневые сертификаты ЦС, которыми подписаны сертификаты контроллеров домена AD, я приводил пример ранее. Если под руками есть доменная Windows-машина, то можно выгрузить корневой сертификат из оснастки управления сертификатами из раздела корневых сертификатов доверенных ЦС. Если корневой сертификат не один, а несколько (цепочка), то каждый корневой сертификат цепочки выгрузим в файл в кодировке Base-64, сразу присвоив им расширение PEM вместо CER

В результате такой выгрузки в нашем примере получится пара файлов AD-RootCA.pem (корневой сертификат ЦС верхнего уровня) и AD-SubCA.pem (корневой сертификат подчинённого ЦС). Скопируем полученные pem-файлы на наш Linux-сервер, например с помощью утилиты pscp, во временный каталог.

Перейдём на консоль Linux-сервера и переместим файлы коневых сертификатов из временного каталога в каталог, который мы создадим специально для хранения наших корневых сертификатов и подправим на эти сертификаты права (если требуется)

Теперь обработаем содержимое каталога с нашими сертификатами утилитой OpenSSL — c_rehash:

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

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

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

В качестве примера рассмотрим клиента OpenLDAP, для которого можно указать созданный нами каталог в конфигурационном файле ldap.conf ( /etc/ldap/ldap.conf ) в дополнительной опции TLS_CACERTDIR, таким образом, чтобы эта опция шла после имеющейся по умолчанию опции TLS_CACERT (подробнее об этих опциях можно найти в man ldap.conf ):

Примечание.
В Debian GNU/Linux параметр TLS_CACERTDIR может игнорироваться, о чём сказано в man ldap.conf .

Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR. This parameter is ignored with GnuTLS. On Debian openldap is linked against GnuTLS…

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

Собрать все нужные доверенные корневые сертификаты Центров сертификации в бандл можно простой склейкой содерживого PAM-файлов в колировке Base-64:

Соответственно, применительно к ранее упомянутому клиенту OpenLDAP в Debian GNU/Linux настройка конфигурации будет такой:

Автор первичной редакции:
Алексей Максимов
Время публикации: 25.03.2017 17:36

Обсуждение

Пытаюсь проделать такие же операции на CentOS, но нет такой команды «c_rehash»:

Источник

Как добавить центр сертификации (CA) в Ubuntu?

Моя работа решила выпустить свой собственный центр сертификации (CA) для безопасной обработки различных аспектов нашей работы без оплаты сертификатов.

• Криптографически подписывать письма
• Шифровать содержимое электронной почты
• Сделайте доступ к таким вещам, как клиентские сертификаты IRC компании .
• Отзывать ключи бывших сотрудников автоматически

Они прислали мне .pem файл, и я не уверен, как добавить его в мою установку Ubuntu. Были отправлены следующие инструкции: «Двойной щелчок по нему на Mac должен установить его».

Как мне продолжить? Нужно ли мне что — то делать с OpenSSL , чтобы создать .key , .csr или .crt файл?

Установка ЦС

Скопируйте свой сертификат в формате PEM (в том формате, —-BEGIN CERTIFICATE—- в котором он есть) /usr/local/share/ca-certificates и назовите его с .crt расширением файла.

Тогда беги sudo update-ca-certificates .

Предупреждения: эта установка влияет только на продукты, которые используют это хранилище сертификатов. Некоторые продукты могут использовать другие магазины сертификатов; Если вы используете эти продукты, вам необходимо добавить этот сертификат CA и в другие хранилища сертификатов. ( Firefox Инструкция , Chrome Инструкция , Java Инструкция )

Тестирование CA

Вы можете проверить, сработало ли это, посмотрев сертификат, который вы только что добавили /etc/ssl/certs/ca-certificates.crt (который представляет собой длинный список всех соединенных вместе доверенных ЦС).

Вы также можете использовать s_client OpenSSL, пытаясь подключиться к серверу, который, как вы знаете, использует сертификат, подписанный только что установленным ЦС.

Первое, что нужно искать, это цепочка сертификатов в верхней части выходных данных. Это должно показать CA как эмитента (рядом с i: ). Это говорит о том, что сервер представляет сертификат, подписанный устанавливаемым центром сертификации.

Во-вторых, ищите verify return code в конце, чтобы быть установленным 0 (ok) .

Исходя из вышеизложенного, я могу сделать вывод, что предпочтительный способ получить локальные файлы сертификатов в надежном хранилище — поместить их в /usr/local/share/ca-certificates и запустить update-ca-certificates . Вам не нужно трогать /etc/ssl/certs напрямую.

У меня была та же проблема, и мне пришлось скопировать .pem файл /usr/local/share/ca-certificates , переименовав его в .crt . .cer Файл может быть легко преобразован в .pem , с OpenSSL, например, если вы не имеете .pem .

После копирования файла вы должны выполнить sudo update-ca-certificates .

Другие ответы относительно update-ca-certificates правильны для приложений, которые читают из системного хранилища сертификатов. Для Chrome и Firefox и, возможно, некоторых других, сертификат должен быть помещен в nssdb, бэкэнд для библиотеки NSS Mozilla.

Например, чтобы доверять сертификату корневого ЦС для выдачи сертификатов сервера SSL, используйте

certutil -d sql: $ HOME / .pki / nssdb -A -t «C ,,» -n -i

Где произвольно, и ваш файл .pem или .crt.

Другие полезные ссылки:

Для новых сборок, основанных на Debian, вам может потребоваться выполнить:

ПРИМЕЧАНИЕ: sudo dpkg-переконфигурирует ca-Certificates внутренне, вызывает update-ca-Certificates

Вам, конечно, все еще нужно будет скопировать сертификат (файл .crt) в / usr / share / ca-сертификаты, прежде чем делать что-либо из этого 🙂

Опираясь на dwmw2 в ответ , вы можете сказать , приложения , которые используют NSS для его управления сертификатами использовать систему доверия магазин.

libnss3 по умолчанию поставляется с набором корневых сертификатов CA (только для чтения libnssckbi.so ), поэтому большую часть времени вам нужно вручную добавлять их в локальное хранилище доверенных сертификатов пользователя, расположенное в $HOME/.pki/nssdb . p11-kit предлагает замену, libnssckbi.so которая действует как адаптер для общесистемных корневых сертификатов, установленных в /etc/ssl/certs .

Редактировать:

Кажется, что существует больше версий libnssckbi.so , чем просто libnss3 . Ниже приведен скрипт для их поиска, резервного копирования и замены ссылками p11-kit :

Оригинальные инструкции:

Для этого установите p11-kit и libnss3 (если они еще не установлены):

Затем сделайте резервную копию существующего, libnssckbi.so предоставленного libnss3 :

Наконец, создайте символическую ссылку:

Чтобы убедиться, что это сработало, вы можете запустить ll /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so и показать ссылку:

Теперь, если вы добавите сертификат в хранилище CA, используя update-ca-certificates эти сертификаты, теперь они будут доступны для приложений, использующих NSS ( libnss3 ), таких как Chrome.

Источник