Восстановить доступ к сайту справки с проверкой HTTPS-сертификата

Введение

Команда поддержки развернула сайт справки, но клиенты отклоняют HTTPS-соединение. HTTPS использует TLS для шифрования трафика и подтверждения личности ответившего сервера. Одного шифрования недостаточно: клиент также должен распознать запрошенное имя и доверять издателю сертификата.

Вы исправите синтетические учебные сертификаты на настоящем сервере Nginx. Достаточно базового владения терминалом; проверка сертификатов и настройка службы объясняются здесь. Client и Server — отдельные сеансы и каталоги одной VM, а не разные компьютеры. Nginx работает в подготовленном контейнере. Необязательный HTTPS Monitor показывает реальные внутренние TLS-проверки; значок замка браузера относится к другому, внешнему соединению.

Получить доверенный эталонный документ

На этом шаге получите документ работающей службы, затем сравните её с неисправным сайтом справки. Имя хоста обозначает запрашиваемую службу. Все учебные имена оканчиваются на .lab.test и действуют только в этом упражнении.

Чтобы начать этот шаг, выберите вкладку Client в интерфейсе лабораторной работы.

Используйте вкладку Client. curl получает содержимое URL. --cacert root.crt доверяет предоставленному центру сертификации (CA), подписывающему сертификаты. Это учебная точка доверия, а не общедоступный CA. --resolve сопоставляет имя и порт с IP-адресом, сохраняя имя для TLS и HTTP. 127.0.0.1 обозначает эту VM; порт 8443 ведёт к подготовленному Nginx. --noproxy '*' отправляет запрос напрямую; кавычки запрещают оболочке раскрывать *. --fail считает HTTP-ошибки неудачей, а --output сохраняет настоящий документ службы для дальнейшего использования.

Перед выполнением следующей команды перейдите на вкладку Client.

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 проверяло бы другую идентичность. Перейдите на вкладку HTTPS Monitor, чтобы увидеть независимые проверки: эталон успешен, запросы help и docs не проходят. Эта веб-страница служит монитором; дальнейшую работу в терминале выполняйте только после выбора указанной вкладки терминала.

HTTPS Monitor отличает работающий эталон от неудачных проверок сертификатов

Исследовать и собрать цепочку сертификатов

На этом шаге сравните выдаваемую сервером личность с подготовленным сертификатом и создайте пригодный серверный набор. Сертификат содержит открытый ключ и сведения о личности. Соответствующий закрытый ключ остаётся на сервере. Никогда не вставляйте его в отчёт и не отправляйте клиентам.

Чтобы начать этот шаг, выберите вкладку Client в интерфейсе лабораторной работы.

Перейдите на вкладку Client. Изучите фактически выдаваемый сертификат. openssl s_client открывает TLS-соединение; -connect задаёт адрес, а -servername передаёт запрошенное имя через Server Name Indication (SNI), позволяя одному слушателю Nginx обслуживать несколько сайтов. < /dev/null завершает интерактивный ввод. 2>/dev/null скрывает диагностику соединения только для этого просмотра. Канал | передаёт сертификат в openssl x509; -noout подавляет закодированный сертификат, остальные параметры показывают выбранные поля. Сам по себе этот просмотр не доказывает доверие.

Перед выполнением следующей команды перейдите на вкладку Client.

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 читает локальный сертификат вместо сетевого ответа:

Перед выполнением следующей команды перейдите на вкладку Server.

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:

Чтобы начать этот шаг, выберите вкладку Server в интерфейсе лабораторной работы.

Перед выполнением следующей команды перейдите на вкладку Server.

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 и повторите требуемый запрос. Перезагрузка конфигурации может занять некоторое время; повторите тот же запрос, если ещё виден старый сертификат.

Перед выполнением следующей команды перейдите на вкладку 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 запросите подготовленный сайт документации. Эта ошибка ожидается:

Чтобы начать этот шаг, выберите вкладку Client в интерфейсе лабораторной работы.

Перед выполнением следующей команды перейдите на вкладку 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, изучите действующий файл, затем откройте его:

Перед выполнением следующей команды перейдите на вкладку 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 подставляет его, а двойные кавычки сохраняют каждый полученный аргумент целиком.

Перед выполнением следующей команды перейдите на вкладку Client.

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 и обновить страницу для сравнения независимых проверок. Если проверка не проходит, вернитесь на вкладку Server, исправьте соответствующую конфигурацию, проверьте её и перезагрузите Nginx. Затем перейдите на вкладку Client и повторите запросы с проверкой; не меняйте корень доверия клиента или требуемые имена узлов. В реальных развёртываниях получайте утверждённые сертификаты по процедуре своей организации; здесь подготовлены синтетические варианты, чтобы сосредоточиться на диагностике.

HTTPS Monitor показывает успешные TLS-запросы с проверкой ко всем трём сервисам

Резюме

Вы получили доверенный эталон, исследовали реальные имена и издателей сертификатов, собрали конечный и промежуточный сертификаты и применили их проверенным перечитыванием Nginx. Вы исправили несовпадение имени и неполную цепочку, сохранив нормальную работу. Следующее испытание объединяет эти решения для другого портала.