ssl renegotiation on nginx 1.13.+
Maxim Dounin
mdounin на mdounin.ru
Пн Сен 18 17:44:16 UTC 2017
Hello!
On Mon, Sep 18, 2017 at 07:53:34PM +0300, Mike Patutin wrote:
> Сертификаты я запрашиваю. Бекенд в разумных пределах может быть допилен.
> Моя проблема именно в железках, и именно в последовательности регистрации.
> Железка генерирует свой запрос сертификата и делает PUT на сервер с первым
> запросом, сервер ей генерирует сертификат по запросу и отдает его назад в
> ответе, после чего вызывает renegotiate.
> После этого творится некая магия в мозгах железки, и она начинает
> использовать свежий сертификат, полученный только что от сервера управления.
> Если renegotiate не происходит, железка по второму кругу отдает свой
> собственный сертификат и не считает себя зарегистрированной.
> Вот как то так. Уже неделю долблюсь в стену. Пока безуспешно. :(
Если железка хочет именно магическую последовательность событий -
то проще всего прокинуть соединение целиком с помощью модуля
stream, как тут уже предлагали. Адрес клиента при этом можно
прокинуть через PROXY protocol:
http://nginx.org/ru/docs/stream/ngx_stream_proxy_module.html#proxy_protocol
Ну или пытаться воспроизводить эту последовательность в рамках
nginx'а. На этом пути потребуется как минимум:
- выпилить детектирование renegotiation и последующее закрытие
соединений в src/event/ngx_event_openssl.c;
- как-то выбрать, в какой момент делать renegotiation; если
исходить из идеи, что надо делать renegotiation после возврата
ответа на запрос регистрации - то, видимо, проще всего сделать
body-фильтр, который включать в специальном location'е,
и там после отправки тела делать SSL_renegotiate().
Пытаться детектировать renegotiation с бекендом и как-то
транслировать его клиенту - я бы не рекомендовал, возни будет
много, а толку - чуть.
--
Maxim Dounin
http://nginx.org/
Подробная информация о списке рассылки nginx-ru