OCSP response: no response sent — что проверить в nginx

При проверке HTTPS команда OpenSSL вывела OCSP response: no response sent, хотя сайт открывается. Это означает, что сервер не приложил OCSP-ответ к этому TLS-соединению. Само сообщение не доказывает ни отзыв сертификата, ни поломку HTTPS.

Сначала проверьте, предусмотрен ли OCSP для выданного сертификата и требует ли клиент stapling. Если такой обязанности нет, отсутствие ответа может быть нормальным. Если stapling нужен, проверять следует тот узел, который завершает TLS: nginx, балансировщик или CDN.

1. Отделите stapling от проверки сертификата

OCSP сообщает о статусе отзыва сертификата. При stapling сервер получает подписанный ответ центра сертификации и передаёт его клиенту вместе с TLS-рукопожатием. Это отдельный механизм от проверки имени домена, срока действия и цепочки доверия.

Для публичного домена выполните команду в терминале с OpenSSL 3.x, заменив example.com своим именем:

openssl s_client -connect example.com:443 \
  -servername example.com -status \
  -verify_hostname example.com -verify_return_error </dev/null

Параметр -status запрашивает stapling, а -servername передаёт SNI — имя сайта, по которому сервер выбирает сертификат. Проверка без нужного имени может попасть в другой виртуальный хост.

Читайте результаты раздельно:

• no response sent — stapled-ответ не получен;
• ошибка проверки имени, срока или доверия — самостоятельная проблема TLS;
• Verify return code: 0 (ok) — пройдены настроенные проверки сертификата в этой среде, но это не отдельное доказательство отсутствия отзыва.

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

2. Посмотрите OCSP URL и Must-Staple

Экспортируйте именно предъявленный сайтом сертификат домена в PEM-файл site.pem, без закрытого ключа. Важно исследовать сертификат из соединения, а не только новый файл в панели хостинга.

openssl x509 -in site.pem -noout -issuer -dates -ocsp_uri
openssl x509 -in site.pem -noout -ext tlsfeature

По документации OpenSSL, -ocsp_uri выводит адрес OCSP responder, если он есть. Отсутствие строки с OCSP-адресом при успешном чтении файла означает, что такого адреса в сертификате нет; ошибка чтения требует сначала исправить формат или путь.

OCSP URL нет, Must-Staple нет

Сверьте политику своего центра сертификации. Например, Let’s Encrypt закрыл OCSP-сервис и публикует сведения об отзыве через CRL — списки отозванных сертификатов. Его текущие сертификаты не содержат OCSP URL, поэтому ожидать stapling по старой инструкции не следует.

Не подставляйте адрес чужого responder и не считайте CRL «ответом для stapling»: это разные способы распространения сведений об отзыве.

Есть TLS Feature: status_request

Это признак OCSP Must-Staple. RFC 7633 позволяет сертификату требовать stapled-ответ; клиент, который применяет это требование, может отклонить соединение без него.

В такой ситуации обычное открытие сайта в одном браузере недостаточно. Нужны рабочий stapling на всех обслуживающих узлах либо согласованный с центром сертификации перевыпуск без требования, которое инфраструктура не выполняет.

3. Если OCSP поддерживается, проверьте nginx по порядку

Начните с журнала ошибок нужного виртуального хоста и времени неудачной проверки. Не меняйте сразу несколько TLS-настроек: иначе будет трудно понять причину.

1. Где завершается TLS? Для сайта за CDN внешний тест видит сертификат CDN. Изменение nginx на origin не исправит stapling на внешнем узле.
2. Включён ли механизм? В нужном блоке server проверьте ssl_stapling. По умолчанию в nginx он выключен.
3. Известен ли издатель? Для stapling nginx нужен сертификат издателя: в цепочке ssl_certificate либо в ssl_trusted_certificate. При ssl_stapling_verify on нужен соответствующий набор доверенных корневых и промежуточных сертификатов.
4. Доступен ли responder с сервера? Проверьте DNS, настроенный resolver и исходящее соединение к OCSP-адресу. Успешная проверка с ноутбука не подтверждает доступ с хостинга.

Требования к этим директивам описаны в документации nginx. Директива ssl_ocsp относится к проверке клиентских сертификатов и не заменяет ssl_stapling для сертификата сайта.

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

4. Подтвердите результат на каждом узле

После изменения конфигурации выполните nginx -t. При успешной проверке примените штатную для вашего сервера перезагрузку конфигурации и повторите внешний тест, сохраняя правильный SNI.

Сравните каждый обслуживающий IPv4/IPv6-адрес и узел балансировщика: сертификат, наличие ответа, а при полученном OCSP-ответе — статус сертификата и сроки This Update / Next Update. Строка OCSP Response Status: successful сообщает об обработке OCSP-запроса; отдельно нужен статус самого сертификата, например good.

Критерий завершения зависит от ветки: либо подтверждено, что stapling здесь не предусмотрен и не требуется, либо все нужные узлы отдают пригодный ответ. Разовый тест не подтверждает стабильность во времени.

Web-Puls помогает регулярно контролировать доступность сайта и срок сертификата; это дополняет диагностику, но не заменяет проверку OCSP и Must-Staple.

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