编辑:在解决了这个问题之后，似乎实际上是许多不同的问题都在有关Rsyslog的一些一般性问题下陷入了困境。
因此，对问题的更好的“TL; DR”摘要:“将Rsyslog与TLS一起使用会产生许多模糊/混淆的问题。如何使它起作用？”我的答案摘要如下。

原始帖子:

我一直在努力让rsyslog从客户端向服务器输出TLS，特别是在使用“指纹”或“证书有效”模式时。

我有多台计算机，其中一台是用于通过端口11514上的TCP/TLS接收syslog数据的服务器。其余的计算机是发送TCP/TLS的客户端。所有证书都具有使用相同证书颁发机构签名的证书(其密钥存储在其他位置)。这些计算机未直接连接到公用IP地址，并且没有DNS条目。

根据适用于哪个平台的版本(从7.6到8.4)，即使试图在所有机器之间共享相似的配置，不同的机器也会表现出不同的行为。 gtls模块被证明是一个不断变化的麻烦，因为对于每台机器，它都会以奇怪的，不同的方式出错。根据配置行的顺序，或者我使用的是Rainer脚本样式还是传统的样式，或者是否在证书的CN中使用了机器的主机名，等等，等等，它可能会出错。

尽管没有很好地记录每种模式的确切细节(在查看像这样的稀疏解释之后:http://www.rsyslog.com/doc/ns_gtls.html)，但我选择不使用“x509/name”，因为它似乎对我没有任何作用。除非我没有记错，否则“x509/name”将服务器上安装的计算机证书的CN与PermittedPeers中的内容匹配。但是，与所有示例相反，我的机器没有DNS条目，因此证书的CN完全是任意的。 (但是，对于最后一台计算机的配置，gtls继续失败，直到我使CN匹配我的主机名为止。巧合还是发生了什么...？)

我只希望每台机器上的签名证书相互验证(因为它们是相同的签名证书，以及我使用“x509/certvalid”的原因)。如果可以，我也不反对通过证书指纹进行验证(或者找到有关如何使用的文档)。

在我的最后一台计算机上，我收到一条错误消息，说远程主机的名称(rsyslog服务器)与允许的对等主机不匹配。我不知道为什么它甚至需要“x509/certvalid”。然后，我尝试将服务器证书的指纹添加到允许的对等方(以我对预期格式的最佳猜测，带或不带冒号“:”或“SHA1:”)。所有人都以同样的方式失败了，我不知道为什么。

可能值得注意的是，在我必须更换所有机器上的所有证书(使用我一直使用的相同方法:http://www.rsyslog.com/doc/tls_cert_machine.html)之前，在此机器上进行的此设置实际上已经起作用。然后发生了一系列荒谬的故障:无法加载gtls，无法使用旧样式的新样式action(type="omfwd"...)等使用Legacy选项，而service rsyslog restart，systemctl restart rsyslog和kill -HUP $(pidof rsyslog)都挂起或处于奇怪的不同状态。经过最后的配置优化和完整的计算机重新启动(嘘，不确定这是否是systemd问题还是其他问题...)，我被允许从此客户端生成对等错误...

客户端计算机的rsyslog版本:

rsyslogd 8.4.2, compiled with:
    FEATURE_REGEXP:                         Yes
    GSSAPI Kerberos 5 support:              Yes
    FEATURE_DEBUG (debug build, slow code): No
    32bit Atomic operations supported:      Yes
    64bit Atomic operations supported:      Yes
    memory allocator:                       system default
    Runtime Instrumentation (slow code):    No
    uuid support:                           Yes
    Number of Bits in RainerScript integers: 64

$DefaultNetstreamDriverCAFile /folder/ca_cert.pem
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /folder/ca_cert.pem
$DefaultNetstreamDriverCertFile /folder/client1_cert.pem
$DefaultNetstreamDriverKeyFile /folder/client1_key.pem
$ActionSendStreamDriverAuthMode x509/certvalid
$ActionSendStreamDriverMode 1
...
ruleset(name="forwardtls") {
    action(type="omfwd" target="192.168.1.1" port="11514" protocol="tcp"
      ResendLastMSGOnReconnect="on" StreamDriverMode="1"   
      StreamDriverAuthMode="x509/certvalid" 
      StreamDriverPermittedPeers="SHA1:AA:BB:CC:11:22:33:44:55:66:77:88:99:11:22:33:44:55:66:77:88")
}
*.* call forwardtls

Feb  7 23:59:35 client2 rsyslogd-2087: authentication not supported by  gtls netstream driver in the configured authentication mode - ignored [try http://www.rsyslog .com/e/2087 ]
Feb  7 23:59:35 client2 rsyslogd-2007: action 'action 1' suspended, next retry is Wed Feb 10 00:00:05 2016 [try http://www.rsyslog .com/e/2007 ]
Feb 8 00:00:01 client2 rsyslogd-2088: error: peer name not authorized -  not permitted to talk to it. Names: CN: server1;  [try http://www.rsyslog .com/e/2088 ]

$ModLoad imtcp
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /folder/ca_cert.pem
$DefaultNetstreamDriverCertFile /folder/server1_cert.pem
$DefaultNetstreamDriverKeyFile /folder/server1_key.pem
$InputTCPServerStreamDriverAuthMode x509/certvalid
$InputTCPServerStreamDriverMode 1
$InputTCPServerRun 11514

最佳答案

谁都可以猜到，这个“问题”远不止是“有效对等”错误。不幸的是，实际的解决方案将非常特定于发行版，发行版，rsyslog版本以及许多其他不一致的内容，因此没有快速的答案就足够了。

经过无休止的挣扎和盯着这个问题，没有答案(代替了一个过于笼统的“元”答案)，这就是我所发现的...

如果计划将Rsyslog与TLS一起使用，则应首先考虑以下几件事:系统有多旧或多旧，以及对故障有多大的耐心。如果需要立即运行，请准备更改某些计划。

首先，大多数发行版是第一个问题。如果要将RELP与Rsyslog的TLS一起使用，则至少需要Rsyslog 7.5版。某些发行版(尤其是基于RedHat的发行版)仅具有7.4版。甚至更旧的基于Debian的LTS发行版也没有足够的最新版本来完全支持Rainer脚本。是否想知道一切所需的特定版本？开始浏览变更日志或其他沮丧的论坛帖子。

不要期望文档会告诉您所需的一切。尽管通常情况很好，但是在线文档有时还是不对的。 (例如，“omrelp”模块显示TLS指纹的确切格式，但是带TLS的纯“tcp”没有；“omrelp”具有Rainer脚本格式的示例，而带TLS的纯“tcp”没有)

预计故障排除会很痛苦。不幸的是，Rsyslog将GnuTLS集成到了所有内容中，但还会将日志消息推送到GnuTLS。根据它在创建TCP连接，进行身份验证，确定适当的加密等过程中所处的位置，它将生成非常不透明的GnuTLS错误代码(当您查找它们或天真地寻找答案时，它通常只会使您误解为REAL问题GnuTLS源代码中的代码)和在线引用网址(可能有也可能没有简短，含糊的任何有用信息的引用)。

有时rsyslog会告诉您该连接不是来自授权的对等方。有时不会。我遇到了许多“GnuTLS错误代码-110”，其原因包括僵尸TCP套接字到在配置中错误键入文件名。这些代码几乎没有用。更糟糕的是，某些客户端安装程序不会对错误进行任何说明，因为它会默默地不记录rsyslog服务启动之后的任何内容(并且还会破坏其他服务，可能是那些触及相同unix套接字的服务，尽管我不确定)。

旧的发行版将使您痛苦。使用不同版本的Rsyslog的不同发行版也会导致非常不同的结果。例如，在最近的Debian构建(带有Systemd)上，运行“service rsyslog stop”将正常停止它，但是“systemctl stop rsyslog”将“停止”服务，但是rsyslogd进程可能仍在后台运行。哎呀如果尝试重新启动rsyslog进程，则服务器与客户端之间的TCP session 很多时候都不会关闭(FIN)，从而导致新进程失败。

但是，不要期望其中的任何一个都会被“-N”选项所吸引(因为它仅在语法上始终有效)。

调整配置的最佳建议:通过对配置进行三次检查(包括所有文件名和任何指定文件名的权限)来弄清楚自己，停止服务，终止进程，等待几分钟让任何TCP session 超时，然后重试。否则，您可能正在具有旧配置和无效套接字的旧进程之上运行新服务。

如果要从rsyslog存储库(“adiscon”)安装，以获取最新的relp，Rainer脚本等，它可能会很好地工作，或者您可能还会遇到上述问题以及其他问题。在Ubuntu安装中，将rsyslog，rsyslog-relp和rsyslog-gnutls分为单独的软件包，有人决定重叠核心文件，从而有效地中断了安装。 (为什么几个月前没有注意到这个问题？)

在某些安装中，一切都会在第一次正常运行。在某些安装中，您将用力敲键盘。

备择方案:

-将RELP或普通UDP syslog与隧道或 sslwrap 或类似版本结合使用。最好使用指向您本地TLS隧道端口的RELP。这样，如果您的隧道发生故障(分别来自Rsyslog)，它可以将日志排队直到固定(在队列填充之前 swift )。

-使用syslog-ng。如果您在一开始遇到足够的痛苦，为什么不尝试一个完整的替代方法...

关于linux - rsyslog x509/certvalid需要允许的同级，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35307954/