Веб-стек / Ступень 5 из 9 · шаг 6 из 7

Магазин после перевыпуска сертификата

~25 мин

Не запущена Запускается обычно ~20 с

Ситуация

Интернет-магазин компании store.lab.test работает по HTTPS на nginx этой машины. В этом месяце учебный центр сертификации (CA) перевыпустил магазину сертификат, новый файл положили на место старого. После этого пишут двое.

Разработчик: «В браузере магазин открывается, а curl и наш сервис оплаты получают ошибку сертификата». Маркетолог: «Ссылки из старой рассылки, вроде http://store.lab.test/catalog?page=2, открывают главную страницу вместо каталога».

Корневому сертификату учебного CA доверяют все машины компании, эта тоже. Сертификаты, которыми CA подписывает сайты, он публикует в /srv/lab-ca. Файлы магазина — в /etc/ssl/store.

Задача

curl без -k открывает https://store.lab.test/ и получает страницу магазина.
Сертификат магазина проходит проверку у клиента, которому известен только корневой сертификат учебного CA (/srv/lab-ca/root.crt), — без настроек на стороне клиента.
http://store.lab.test/ отвечает кодом 301 и уводит на https://store.lab.test/.
Переход на HTTPS сохраняет путь и параметры: http://store.lab.test/catalog?page=2 уводит на https://store.lab.test/catalog?page=2.

Интернета на машине нет, всё нужное уже установлено.

Цели лабы

0 из 4

curl без -k открывает https://store.lab.test/ и получает страницу магазина — ещё не проверялась
Сертификат магазина проходит проверку у клиента, которому известен только корневой сертификат учебного CA — ещё не проверялась
http://store.lab.test/ отвечает кодом 301 и уводит на https://store.lab.test/ — ещё не проверялась
http://store.lab.test/catalog?page=2 уводит на https://store.lab.test/catalog?page=2 — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Безопасность · подобрано по лабе

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 cp ca.pem /usr/local/share/ca-certificates/lab.crt
sudo update-ca-certificates CA в доверие

Что отдаёт сервер

bash

openssl s_client -connect secure.lab.test:443 \
  -servername secure.lab.test -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

Первый сертификат в выводе — сертификат сайта. Цепочку целиком — строки s: (кому) и i: (кем подписан):

text

 0 s:CN = secure.lab.test
   i:CN = Lab Intermediate CA
 1 s:CN = Lab Intermediate CA
   i:CN = Lab Root CA

Только строка 0 — сервер не отдаёт промежуточный. -servername передаёт имя сайта в начале TLS (SNI): по нему nginx с несколькими сайтами на 443 выбирает сертификат. Без имени, например при подключении к IP, приходит сертификат сервера по умолчанию.

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

bash

openssl verify -CAfile ca.pem site.pem
openssl verify -CAfile ca.pem -untrusted int.pem site.pem

Первая команда без промежуточного — error 20 at 0 depth lookup: unable to get local issuer certificate. Вторая — site.pem: OK: от сайта через промежуточный до корня цепочка сходится.

Собрать файл полной цепочки

bash

cat site.pem int.pem > fullchain.pem
grep -c BEGIN fullchain.pem      # 2

Порядок — сертификат сайта первым, за ним промежуточный. Корень в файл не кладут: он у клиента свой. Подключение файла в nginx — nginx.

Ключ и сертификат — пара?

bash

openssl x509 -in site.pem -noout -pubkey | sha256sum
openssl pkey -in site.key -pubout | sha256sum

Суммы совпали — пара. Не совпали — nginx не примет конфиг: key values mismatch.

Выпустить сертификат с прежним ключом

bash

openssl req -new -key site.key -out site.csr -subj '/CN=shop.lab.test' \
  -addext 'subjectAltName=DNS:shop.lab.test,DNS:www.shop.lab.test'
openssl x509 -req -in site.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -days 90 -copy_extensions copy -out site.pem
openssl x509 -in site.pem -noout -ext subjectAltName -enddate

-copy_extensions copy переносит SAN из запроса в сертификат. Без него сертификат выйдет без имён: -ext subjectAltName напишет No extensions in certificate, и curl отвергнет его по имени. Готовый сертификат — в файл, на который смотрит сервер, затем nginx -t и reload.

Сколько осталось до конца срока

bash

openssl x509 -in site.pem -noout -enddate
openssl x509 -in site.pem -noout -checkend 2592000; echo $?

-checkend N — истечёт ли сертификат за N секунд (2592000 — 30 дней): Certificate will expire и код 1 или Certificate will not expire и код 0. Удобно в проверках и мониторинге.

Свой CA в доверие системы

bash

sudo cp ca.pem /usr/local/share/ca-certificates/lab-root.crt
sudo update-ca-certificates

Файл должен называться *.crt. Команда пишет 1 added, 0 removed; done., после этого curl и другие программы на OpenSSL верят сертификатам этого CA без --cacert.

Let's Encrypt (certbot)

bash

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run
systemctl list-timers certbot.timer

Публичный CA для сайтов в интернете: сертификат на 90 дней, таймер продлевает его заранее. Нужны DNS-имя на этот сервер и доступный снаружи порт 80. В учебных ВМ сети наружу нет, поэтому там — свой учебный CA.

certificate has expired

curl: (60) SSL certificate problem: certificate has expired, у openssl s_client — Verify return code: 10. Проверь notAfter сертификата, который отдаёт сервер (рецепт выше), и часы машины — timedatectl. Выпусти новый, замени файл и сделай reload: старый сертификат nginx держит в памяти.

unable to get local issuer certificate

Клиент не дошёл до доверенного корня. Две причины:

CA клиенту не известен — --cacert или update-ca-certificates;
сервер не отдаёт промежуточный — у s_client одна строка 0 s: и Verify return code: 21 (unable to verify the first certificate). Нужен файл полной цепочки.

no alternative certificate subject name matches

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.

self-signed certificate

curl: (60) SSL certificate problem: self-signed certificate, у s_client — код 18. Сервер отдаёт сертификат, подписанный им самим, и в хранилище доверия его нет. Для своего сервиса — выпусти сертификат от своего CA и положи корень в доверие.

wrong version number

curl: (35) … SSL routines::wrong version number — https:// ушёл на порт, где говорят обычным HTTP. Проверь порт и listen … ssl у сервера.

Сервер отдаёт старый сертификат

Файл заменён, а s_client показывает старый notAfter: nginx не перечитал конфиг. sudo nginx -t && sudo systemctl reload nginx и проверка через секунду — nginx.

curl -k в скриптах и проверках

-k (--insecure) молча пропускает подмену сервера, истёкший сертификат и чужое имя. Проверка «сайт отвечает по HTTPS» с -k проходит и тогда, когда пользователи видят ошибку. Вместо -k — --cacert с нужным CA.

Закрытый ключ

Ключ даёт право выдавать себя за сайт. Права — 600, владелец — root, в репозитории, письма и чаты ключ не попадает. Утёк — выпусти сертификат на новый ключ.