Проверка валидности сертификата linux

Как проверить сертификат SSL в командной строке Linux?

SSL — это очень часто используемый интернет-протокол, предназначенный для шифрования сетевого трафика и, следовательно, обеспечения безопасного обмена данными по сети. Всякий раз, когда SSL включен на веб-сайте, с ним связан специальный сертификат SSL. Этот сертификат содержит такую ​​информацию, как доменное имя веб-сервера, имя органа, выдающего сертификат, дату истечения срока действия сертификата и т.д.

В этой статье мы объясним вам метод проверки сертификата SSL через командную строку Linux. Мы используем систему Linux Mint 20, чтобы продемонстрировать этот метод.

Метод проверки сертификата SSL в командной строке Linux Mint 20

Чтобы проверить SSL-сертификат любого желаемого веб-сервера на определенном номере порта, вам нужно будет выполнить следующую команду в своем терминале Linux Mint 20:

Здесь вам нужно будет заменить WebServerURL именем веб-сервера, чей SSL-сертификат вы хотите проверить, а PortNumber — точным номером порта, к которому подключен этот веб-сервер. Мы заменили WebServerURL на google.com и PortNumber на 80, как показано на изображении ниже:

Информация о сертификате SSL указанного веб-сервера показана в командной строке Linux Mint 20 на следующем изображении:

Заключение

Следуя методу, описанному в этой статье, вы легко сможете проверить SSL-сертификат любого желаемого веб-сервера через командную строку Linux Mint 20. Этот метод основан на одной команде; следовательно, вы сможете быстро достичь желаемой цели. Более того, ту же процедуру можно использовать в системе Ubuntu 20.04 или Debian 10.

Источник

Как работает проверка подписи сертификатов (CA)?

Не совсем linux, но честно, не знаю куда еще податься. Прочитал кучу статей, наконец разобрался как работают технологии симметричных и ассиметричных ключей SSL, но так и не понял как именно (в математическом смысле) работает проверка валидности (читай подлинности) сертификата.

Допустим: Есть «клиент», желающий общаться с «сервером» в зашифрованном виде, клиент просит у сервера его публичный ключ, после чего его каким-то образом проверяет с имеющимся у него сертификатом (открытый ключ) доверительного центра сертификации (ЦС). А дальше история про Боба и Алису. Но как именно проверяется сертификат на его валидность и подписанность ЦС?

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

Я даже, вроде как, нашел формулу на википедии
http://bit.ly/1DXwL4u (Сертификат открытого ключа / Формальное описание)
Но в этой офигенной формуле один большой изъян: откуда блин взялась переменная Ss которой неожиданно владеет А2 ?!

Перемещено JB из general

Если на пальцах, то схема такая:
1. Сервер генерирует приватный ключ и запрос на получение сертификата — csr.
2. Отправляет csr сертифакионному центру
3. СЦ возвращает серверу сертификат (открытый ключ, подписанный закрытым ключом СЦ).
4. Когда клиент обращается к серверу, он первым делом смотрит на сертификат сервера. Если у него корректная подпись СЦ, значит ему можно доверять. Подписать сертификат сервера может только СЦ, ведь приватный ключ СЦ есть только у СЦ 🙂

1. Есть корневые CA. Это компании, которым большинство решило доверять. Каждая CA имеет приватный и публичный ключ (RSA или ECDSA). При помощи приватного ключа подписывается сертификат, который содержит публичный ключ. Все браузеры таскают с собой некоторый набор сертификатов корневых CA.

2. Сами корневые CA напрямую сертификаты не продают, а перепоручают это промежуточным CA. У промежуточного CA тоже есть свой публичный и приватный ключ. Промежуточный CA вставляет свой публичный ключ в заготовок для сертификта (CSR) и просит корневую CA подписать ее своим ключем. Корневая CA подписывает заготовку своим приватным ключем и получается сертификат промежуточного CA. Важно: подписанный корневым CA сертификат для промежуточного CA имеет право подписи ( в сертификате для этого делается специальная запись).

3. Промежуточные CA тоже часто сами не подписывают клиентам сертификаты, а перепоручают это дело другим промежуточным, подписывая уже своим приватным ключем сертификаты с правом подписи.

4. В конце концов мы приходим к конечному CA, который и выдает сертификаты клиентам. Итак, есть пользователь Вася. Он хочет для vasya.ru сертификат. Он генерирует приватный и публичный ключи, делает заготовку для сертификата с публичным ключем и отправляет запрос к CA для создания сертификата. Конечная CA подписывает своим приватным ключем запрос от клиента и получается сертификат для клиента. Этот сертификат + сертификаты ВСЕХ промежуточных CA, отдаются клиенту Васе. Вася в своем любимом веб сервере указывает путь к приватному ключу и путь к ЦЕПОЧКЕ сертификатов. Важно: Васин сертификат уже права подписи не имеет.

5. Маша в браузере Firefox, который с собой таскает набор корневых сертификатов, идет на https://vasya.ru. Сервер в ответ на запрос firefox возвращает ВСЮ ЦЕПОЧКУ сертификатов.

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

generator, Vovka-Korovka спасибо за общий алгоритм, но с ним я и так разобрался. Идём по цепочки и проверяем пока не дойдем до корневого. это всё понятно.

Но вопрос совсем в другом. Блин.. Довольно сложно формулировать вопрос. Попробую иначе.

Имеем:
— Некий сертификат с некой подписью (причем подпись генерируется с использованием неизвестной переменной)
— Имеется некий открытый ключ доверительного центра сертификации

И собственно всё. Как я зная всего лишь открытую часть, которая в доступе у всех однозначно определю что эта подпись верна? Ну да, пришел какой-то сертификат, ну да, кем-то там подписан. Всё что я могу «проверить» можно «подделать» т.к. и я и мошенник имеем публичную часть сертификата ЦС и только.

И собственно всё. Как я зная всего лишь открытую часть, которая в доступе у всех однозначно определю что эта подпись верна? Ну да, пришел какой-то сертификат, ну да, кем-то там подписан. Всё что я могу «проверить» можно «подделать» т.к. и я и мошенник имеем публичную часть сертификата ЦС и только.

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

Т.е. берется сертификат (сочетание открытого ключа, имени, периода действия, серийного номера и прочего), от этого всего считается хэш-функция (SHA1, SHA-2 или ещё какая-нибудь), затем результат хэш-функции зашифровывается закрытм (приватным) ключом. Результат шифрования и есть цифровая подпись. Для проверки подпись расшифровывается открытым ключом из сертификата CA и полученный хэш сравнивается с хэшем, который проверяющий считает самостоятельно от проверяемого сертификата

Источник

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

При установке 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 и ключа:

server.csr – имя файла CSR;

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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сопоставив данные сертификата и промежуточных сертификатов, можно сделать вывод, что после основного сертификата первым промежуточным должен идти сертификат 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):

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

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

Источник