OCSP stapling (пристёгивание OCSP) — расширение TLS-хендшейка, позволяющее серверу включать заранее полученный подписанный ответ OCSP (Online Certificate Status Protocol) непосредственно в TLS-соединение. Без stapling браузер самостоятельно запрашивает OCSP-сервер CA для проверки отзыва сертификата — это добавляет дополнительный DNS-запрос и HTTP-запрос к CA при каждом соединении, а также раскрывает CA информацию о том, какие сайты посещает пользователь.
Как работает
Традиционный OCSP (RFC 2560, 1999): браузер при подключении к серверу делает HTTP-запрос к OCSP Responder CA для проверки статуса SSL-сертификата (good/revoked/unknown). Проблемы: задержка 20-100 мс, зависимость от доступности OCSP-сервера CA, слежка за пользователями.
OCSP stapling (RFC 6066, 2011): сервер nginx/Apache сам периодически запрашивает OCSP Responder и кэширует ответ (обычно 24-48 часов). При TLS-хендшейке сервер прикладывает этот ответ к сертификату — браузер получает подтверждение отзыва без внешнего запроса. Ответ OCSP подписан CA — клиент проверяет подпись локально.
Настройка в nginx:
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
ssl_trusted_certificate /path/to/chain.pem;OCSP Must-Staple
Расширение X.509-сертификата, указывающее браузеру отказывать в соединении, если сервер не предоставил OCSP stapling ответ. Значительно снижает риск атак типа «soft-fail» (когда браузер игнорирует недоступность OCSP и продолжает соединение). Let's Encrypt не поддерживает Must-Staple; DigiCert и Comodo — поддерживают. Certbot позволяет запросить сертификат с Must-Staple флагом через параметр --must-staple.
История
OCSP определён в RFC 2560 (1999). Certificate Revocation Lists (CRL) появились ещё в RFC 1422 (1993) как первый механизм отзыва. OCSP stapling стандартизован в RFC 6066 (2011) как расширение TLS. Браузеры (Chrome, Firefox) отказались от принудительных OCSP-проверок в 2012-2013 годах (слишком медленно при недоступном OCSP), что сделало stapling основным механизмом проверки актуального статуса сертификата.
OCSP: настройка Must-Staple и мониторинг
OCSP Must-Staple (RFC 7633) — расширение X.509, требующее от TLS-клиента проверки OCSP-ответа. Если сервер не предоставляет staple — соединение должно быть отклонено (при строгой интерпретации). Включается при выпуске сертификата у CA с поддержкой Must-Staple (Let's Encrypt поддерживает через --must-staple в certbot). Защита от атак с компрометированным сертификатом без staple.
Мониторинг OCSP stapling: curl -vI https://example.com 2>&1 | grep -i ocsp — ответ "OCSP response: good" подтверждает корректную работу. openssl s_client -connect example.com:443 -status — детальная информация о OCSP staple. Ошибка "OCSP stapling not supported" — nginx не смог получить OCSP-ответ от CA. Решение: проверить доступность OCSP responder URL (из openssl x509 -noout -ocsp_uri -in cert.pem), добавить resolver 8.8.8.8 в nginx.conf для резолвинга OCSP endpoint.
На что обращать внимание
OCSP stapling включается на уровне веб-сервера, а не CA. Без корректного ssl_trusted_certificate nginx не сможет проверить ответ CA. Проверить работу stapling: openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 17 'OCSP response'. Если ответ no response sent — stapling не работает. Для Wildcard и Let's Encrypt сертификатов OCSP stapling настраивается одинаково.
Типичные проблемы
OCSP stapling не работает — первая причина: отсутствует ssl_trusted_certificate с промежуточными сертификатами (цепочкой сертификатов). nginx не может проверить OCSP-ответ и отключает stapling молча. Вторая: OCSP Responder CA недоступен с вашего сервера (блокировка по IP, rate limit). Решение — настроить resolver и убедиться, что сервер имеет доступ к CA OCSP URL. Для HTTPS-сайтов на shared hosting OCSP stapling обычно настраивается на уровне хостинг-провайдера автоматически.