TLS-сертификат связывает ключ сервера с именем сайта; openssl читает его поля, проверяет цепочку и выпускает новый.
openssl x509 -in site.pem -noout -subject -issuer -dates
openssl x509 -in site.pem -noout -ext subjectAltName
имена
openssl x509 -in site.pem -noout -checkend 2592000
30 дней?
openssl s_client -connect site.lab.test:443 -servername site.lab.test \
-showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'
openssl verify -CAfile ca.pem -untrusted int.pem site.pem
curl --cacert ca.pem https://site.lab.test/
свой CA
sudo update-ca-certificates
CA в доверие
TLS шифрует соединение и до первого байта http даёт клиенту проверить, что сервер — тот, за кого себя выдаёт. Для этого сервер показывает сертификат: открытый ключ, имена сайта и срок, заверенные подписью центра сертификации. Парный закрытый ключ лежит только на сервере.
subject — кому выдан, issuer — кто подписал, notBefore/notAfter — срок,
SAN — имена, для которых сертификат годен.
| Проверка | Что сверяет | Ошибка curl |
|---|---|---|
| доверие | цепочка подписей доходит до CA из хранилища | unable to get local issuer certificate |
| имя | имя из адреса есть в SAN | no alternative certificate subject name matches |
| срок | сейчас между notBefore и notAfter | certificate has expired |
Любая не прошла — curl выходит с кодом 60, браузер показывает страницу ошибки.
curl -k отключает все три: соединение шифруется, но с кем — неизвестно.
Сертификат сайта обычно подписан не корнем, а
промежуточным CA, а тот — корневым. Корень
подписан сам собой (subject = issuer), и ему
верят потому, что он лежит в хранилище доверия клиента. В
Ubuntu это /etc/ssl/certs; свой корень туда добавляет
update-ca-certificates, для одного запроса — curl --cacert ca.pem.
Клиент знает только корни. Промежуточный ему присылает сервер, вместе с
сертификатом сайта — это цепочка. Сервер отдал один
сертификат сайта — клиент не может дойти до корня и пишет
unable to get local issuer certificate, хотя корень у него есть.
Файлы PEM — текст между строками -----BEGIN …----- и -----END …-----,
внутри base64. По первой строке видно, что в файле:
| Первая строка | Что это |
|---|---|
-----BEGIN PRIVATE KEY----- |
закрытый ключ |
-----BEGIN CERTIFICATE REQUEST----- |
запрос CSR |
-----BEGIN CERTIFICATE----- |
сертификат |
Сертификат выпускают из запроса (CSR): в нём открытый ключ и нужные имена. CA подписывает запрос и возвращает сертификат. Новый запрос на прежний ключ даёт новый сертификат без смены ключа.
Первый сертификат в выводе — сертификат сайта. Цепочку целиком — строки
s: (кому) и i: (кем подписан):
Только строка 0 — сервер не отдаёт промежуточный. -servername передаёт
имя сайта в начале TLS (SNI): по нему nginx с несколькими сайтами
на 443 выбирает сертификат. Без имени, например при подключении к IP, приходит
сертификат сервера по умолчанию.
Первая команда без промежуточного — error 20 at 0 depth lookup: unable to get
local issuer certificate. Вторая — site.pem: OK: от сайта через
промежуточный до корня цепочка сходится.
Порядок — сертификат сайта первым, за ним промежуточный. Корень в файл не кладут: он у клиента свой. Подключение файла в nginx — nginx.
Суммы совпали — пара. Не совпали — nginx не примет конфиг:
key values mismatch.
-copy_extensions copy переносит SAN из запроса в сертификат. Без него
сертификат выйдет без имён: -ext subjectAltName напишет
No extensions in certificate, и curl отвергнет его по имени. Готовый
сертификат — в файл, на который смотрит сервер, затем nginx -t и reload.
-checkend N — истечёт ли сертификат за N секунд (2592000 — 30 дней):
Certificate will expire и код 1 или Certificate will not expire и код 0.
Удобно в проверках и мониторинге.
Файл должен называться *.crt. Команда пишет 1 added, 0 removed; done.,
после этого curl и другие программы на OpenSSL верят сертификатам этого CA без
--cacert.
Публичный CA для сайтов в интернете: сертификат на 90 дней, таймер продлевает его заранее. Нужны DNS-имя на этот сервер и доступный снаружи порт 80. В учебных ВМ сети наружу нет, поэтому там — свой учебный CA.
curl: (60) SSL certificate problem: certificate has expired, у
openssl s_client — Verify return code: 10. Проверь notAfter сертификата,
который отдаёт сервер (рецепт выше), и часы машины — timedatectl. Выпусти
новый, замени файл и сделай reload: старый сертификат nginx держит в памяти.
Клиент не дошёл до доверенного корня. Две причины:
--cacert или update-ca-certificates;s_client одна строка 0 s: и
Verify return code: 21 (unable to verify the first certificate). Нужен файл
полной цепочки.curl: (60) SSL: no alternative certificate subject name matches target host
name 'other.lab.test' — имени из адреса нет в SAN. Так же curl ответит на
обращение по IP. Посмотри имена: openssl x509 -noout -ext subjectAltName;
если SAN пуст — сертификат подписан без -copy_extensions.
curl: (60) SSL certificate problem: self-signed certificate, у s_client —
код 18. Сервер отдаёт сертификат, подписанный им самим, и в хранилище доверия
его нет. Для своего сервиса — выпусти сертификат от своего CA и положи корень
в доверие.
curl: (35) … SSL routines::wrong version number — https:// ушёл на порт, где
говорят обычным HTTP. Проверь порт и listen … ssl у сервера.
Файл заменён, а s_client показывает старый notAfter: nginx не
перечитал конфиг. sudo nginx -t && sudo systemctl reload nginx и проверка
через секунду — nginx.
-k (--insecure) молча пропускает подмену сервера, истёкший сертификат и
чужое имя. Проверка «сайт отвечает по HTTPS» с -k проходит и тогда, когда
пользователи видят ошибку. Вместо -k — --cacert с нужным CA.
Ключ даёт право выдавать себя за сайт. Права — 600, владелец — root, в
репозитории, письма и чаты ключ не попадает. Утёк — выпусти сертификат на
новый ключ.
ssl_certificate, цепочка, перенаправление на HTTPS.--cacert, -v с разбором рукопожатия.Есть неточность? Сообщить об ошибке в статье