Linux где лежит сертификат

Вики 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»:

Источник

Сертификаты

Содержание

Сертификаты

Одной из наиболее распространенных форм криптографии сегодня является криптография на открытых ключах. Криптография на открытых ключах использует открытый (public) и закрытый (secret) ключи. Система выполняет шифрование с использованием открытого ключа. Расшифрована такая информация может быть только с использованием закрытого ключа.

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

Типы сертификатов

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

Продолжая пример с HTTPS, сертификат, подписанный CA, предоставляет два важных свойства в отличие от самоподписанного сертификата:

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

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

Процесс получения сертификата из CA довольно прост. Короткий обзор его приведен ниже:

Создайте пару из открытого и закрытого ключей.

Создайте запрос на сертификат на основе открытого ключа. Запрос на сертификат содержит информацию о вашем сервере и управляющей им компании.

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

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

Установите это сертификат на ваш защищенный сервер и настройте соответствующие приложения на его использование.

Создание запроса на подпись сертификата (CSR)

Вне зависимости от того получаете ли вы сертификат от CA или создаете самоподписаный, первым шагом будет создание ключа.

Если сертификат будет использоваться системными сервисами такими, как Apache, Postfix, Dovecot и т.п., уместно создать ключ без пароля. Отсутствие пароля позволяет сервису стартовать с минимальным ручным вмешательством, обычно это предпочтительный вариант запуска сервиса.

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

Для генерации ключей CSR запроса, запустите следующую команду из терминала:

Теперь вы можете ввести вашу кодовую фразу. Для лучшей безопасности рекомендуется использовать не менее восьми символов. Минимальная длина при использовании -des3 — 4 символа. Фраза должна включать цифры и/или знаки препинания и не должно быть словом из словаря. Также не забывайте, что ваша фраза будет чувствительна к регистру.

Повторите ввод для проверки. В случае корректного ввода ключ сервера будет создан и записан в файл server.key.

Теперь создадим небезопасный ключ, без кодовой фразы и поменяем имена ключей:

Небезопасный ключ теперь называется server.key и вы можете использовать его для создания CSR без кодовой фразы.

Для создания CSR выполните следующую команду в терминале:

У вас будет запрошена кодовая фраза (при использовании ключа с паролем — прим. пер.). Если введена корректная фраза, у вас запросят название компании, имя сайта, email и пр. Как только вы введете все эти подробности, будет создан запрос CSR и сохранен в файл server.csr.

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

Создание самоподписанного сертификата

Для создания самоподписанного сертификата, запустите следующую команду в терминале:

Эта команда попросит вас ввести кодовую фразу. Как только вы введете корректную фразу, ваш сертификат будет создан и сохранен в файл server.crt.

Установка сертификата

Вы можете установить файлы ключа server.key и сертификата server.crt (или файл сертификата, выданный вашим CA), запуском следующих команд в терминале:

Теперь просто настройте любое приложение с возможностью использования криптографии на открытых ключах для использования этих файлов ключа и сертификата. Например, Apache может предоставить HTTPS, Dovecot предоставляет IMAPS и POP3S, и т.д.

Центр сертификации

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

1. Сначала создайте каталоги для хранения сертификата CA и необходимых файлов:

2. Центр сертификации требует несколько дополнительных файлов для своей работы; один для хранения последнего серийного номера, использованного CA, другой для записи какие сертификаты были выпущены:

3. Третий файл — это файл настроек CA. Хотя он не строго обязателен, но очень удобен для выпуска множества сертификатов. Отредактируйте /etc/ssl/openssl.cnf, изменив секцию [ CA_default ]:

4. Далее создайте самоподписанный сертификат:

Вам будут заданы вопросы по деталям сертификата.

5. Теперь установим корневой сертификат и ключ:

6. Теперь вы готовы приступить к выпуску сертификатов. Первое, что вам потребуется — запрос на сертификат (CSR). Смотрите детали в разделе Создание запроса на подпись сертификата (CSR). Получив CSR, введите следующую команду для создания сертификата, подписанного нашим центром:

После ввода пароля для ключа CA у вас запросят подтверждение на подпись сертификата и еще одно на сохранение нового сертификата. Затем вы сможете увидеть нечто с объемным выводом, относящееся к созданию сертификата.

7. Теперь у вас должен появиться новый файл /etc/ssl/newcerts/01.pem, с таким же содержанием, что и в предыдущем выводе. Выделите и скопируйте все, начиная со строки ——BEGIN CERTIFICATE—— и до строки ——END CERTIFICATE—— в файл с названием по сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt — вполне хорошее описательное имя.

Последующие сертификаты будут иметь имена 02.pem, 03.pem и т.д.

8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов — каталог /etc/ssl/certs. Это позволяет многим сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.

Для приложений, которые могут быть настроены на использование сертификата CA, вы можете скопировать файл /etc/ssl/certs/cacert.pem в каталог /etc/ssl/certs/ на каждом сервере.

Ссылки

Для более детальных инструкций по использованию криптографии смотрите SSL Certificates HOWTO на tlpd.org.

Страница Википедии HTTPS содержит больше относительно HTTPS.

Для дополнительной информации по OpenSSL смотрите домашнюю страницу OpenSSL.

Также хорошее глубокое руководство Network Security with OpenSSL от O’Reilly.

Источник

Где в Linux хранятся корневые сертификаты Центров Сертификации (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 сертификатов в системе:

Эти сертификаты используются утилитоми curl, wget и другими. Веб-браузеры Chromium и Firefox используют свои собственные хранилища корневых CA сертификатов.

Чтобы узнать, где веб браузеры хранять корневые CA сертификаты в Linux, нам нужно познакомиться с NSS.

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 и производные установка делается так:

Google Chrome / Chromium

Как уже было сказано, при работе на Linux, Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для выполнения верификации сертификатов.

Корневые CA сертификаты, которые добавил пользователь, хранятся в файле

/.pki/nssdb/cert9.db, их можно просмотреть командой:

Поскольку Chrome не может удалить сертификаты из хранилища NSS, то если вы отключите некоторые из них в настройках веб браузера (Privacy and security → Manage certificates → Authorities), то в том же файле, где хранятся добавленные пользователем корневые CA сертификаты, будут сохранены изменения о полномочиях отключённого сертификата:

Используемые в Google Chrome / Chromium корневые CA сертификаты в Linux можно посмотреть следующим причудливым способом:

1. Найдите расположение файла libnssckbi.so (как было сказано в предыдущем разделе, в нём NSS хранит доверенные корневые сертификаты):

Примеры расположений этого файла:

2. Теперь выполните команду вида:

2. Затем запустите команду:

Вы увидите доверенные корневые сертификаты, которые использует Google Chrome в Linux.

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации, на английском это Privacy and security → Manage certificates → Authorities.

Поскольку Firefox принадлежит Mozilla, то этот веб браузер, конечно, также использует Mozilla Network Security Services (NSS).

Стандартными расположениями папок с базами данных NSS являются:

/.pki/nssdb (на уровне пользователей)

/etc/pki/nssdb (на общесистемном уровне, может отсутствовать)

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

Посмотреть корневые сертификаты CA которые использует Firefox в Linux можно следующей командой:

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Чтобы просмотреть, каким CA доверяет Thunderbird:

Чтобы найти все файлы cert9.db выполните команду:

Источник