Попытка настроить TLS на сервере Rsyslog, s_client подключается, но не получает сертификаты, зависает

Я пытаюсь настроить TLS на сервере rsyslog, используя различные руководства, включая официальные документы rsyslog: http://www.rsyslog.com/doc/v8-stable/tutorials/tls.html.

Я запускаю rsyslog-8.33.1 вместе с той же версией rsyslog-gnutls. ОС — amazon linux v2017.09 на ec2.

Поскольку конкретный клиент системного журнала, который я использую, не работает с самозаверяющими сертификатами, я подписываюсь с ЦС нашего домена. Я настроил ключ, сертификат и захватил цепочку ЦС (поскольку в корне есть промежуточные сертификаты) и настроил rsyslog.conf, как мне говорят многие учебники:

# RsyslogGnuTLS
$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile /etc/pki/tls/CA-chain.crt
$DefaultNetstreamDriverCertFile /etc/pki/tls/<hostname>.crt
$DefaultNetstreamDriverKeyFile /etc/pki/tls/<hostname>.key
$ActionSendStreamDriverMode 1 # TLS mode only
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer *
$InputTCPServerRun 6514

И получил rsyslog для запуска без жалоб (после некоторого kerjigering).

Это хост ec2 с портом 6514, открытым для всего мира. Теперь я тестирую с помощью openssl s_client и не могу получить сертификаты с машины.

[me@my_host ~]$ openssl s_client -connect ec2-<ip>.us-west-2.compute.amazonaws.com:6514
CONNECTED(00000003)

(hangs)

... и он висит там безучастно навсегда, пока я не убью сервер rsyslog, после чего он выдает ошибку с «нет доступного однорангового сертификата».

Я знаю, что сервер rsyslog работает. Он получает журналы 6514 от клиента системного журнала, когда TLS отключен с обеих сторон.

Я пробовал почти все комбинации переменных в rsyslog.conf, и я в отчаянии. Я также пытался использовать пакет cert/key/CA в /etc/pki/tls/certs, который поставляется с машиной, без игры в кости.


person lowly_junior_sysadmin    schedule 14.03.2018    source источник


Ответы (1)


Выяснилось, что я использовал неправильные переменные - переменные на стороне клиента вместо переменных на стороне сервера, которые выглядят одинаково на концах. я должен был использовать

$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *
$InputTCPServerStreamDriverMode 1

на сервере вместо

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer *
$ActionSendStreamDriverMode 1. 

Просто надо было посмотреть свежим взглядом.

person lowly_junior_sysadmin    schedule 16.03.2018