Введение
Команда поддержки развернула сайт справки, но клиенты отклоняют HTTPS-соединение. HTTPS использует TLS для шифрования трафика и подтверждения личности ответившего сервера. Одного шифрования недостаточно: клиент также должен распознать запрошенное имя и доверять издателю сертификата.
Вы исправите синтетические учебные сертификаты на настоящем сервере Nginx. Достаточно базового владения терминалом; проверка сертификатов и настройка службы объясняются здесь. Client и Server — отдельные сеансы и каталоги одной VM, а не разные компьютеры. Nginx работает в подготовленном контейнере. Необязательный HTTPS Monitor показывает реальные внутренние TLS-проверки; значок замка браузера относится к другому, внешнему соединению.
Получить доверенный эталонный документ
На этом шаге получите документ работающей службы, затем сравните её с неисправным сайтом справки. Имя хоста обозначает запрашиваемую службу. Все учебные имена оканчиваются на .lab.test и действуют только в этом упражнении.
Используйте вкладку Client. curl получает содержимое URL. --cacert root.crt доверяет предоставленному центру сертификации (CA), подписывающему сертификаты. Это учебная точка доверия, а не общедоступный CA. --resolve сопоставляет имя и порт с IP-адресом, сохраняя имя для TLS и HTTP. 127.0.0.1 обозначает эту VM; порт 8443 ведёт к подготовленному Nginx. --noproxy '*' отправляет запрос напрямую; кавычки запрещают оболочке раскрывать *. --fail считает HTTP-ошибки неудачей, а --output сохраняет настоящий документ службы для дальнейшего использования.
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 --output reference.txt https://status.lab.test:8443/
cat показывает содержимое файла:
cat reference.txt
status service: training content available
Это реально загруженный эталонный документ, а не отчёт. Теперь запросите предусмотренное имя сайта справки. Следующая команда должна завершиться ошибкой и вернуть приглашение; после этого продолжайте.
curl --noproxy '*' --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
curl: (60) SSL: no alternative certificate subject name matches target host name 'help.lab.test'
...
Эталон работал с теми же CA и адресом. Эта ошибка указывает именно на несовпадение имени, а не на остановленный сервер. Сохраните ожидаемое имя: изменение URL проверит другую личность.
Исследовать и собрать цепочку сертификатов
На этом шаге сравните выдаваемую сервером личность с подготовленным сертификатом и создайте пригодный серверный набор. Сертификат содержит открытый ключ и сведения о личности. Соответствующий закрытый ключ остаётся на сервере. Никогда не вставляйте его в отчёт и не отправляйте клиентам.
В Client исследуйте фактически выдаваемый сертификат. openssl s_client открывает TLS-соединение; -connect задаёт адрес, а -servername передаёт запрошенное имя через Server Name Indication (SNI), позволяя одному слушателю Nginx обслуживать несколько сайтов. < /dev/null завершает интерактивный ввод. 2>/dev/null скрывает диагностику соединения только для этого просмотра. Конвейер | передаёт сертификат в openssl x509; -noout скрывает закодированный сертификат, остальные параметры показывают нужные поля. Сам просмотр ещё не доказывает доверие.
openssl s_client -connect 127.0.0.1:8443 -servername help.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = legacy.lab.test
issuer=CN = LabEx Training Issuing CA
notBefore=...
notAfter=...
X509v3 Subject Alternative Name:
DNS:legacy.lab.test
Альтернативное имя субъекта (SAN) перечисляет допустимые имена хостов. issuer обозначает подписавший CA; даты ограничивают срок действия. При подготовке создаются новые сертификаты для этой VM: конечные сертификаты действуют 365 дней. Верная дата не компенсирует неверное имя.
Перейдите в Server. openssl x509 -in читает локальный сертификат вместо сетевого ответа:
openssl x509 -in certs/help.crt -noout -subject -issuer -dates -ext subjectAltName
Его SAN — DNS:help.lab.test, что совпадает с запросом. Предусмотрены следующие связи:
| Элемент | Назначение |
|---|---|
help.crt и help.key |
Сертификат справки и соответствующий закрытый ключ |
docs.crt и docs.key |
Сертификат документации и соответствующий закрытый ключ |
issuing.crt |
Промежуточный CA, подписавший оба сайта |
../client/root.crt |
Корневой CA, которому доверяет клиент |
Цепочка: сертификат сайта → промежуточный CA → доверенный корневой CA. Nginx должен сначала отправлять конечный сертификат, затем промежуточный. Клиент уже доверяет корню, отправлять его необязательно. Соберите публичный набор командой cat; > записывает вывод в файл, заменяя прежнее содержимое. Закрытый ключ в этот набор не входит.
cat certs/help.crt certs/issuing.crt > certs/help-fullchain.pem
openssl verify проверяет набор относительно указанного доверенного корня. -untrusted предоставляет промежуточные сертификаты как возможные звенья, а не дополнительные доверенные корни; -verify_hostname проверяет нужное имя.
openssl verify -CAfile ../client/root.crt -untrusted certs/help-fullchain.pem -verify_hostname help.lab.test certs/help-fullchain.pem
certs/help-fullchain.pem: OK
При ошибке проверьте порядок входных файлов и написание имён, затем повторите cat. Это проверяет подготовленный набор; работающий сервер ещё должен начать его использовать.
Применить личность сайта справки
На этом шаге настройте выдачу правильной личности Nginx, сохранив работу сайта статуса. В Server покажите конфигурацию через cat:
cat conf/help.conf
server_name выбирает сайт. ssl_certificate указывает публичную цепочку, ssl_certificate_key — закрытый ключ. Пути с /tls/ находятся внутри подготовленного контейнера Nginx и соответствуют местному certs/. Строка return 200 выдаёт настоящее учебное содержимое справки. Сохраните слушатель, имя и ответ.
Откройте файл текстовым редактором nano:
nano conf/help.conf
Стрелками найдите две директивы TLS. Замените только эти две строки:
ssl_certificate /tls/help-fullchain.pem;
ssl_certificate_key /tls/help.key;
Точки с запятой завершают директивы Nginx. Сохраните через Ctrl+O, нажмите Enter, выйдите через Ctrl+X. При опечатке в пути снова откройте этот файл и исправьте её.
sudo запускает команду с административными правами. docker exec https-edge выполняет следующую команду внутри подготовленного контейнера службы. nginx -t проверяет конфигурацию, не применяя её:
sudo docker exec https-edge nginx -t
Найдите syntax is ok и test is successful. При ошибке сначала исправьте указанные файл и строку. nginx -s reload просит работающую службу перечитать проверенную конфигурацию:
sudo docker exec https-edge nginx -s reload
Переключитесь в Client и повторите нужный запрос. Перезагрузка конфигурации может занять мгновение; повторите запрос, если ещё виден старый сертификат.
curl --noproxy '*' --fail --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
help service: training content available
Сохраните и нормальную работу эталонного сайта:
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 https://status.lab.test:8443/
Успех означает проверку реальных имени, цепочки и срока действия до принятия ответа справки. Редактирование неиспользуемого сертификата такого результата не даст.
Исправить отсутствие промежуточного сертификата
На этом шаге отличите неполную цепочку от уже исправленного несовпадения имени. В Client запросите подготовленный сайт документации. Эта ошибка ожидается:
curl --noproxy '*' --cacert root.crt --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
curl: (60) SSL certificate problem: unable to get local issuer certificate
...
В обоих случаях код завершения 60; читайте сопровождающее объяснение. Исследуйте выдаваемый сертификат той же формой команды:
openssl s_client -connect 127.0.0.1:8443 -servername docs.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Теперь SAN — DNS:docs.lab.test. Имя верное, но Nginx отправляет только конечный сертификат: клиент не может связать его издателя с корнем.
Для одного контролируемого сравнения -k отключает проверку сертификата. Это показывает, что содержимое доступно даже при нарушенном доверии:
curl --noproxy '*' -k --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
Получение docs service: training content available здесь не является исправлением. Вернитесь в Server, просмотрите активный файл и откройте его:
cat conf/docs.conf
nano conf/docs.conf
Подготовленный docs-fullchain.pem уже содержит конечный и промежуточный сертификаты в нужном порядке. Замените только строку ssl_certificate:
ssl_certificate /tls/docs-fullchain.pem;
Оставьте /tls/docs.key закрытым ключом. Сохраните и выйдите, как прежде, затем проверьте и перечитайте настройки:
sudo docker exec https-edge nginx -t
sudo docker exec https-edge nginx -s reload
В Client запросите все три предусмотренных имени без -k. Цикл последовательно присваивает значения переменной host; $host подставляет значение, двойные кавычки сохраняют целостность каждого аргумента.
for host in help docs status; do
curl --noproxy '*' --fail --cacert root.crt --resolve "$host.lab.test:8443:127.0.0.1" "https://$host.lab.test:8443/"
done
Ожидаются три соответствующих ответа службы. Можно обновить HTTPS Monitor и сравнить независимые живые проверки. Исправляйте ошибку в нужной конфигурации, тестируйте и перечитывайте её; не меняйте клиентский корень доверия или ожидаемые имена. В реальных развёртываниях получайте утверждённые сертификаты через процесс вашей организации; здесь даны синтетические кандидаты, чтобы сосредоточиться на диагностике.
Резюме
Вы получили доверенный эталон, исследовали реальные имена и издателей сертификатов, собрали конечный и промежуточный сертификаты и применили их проверенным перечитыванием Nginx. Вы исправили несовпадение имени и неполную цепочку, сохранив нормальную работу. Следующее испытание объединяет эти решения для другого портала.
