Проверка цепочки сертификатов линукс

Openssl, проверка SSL-сертификатов через терминал

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT. Также имеется возможность шифрования данных и тестирования SSL/TLS соединений.

Рассмотрим на примерах следующие случаи:
1. Генерация CSR и ключа.
2. Создание нового CSR для уже имеющегося ключа.
3. Проверка корректности CSR.
4. Проверка корректности ключа.
5. Проверка данных SSL-сертификата.
6. Декодирование CSR.
7. Декодирование SSL-сертификата.
8. Сравнение соответствия SSL-сертификата и CSR.
9. Сравнение соответствия SSL-сертификата и ключа.
10. Проверка правильности порядка установки CA сертификатов.

Первое что нужно сделать — это зайти по SSH на сервер и установить OpenSSL.

1. Генерация CSR и ключа

Перейдем в директорию, в которой будут хранится файлы CSR и ключа:

Далее выполняем команду генерации CSR и ключа:

openssl req -out server.csr -new -newkey rsa:2048 -nodes -keyout server.key

server.key – имя файла ключа;

имена можно менять по своему усмотрению.

После ввода команды, так же как и через онлайн генератор CSR нужно ввести данные в поля:

Проверяем создались ли файлы:

Файлы создались, все в порядке. Можно заказывать SSL-сертификат.

Подробно о заказе и установке SSL-сертификата можно ознакомиться в статье “Заказ и установка SSL сертификата на хостинг Ukrnames”

Мы получили файлы сертификата (ukrnames_idua_org, ca_1, ca_2, ca_3) и переместим их так же в папку /etc/ssl/certs/

Можем переходить теперь к следующим пунктам статьи.

2. Создание нового CSR для уже имеющегося ключа.

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

Данная команда позволит заново сгенерировать CSR-запрос на основании имеющегося у нас ключа (в данном примере ключ у нас находится в папке /etc/ssl/certs/server.key):

openssl req -out /etc/ssl/certs/server.csr -key /etc/ssl/certs/server.key -new

И вновь нужно вводить данные CSR.

Потом можем копировать данные файла server.csr и продлевать SSL-сертификат, копировать ключ уже не нужно, он заново сгенерирован в старый файл ключа /etc/ssl/certs/server.key.

3. Проверка корректности CSR

Выполним команду для проверки корректности содержимого CSR:

openssl req -text -noout -verify -in /etc/ssl/certs/server.csr

Получаем вывод, в котором стоит обратить внимание на поле verify , если стоит статус “OK” , значит с CSR все в порядке.

4. Проверка корректности ключа

Выполним команду для проверки корректности содержимого ключа:

openssl rsa -in /etc/ssl/certs/server.key -check

Получаем вывод, в котором стоит обратить внимание на поле RSA key, если стоит статус “ok”, значит с ключом все в порядке.

5. Проверка данных SSL-сертификата

Переименуем для удобства файл сертификата ukrnames_idua_org в server.crt с помощью команды:

mv /etc/ssl/certs/ukrnames_idua_org /etc/ssl/certs/server.crt

Выполним команду для проверки данных SSL-сертификата:

openssl x509 -in /etc/ssl/certs/server.crt -text -noout

Получаем вывод, в котором можно ознакомится с подробностями SSL-сертификата (кто выдал, для какого домена выдан и т.д.).

6. Декодирование CSR

Иногда после генерации CSR хочется проверить правильность ввода данных. Для этого достаточно выполнить команду:

openssl req -in /etc/ssl/certs/server.csr -noout -text

Получим вывод, в котором стоит обратить внимание на поле “Subject:”, в нем указаны все вводимые нами данные.

7. Декодирование SSL-сертификата

Вывести данные SSL-сертификата можно командой:

openssl x509 -in certificate.crt -text -noout

Вывод будет эдентичен выводу в пункте 5.

8. Сравнение соответствия SSL-сертификата и ключа

Для того чтобы сравнить SSL-сертификат и ключ, нужно будет вывести хеши данных их файлов и сравнить.

openssl x509 -noout -modulus -in /etc/ssl/certs/server.crt | md5sum

openssl rsa -noout -modulus -in /etc/ssl/certs/server.key | md5sum

Получим вывод на экран хешей:

5bece1c3929b08096dcad3eb4613b300

5bece1c3929b08096dcad3eb4613b300

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

9. Сравнение соответствия SSL-сертификата и CSR

Для данного примера заменим данные CSR файла /etc/ssl/certs/server.csr на другие:

openssl req -out /etc/ssl/certs/server.csr -key /etc/ssl/certs/server.key -new

Выполним команды для вывода хешей файлов /etc/ssl/certs/server.crt и /etc/ssl/certs/server.csr:

openssl x509 -noout -modulus -in /etc/ssl/certs/server.crt | md5sum

openssl req -noout -modulus -in /etc/ssl/certs/server.csr | md5sum

5bece1c3929b08096dcad3eb4613b300

6f4526732defc3985a3abd37f877eae5

Как видим, хеши отличаются – это означает, что сертификат не совпадает с CSR.

10. Проверка правильности порядка установки CA сертификатов.

На данном сервере, где выполнялись работы с openssl, установим веб-сервер, подключим домен ukrnames.idua.org и установим для него SSL-сертификат.

Т.к. веб-сервер не имеет доступа к папке /etc/ssl/certs/ , то копируем ключ, сертификат и промежуточные сертификаты в новосозданную папку /var/www/ssl/

В файле конфигурации веб-сервера подключаем файлы SSL-сертификата. Но чтобы все корректно работало, нужно создать файл для промежуточных сертификатов (к примеру ca.pem) и внести в него с определенной последовательностью данные файлов промежуточных сертификатов (ca_1, ca_2, ca_3).

Чтобы понять в какой последовательности нужно добавлять файлы, выполним ряд действий.

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

openssl x509 -in /var/www/ssl/server.crt -noout -text | grep Issuer:

Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA

Теперь получим данные о промежуточных сертификатах ca_1, ca_2, ca_3 (нужно обращать внимание только на поля “Issuer:” и “Subject:”):

openssl x509 -in /var/www/ssl/ca_1 -noout -text | egrep "Subject:|Issuer:"

openssl x509 -in /var/www/ssl/ca_2 -noout -text | egrep "Subject:|Issuer:"

openssl x509 -in /var/www/ssl/ca_3 -noout -text | egrep "Subject:|Issuer:"

Сопоставив данные сертификата и промежуточных сертификатов, можно сделать вывод, что после основного сертификата первым промежуточным должен идти сертификат ca_3, т.к. в поле “Subject:” раздел CN файла ca_3 совпадает с полем “Issuer:” разделом CN (CN=COMODO RSA Domain Validation Secure Server CA).

Далее смотрим на поле “Issure:” раздел CN файла ca_3 (CN=COMODO RSA Certification Authority). Ищем в выводах файлов ca_2 и ca_1 совпадение в полях “Subject:” . Совпадение найдено в файле ca_2, данный файл мы будем подключать вторым.

И методом исключения, файл ca_1 будет подключаться самым последним.

Выполняем команды для объединения всех файлов промежуточных сертификатов(ca_1, ca_2, ca_3) в один (ca.pem):

cat /var/www/ssl/ca_3 > /var/www/ssl/ca.pem cat /var/www/ssl/ca_2 >> /var/www/ssl/ca.pem cat /var/www/ssl/ca_1 >> /var/www/ssl/ca.pem

Теперь можем увидеть полную цепочку установленных сертификатов с помощью команды:

openssl s_client -connect ukrnames.idua.org:443

Получим вывод на экран правильной цепочки подключения сертификатов:

Источник

showcert: проверяем сертификаты (без боли)

showcert — маленькая CLI утилитка, альтернатива openssl для просмотра сертификатов. Она умеет 1% того, что может openssl, но зато умеет [почти] все, что нужно в обычной админской жизни и даже немного больше чем openssl. И гораздо проще в использовании. Основные функции:

• Взять сертификат (или цепочку) из stdin, файла(файлов) или из TLS сервиса (HTTPS, POP3S, IMAPS), в том числе через STARTTLS (для SMTP, POP3, IMAP)
• Проверить валидность сертификата.
• Проверить «свежесть» сертификата, и если срок действия истекает через N дней — передать это в коде завершения.
• Распечатать сертификат (цепочку) в краткой форме (только основное), полной, в PEM формате (для сохранения в cert.pem или fullchain.pem).

И все это делается простым, интуитивно-понятным образом, для людей.

Когда я хочу проверить дату истечения, например, почтового сертификата яндекса, немного гуглю, потом сноровисто пишу что-то вроде:

$ echo | openssl s_client -connect mx.yandex.ru:25 -starttls smtp 2>&1 | openssl x509 -noout -dates

Когда я печатаю эту строчку, вспоминаю немало многокоренных слов из флотской службы, а ведь я даже не служил. А теперь, представьте, что мы хотим не просто увидеть дату, а еще и как-то что-то сделать, если до истечения останется меньше 20 дней. как будет выглядеть команда? Мне вообще сложно представить, как это можно автоматизировать через openssl и простые шелл скрипты.

Просмотр сертификатов через showcert

А теперь (после установки: pip3 install showcert ) сравните с:

$ showcert mx.yandex.ru:25
Names: mx.yandex.ru mx.yandex.net
notBefore: 2022-07-25 11:16:45 (15 days old)
notAfter: 2023-01-22 20:59:59 (165 days left)
Issuer: C=BE O=GlobalSign nv-sa CN=GlobalSign RSA OV SSL CA 2018

Ну разве не проще? showcert сам (по номеру порта) догадывается, как начать STARTTLS (но конечно же, это можно переопределить через опцию -t / —starttls, например, -t no или -t imap).

Предупредить о том, что сертификат скоро протухнет? Окей!

$ showcert mx.yandex.ru:25 -qw 200 || echo PROBLEM
mx.yandex.ru:25 expires in 165 days
PROBLEM

-q — тихий режим, не печатать лишнего, только предупреждения, -w 200 — завершаться с кодом ошибки, если до протухания меньше 200 дней.

Проверить https вебсайт? showcert github.com (Несложный синтаксис?)

«Скопировать» fullchain.pem с сервера (взять его и распечатать в PEM):

$ showcert google.com —chain -o pem > fullchain.pem

У меня после этого дампа (не с гугла, а со своего другого сервера) — даже md5 файлов сошелся!

Так же можно посмотреть или проверить один или несколько локальных файлов сертификатов (fullchain.pem или cert.pem).

Можно добавить —chain чтобы увидеть всю цепочку. И ключ -w тоже работает.

Формат вывода сертификатов

По умолчанию ( -o brief ) выводится краткая информация (все, что обычно важно, минимум лишнего). -o full дает полный дамп (как openssl), -o pem даст сертификат в PEM формате (удобно сделать редирект в файл и получить его на диске).

Еще есть удобный формат -o names — просто распечатывает все имена из сертификата, и его вариация -o dnames , о ней ниже.

Сахар для LetsEncrypt

Мы много используем LetsEncrypt, поэтому showcert удобен для этого. На сервере могут быть десятки (а то и сотни) сайтов, у каждого сертификат. Да, certbot renew в теории должен обновлять их, но сайты живые, постоянно разрабатываются, причем разными людьми и с ними иногда происходят разные чудеса. То поменяется DocumentRoot, то появятся правила rewrite/redirect, которые блокируют проверку, то доменное имя куда-то уедет. В общем, обновления иногда фейлятся и сертификаты протухают. А когда сайтов много, что-то проблемное случается регулярно.

Мы используем okerr (статья про okerr на хабре) для мониторинга. Наш собственный open source гибридный мониторинг. Раньше мы использовали скрипт, создавал индикатор типа sslcert для каждого сайта (это тоже не очень удобно, так как сайты ведь иногда и умирают или переезжают на другой сервер). Но с showcert стало еще проще:

Простой приятный способ проверить, что все LetsEncrypt сертификаты еще свежи:

# showcert :le -qw
/etc/letsencrypt/live/example.com/fullchain.pem expires in 19 days
/etc/letsencrypt/live/example.net/fullchain.pem expires in 19 days
# echo $?
2

Команда выше — синоним showcert /etc/letsencrypt/live/*/fullchain.pem -qw , а код :le запомнить проще, чем путь к сертификатам. Ну и код завершения удобен, чтобы использовать его в мониторинге, собственных скриптах. У нас showcert вызывается из okerrupdate/okerrmod, в окерр внешние скрипты проверки цепляются одной строчкой, но если у вас другой мониторинг — тоже сможете легко подцепить showcert.

Если не используете никакой мониторинг, то showcert :le -qw в cron раз в сутки — оповестит заранее о сертификатах, которые своевременно не смогли обновиться, и у вас будет время починить.

Еще одна опция: -o dnames печатает имена через -d, это удобно чтобы скармливать их certbot:

$ showcert -o dnames habr.ru
-d habr.ru -d www.habr.ru

Для двух имен, как у хабра — это не имеет особого смысла, но если у сертификата имен много, и вам нужно пересоздать его — вручную печатать их можно и ошибиться. Проще через showcert получить часть команды и просто использовать ее (или даже использовать сам showcert в команде:

certbot certonly —webroot /var/www/habr `showcert -o dnames habr.ru`

Попробуйте, например, showcert -o dnames google.com .

Заключение

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

Очень советую попробовать 🙂

Источник