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