Hello!

On Mon, Apr 17, 2017 at 06:16:51PM +0500, Илья Шипицин wrote:

> 17 апреля 2017 г., 17:49 пользователь Maxim Dounin <mdounin@mdounin.ru>
> написал:
>
> > 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
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru