Список доверенных сертификатов linux

Обновление корневых сертификатов на Linux

От корневых сертификатов в системе может зависеть правильная работа при обращении к ресурсам, которые работают по зашифрованному каналу связи. Если данные сертификаты устареют, мы можем столкнуться с рядом проблем:

• Не открываются или выдают предупреждение безопасности некоторые (или все) сайты, работающие по https.
• Некорректная работа отдельных приложений.
• Ошибки при подключении по ssh.

Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания.

Установка из репозитория

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

а) для систем на базе DEB (Debian, Ubuntu, Mint):

apt install ca-certificates

б) для систем на базе RPM (Rocky Linux, CentOS):

yum install ca-certificates

Если нам повезет и в репозитории будут обновленные корневые центры, наша работа закончена. Иначе, устанавливаем сертификаты вручную.

Загрузка пакета с сертификатами

Установка из репозитория может не дать нужного эффекта, если в нем находятся не самые свежие сертификаты или наша система сильно устарела или не имеет выхода в Интернет.

В этом случае нам нужно загрузить пакет с корневыми сертификатами вручную. Разберем пример на системе Ubuntu. В официальном репозитории или в поисковой системе находим пакет для загрузки, например, по ссылке ftp.ru.debian.org/debian/pool/main/c/ca-certificates копируем ссылку на файл с последней версией сертификатов, и загружаем его на наш компьютер:

Полученный пакет устанавливаем в системе:

dpkg -i ca-certificates_20210119_all.deb

И обновляем корневые сертификаты:

Установка вручную

Выше рассмотрены самые удобные способы обновления корневых сертификатов. Но мы можем столкнуться с ситуацией, когда в предоставляемых официальных пакетах не окажется обновленного сертификата. Например, на момент написания данной инструкции у систем на базе Deb не оказалось нового сертификата для Let’s Encrypt, а старый закончил свое действие 30 сентября 2021 года.

В данном случае, мы можем установить любой нужный нам сертификат руками. Для этого скачала находим его и копируем — приведем пример с Let’s Encrypt. На странице letsencrypt.org/ru/certificates мы можем увидеть ссылки на корневые сертификаты. Допустим, нам нужен Let’s Encrypt Authority X3 (Signed by ISRG Root X1), который доступен по ссылке letsencrypt.org/certs/letsencryptauthorityx3.pem.txt. Копируем последовательность и создаем файл на компьютере:

——BEGIN CERTIFICATE——
MIIFjTCCA3WgAwIBAgIRANOxciY0IzLc9AUoUSrsnGowDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTYxMDA2MTU0MzU1
WhcNMjExMDA2MTU0MzU1WjBKMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDEjMCEGA1UEAxMaTGV0J3MgRW5jcnlwdCBBdXRob3JpdHkgWDMwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc0wzwWuUuR7dyXTeDs2hjMOrX
NSYZJeG9vjXxcJIvt7hLQQWrqZ41CFjssSrEaIcLo+N15Obzp2JxunmBYB/XkZqf
89B4Z3HIaQ6Vkc/+5pnpYDxIzH7KTXcSJJ1HG1rrueweNwAcnKx7pwXqzkrrvUHl
Npi5y/1tPJZo3yMqQpAMhnRnyH+lmrhSYRQTP2XpgofL2/oOVvaGifOFP5eGr7Dc
Gu9rDZUWfcQroGWymQQ2dYBrrErzG5BJeC+ilk8qICUpBMZ0wNAxzY8xOJUWuqgz
uEPxsR/DMH+ieTETPS02+OP88jNquTkxxa/EjQ0dZBYzqvqEKbbUC8DYfcOTAgMB
AAGjggFnMIIBYzAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADBU
BgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEBATAwMC4GCCsGAQUFBwIB
FiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQub3JnMB0GA1UdDgQWBBSo
SmpjBH3duubRObemRWXv86jsoTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js
LnJvb3QteDEubGV0c2VuY3J5cHQub3JnMHIGCCsGAQUFBwEBBGYwZDAwBggrBgEF
BQcwAYYkaHR0cDovL29jc3Aucm9vdC14MS5sZXRzZW5jcnlwdC5vcmcvMDAGCCsG
AQUFBzAChiRodHRwOi8vY2VydC5yb290LXgxLmxldHNlbmNyeXB0Lm9yZy8wHwYD
VR0jBBgwFoAUebRZ5nu25eQBc4AIiMgaWPbpm24wDQYJKoZIhvcNAQELBQADggIB
ABnPdSA0LTqmRf/Q1eaM2jLonG4bQdEnqOJQ8nCqxOeTRrToEKtwT++36gTSlBGx
A/5dut82jJQ2jxN8RI8L9QFXrWi4xXnA2EqA10yjHiR6H9cj6MFiOnb5In1eWsRM
UM2v3e9tNsCAgBukPHAg1lQh07rvFKm/Bz9BCjaxorALINUfZ9DD64j2igLIxle2
DPxW8dI/F2loHMjXZjqG8RkqZUdoxtID5+90FgsGIfkMpqgRS05f4zPbCEHqCXl1
eO5HyELTgcVlLXXQDgAWnRzut1hFJeczY1tjQQno6f6s+nMydLN26WuU4s3UYvOu
OsUxRlJu7TSRHqDC3lSE5XggVkzdaPkuKGQbGpny+01/47hfXXNB7HntWNZ6N2Vw
p7G6OfY+YQrZwIaQmhrIqJZuigsrbe3W+gdn5ykE9+Ky0VgVUsfxo52mwFYs1JKY
2PGDuWx8M6DlS6qQkvHaRUo0FMd8TsSlbF0/v965qGFKhSDeQoMpYnwcmQilRh/0
ayLThlHLN81gSkJjVrPI0Y8xCVPB4twb1PFUd2fPM3sA1tJ83sZ5v8vgFv2yofKR
PB0t6JzUA81mSqM3kxl5e+IZwhYAyO0OTg3/fs8HqGTNKd9BqoUwSRBzp06JMg5b
rUCGwbCUDI0mxadJ3Bz4WxR6fyNpBK2yAinWEsikxqEt
——END CERTIFICATE——

Открываем на редактирование файл:

И добавляем в него строку с указанием на созданный файл:

Источник

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

Источник

Где в 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 выполните команду:

Источник