Где лежат сертификаты linux
От корневых сертификатов в системе может зависеть правильная работа при обращении к ресурсам, которые работают по зашифрованному каналу связи. Если данные сертификаты устареют, мы можем столкнуться с рядом проблем:
Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания.
Установка из репозитория
Самый простой способ, который нужно попробовать, установить сертификаты из официального репозитория системы. В зависимости от ее типа, наши команды будут немного отличаться.
а) для систем на базе DEB (Debian, Ubuntu, Mint):
apt install ca-certificates
б) для систем на базе RPM (Rocky Linux, CentOS):
yum install ca-certificates
Если нам повезет и в репозитории будут обновленные корневые центры, наша работа закончена. Иначе, устанавливаем сертификаты вручную.
Загрузка пакета с сертификатами
Установка из репозитория может не дать нужного эффекта, если в нем находятся не самые свежие сертификаты или наша система сильно устарела или не имеет выхода в Интернет.
Полученный пакет устанавливаем в системе:
dpkg -i ca-certificates_*_all.deb
И обновляем корневые сертификаты:
Установка вручную
-----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-----
В целях безопасности, в частности во избежание перехвата конфиденциальных, персональных или важных данных. Многие владельцы сайтов в сети защищают трафик с помощью SSL-сертификатов. Естественно, защите подлежит только тот трафик, который связан непосредственно с запросами и передачей данных с определённым адресом — адресом сайта. Системные администраторы, сотрудники техподдержки должны ориентироваться в вопросах, касающихся создания и внедрения SSL-сертификатов для хостов. Поскольку предоставляют соответствующие услуги. Для этих целей в системах Linux существует утилита openssl. Она является свободной реализацией методов защиты, протокола SSL, а также генерации сертификатов.
Как SSL-сертификат помогает защитить данные?
На самом деле схема защиты трафика основана на его шифровании открытым ключом и его расшифровке закрытым ключом. Понятие SSL-сертификата применимо в контексте подтверждения того факта, что открытый ключ действительно принадлежит именно тому домену, с которым происходит соединение. Таким образом, в данной схеме присутствуют две составляющие:
- Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
- Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.
Общий порядок создания SSL-сертификата, ключи и подпись
Во время создания SSL-сертификата происходит последовательная обработка следующих видов ключей:
- *.key – это сами ключи шифрования, открытий и/или закрытый;
- *.csr – ключ, содержащий сформированный запрос для получения подписи сертификата от центра сертификации, а сам запрос — это открытый ключ и информация о домене и организации, связанной с ним;
- *.crt, *.cer, *.pem – это, собственно, сам сертификат, подписанный центром сертификации по запросу из файла *.csr.
Для начала нужно создать закрытый ключ:
Здесь команда genrsa генерирует RSA-ключ, опция -des3 указывает алгоритм шифрования ключа. А опция -out указывает, что ключ должен быть получен в виде файла server.key. Число 2048 — это сложность шифрования. При выполнении этой команды пользователю будет предложено ввести пароль для шифрования. Поскольку указан его алгоритм опцией -des3. Если это личный ключ и его планируется использовать на сервере, который можно настроить в собственных целях, то естественно шифрование обязательно. Однако, многие серверы требуют закрытые ключи без шифрования (например хостинг-площадки, поскольку предоставляют универсальную услугу по заказу SSL-сертификатов). Поэтому перед генерацией закрытого ключа нужно определиться, как он будет использоваться.
Теперь нужно создать запрос на подпись — CSR-файл, который будет включать только что сгенерированный ключ server.key:
Подписание SSL-сертификатов
Получить подписанный сертификат, когда имеется закрытый ключ и запрос на подпись можно несколькими способами: воспользоваться услугой авторитетных центров сертификации, отправив им запрос (CSR-файл) и получив в ответ готовый сертификат *.crt. Либо можно сделать сертификат самоподписанным. Т. е. подписать его тем же ключом, который использовался при создании файла CSR. Для этого следует выполнить команду:
Здесь опция -days указывает количество дней, в течение которых выпускаемый сертификат server.crt будет действителен. В данном случае на протяжении одного года.
Также можно создать самоподписанный сертификат из имеющегося закрытого ключа без использования CSR-файла. Но в этом случае нужно вводить информацию CSR-запроса:
Параметр -x509 задаёт формат генерируемого сертификата. Он является самым распространённым и используется в большинстве случаев. Опция -new позволяет запрашивать информацию для запроса у пользователя.
Важно отметить, что сертификаты, подписанные авторитетными центрами сертификации известны веб-браузерам. Самоподписанные сертификаты необходимо импортировать в хранилище доверенных сертификатов веб-браузера вручную. Поскольку соединения с доменами, обслуживаемыми такими сертификатами по-умолчанию блокируются.
Использование SSL-сертификатов для домена
Для использования сертификата доменом, для которого он был создан, необходимо соответствующим образом настроить виртуальный хост этого домена. Для начала нужно сохранить файлы *.crt и *.key где-нибудь, где доступ к ним может получить только их владелец. Например в
/ssl/certs/ нужно поместить файл server.crt, в
Как подключить ssl сертификата в nginx читайте в этой статье.
Заключение
В заключение следует заметить, что генерация и подключение SSL-сертификатов к домену — далеко не самая сложная задача. Однако она требует очень внимательного выполнения отдельных её этапов, поскольку от ошибки зависит безопасность для домена.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Добавление в 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 .
TLS_CACERTDIR <path>
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
Когда вы сгенерировали CSR-запрос и приобрели SSL сертификат, воспользуйтесь этой инструкцией по установке сертификата на веб-сервер Nginx под управлением Linux: Ubuntu, Debian или CentOS.
После заказа SSL сертификата файлы для его установки отразятся в панели управления (меню SSL): .CA - файл сертификата Центра Сертификации (Certificate Authority). .CRT - файл сертификата вашего веб-сайта.
Как загрузить нужные файла на веб-сервер
Прежде всего загрузите файлы .ca и .crt на веб-сервер. При отсутствии графического окружения рабочего стола на сервере загрузка файлов может осуществиться на другой компьютер. Впоследствии их можно будет перенести.
Внимание: предполагается, что нужная для применения пара закрытый/открытый ключ была создана на том же веб-сервере, куда будет перенесен приобретенный сертификат. При создании ключей на другом сервере следует также перенести файл закрытого ключа .key на ваш веб-сервер (аналогично описанной ниже процедуре копирования файлов сертификатов).
Как переносить сертификаты с компьютера Linux/Mac OS:
Проще всего – при помощи опции SCP, встроенной в возможность терминала вашего компьютера:
Скачайте файлы .CA и .CRT на локальный компьютер. Откройте терминал и папку с сохраненными сертификатами (напр., Downloads):
Скопируйте сертификаты вашего сайта и Центра Сертификации на веб-сервер:
scp - команда для копирования файлов
user - имя вашего пользователя для подключения к серверу через ssh (часто используется root)
1.1.1.1 - IP-адрес вашего веб-сервера
/etc/ssl - директория на удаленном сервере, куда следует сохранить загружаемые файлы.
Как переносить сертификаты с компьютера Windows:
Скачайте, установите и включите программу WinSCP. В открывшемся окне наберите данные для подключения к вашему серверу по SSH. Слева в окне отразятся файлы на локальном компьютере, справа - на подключенном удаленном сервере. Выберите или создайте директорию, куда нужно сохранить сертификаты, в правой части окна. Перетащите файлы .CA и .CRT в эту директорию из левой части окна.
Внимание: можно перенести файл закрытого ключа (.key) для удобства в ту же директорию, куда вы скопировали файлы сертификатов. Если вы не делаете этого, просто запомните путь до этого файла и потом укажите его в файле конфигурации Apache вместо пути, рассмотренном в нашем примере.
Если закрытый ключ .key сгенерирован прямо на сервере, то для его копирования в другую директорию подойдет команда:
cp /home/root/private.key /etc/ssl/private.key
cp - команда копирования
/home/root/ - путь до файла ключа
private.key - имя файла ключа
/etc/ssl/private.key - путь, по которому необходимо скопировать файл ключа
Вы можете удалить файл ключа из старого расположения такой командой:
Как настроить веб-сервер Nginx на применение SSL сертификата
После копирования файлов сертификата сайта и Центра Сертификации вы должны отредактировать параметры вашего веб-сервера Nginx. Подключитесь к вашему серверу по SSH от имени пользователя root и выполните такие действия:
1. Объедините файлы сертификата Центра Сертификации (.CA) и сертификата вашего веб-сайта (.CRT) в один документ:
2. Откройте файл конфигурации сайта, для которого устанавливается SSL сертификат. Если, к примеру, параметры веб-сайта хранятся в файле /etc/nginx/sites-enabled/default:
Внимание: На Ubuntu/Debian файлы параметров сайтов Nginx обычно располагаются в директории /etc/nginx/sites-enabled/ . На CentOS стандартное расположение - /etc/nginx/conf.d/
Для поиска интересующей конфигурации подойдет команда ls /директория/конфигураций (напр. ls /etc/nginx/sites-enabled), отображающая полный список файлов в нужной директории.
Внимание для CentOS: если на сервере не установлен редактор nano, используйте такую команду для его установки:
используйте такую команду для его установки:
yum install nano
Затем добавьте приведенные ниже параметры в открытый файл конфигурации:
listen 443 ssl;
ssl_certificate /etc/ssl/mydomain.crt;
ssl_certificate_key /etc/ssl/private.key;
/etc/ssl/mydomain.crt - путь до файла сертификатов вашего сайта и центра сертификации
/etc/ssl/private.key - путь к файлу вашего закрытого ключа
(изменения выделены жирным шрифтом).
Перезапустите сервис nginx:
service nginx restart
Ubuntu 16.04:
ufw allow 443/tcp
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
Читайте также: