Hello! On Mon, Apr 17, 2017 at 06:16:51PM +0500, Илья Шипицин wrote:
> 17 апреля 2017 г., 17:49 пользователь Maxim Dounin <[email protected]> > написал: > > > Hello! > > > > On Mon, Apr 17, 2017 at 03:48:00AM -0400, VVL wrote: > > > > > "будет использоваться для всех соединений в данном сервере" > > > Виртуальном сервере? В моей конфигурации для каждого виртуального хоста > > свой > > > stapling файл, при тестах сервер отвечает на все запросы. > > > > Речь про блок конфигурации server{}. > > > > > "использовать для получения OCSP-ответов для stapling'а сам nginx, он это > > > умеет" > > > Умеет, но к сожалению, ocsp-сервер не всегда отвечает. Именно поэтому > > > кэширую локально (скрипт не успокоится, пока не получит ответ и не > > обновит > > > файл). Или nginx тоже кэширует ответы? В каком случае они сбрасываются? > > > > Ответы кешируются в рамках рабочего процесса, и возвращаются > > клиентам вплоть до получения нового OCSP-ответа или истечения > > указанного в ответе срока годности. Соответственно, наиболее > > неприятный момент - это перезагрузка конфигурации в тот момент, > > когда OCSP-сервер не отвечает. > > > > Но вообще, если OCSP-сервер не всегда отвечает - это повод сменить > > CA. > > > > > "можно попробовать поднять локально OCSP-responder" > > > Задача к счастью намного (надеюсь) проще - получить минимальный и > > > гарантированный ответ при OCSP запросе. > > > > Что уж может быть проще, чем поднять proxy с кешированием. > > Впрочем, смотри выше про "сменить CA". > > > > Отмечу также в скобках, что OCSP stapling - это механизм > > оптимизации, позволяющий снять работу (точнее, часть работы) по > > получению OCSP-ответов с клиентов и переложить её на сервер. > > Странно ожидать от этого механизма гарантированности чего либо. > > > > > после массового выпуска сертификатов на Let's Encrypt > произошло вот такое > > https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/4 Спасибо, вдохновился: "our database was overloaded, and we use the same database to serve OCSP queries". Но, вроде, сейчас у них всё более или менее нормально. > и, собственно, > > "You may be interested to read these gists about the ways in which OCSP > stapling is implemented suboptimally in Apache and Nginx: > https://gist.github.com/AGWA/1de6c26be5396f7cbce7ee016302d68424 > <https://gist.github.com/AGWA/1de6c26be5396f7cbce7ee016302d684> and > https://gist.github.com/sleevi/5efe9ef98961ecfb4da8"; Когда ты CA, и у тебя "database was overloaded" - всё кажется "suboptimal". И очень хочется сделать OCSP stapling обязательным, а клиентов - вообще запретить, чтобы за OCSP ходить и не пытались. Но, к сожалению или к счастью, работает оно не так. Отмечу в скобках, что предложенное выше проксирование - в списке от Ryan Sleevi значится под номером 6, "Distributed or proxiable fetching". -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
