title: rsyslog x509/certvalid requiring permitted peer
body: <p><strong>EDIT:</strong> After battling with this issue, it seems to be actually be many different issues all glomming together under some general issues regarding Rsyslog.
   So a better "TL;DR" summary of the problem: "Many vague/conflated problems arise from using Rsyslog with TLS. How can I make it work?"  My answer summary is below.</p>
  
  <hr>
  
  <p>ORIGINAL POST:</p>
  
  <p>I have been struggling with getting <code>rsyslog</code> to output TLS from a client to a server, specifically while using the "fingerprint" or "certvalid" modes.</p>
  
  <p>I have multiple machines, one of which is the server to receive the syslog data over TCP/TLS on port 11514. The rest of the machines are clients sending the TCP/TLS. All have certs signed with the same Certificate Authority (whose key is stored elsewhere). These machines are NOT attached directly to public IP addresses and do NOT have DNS entries.</p>
  
  <p>Depending on what version was available for which platform (ranging from 7.6 to 8.4), different machines would exhibit different behavior even when trying to share the similar configs among them all. The <code>gtls</code> module proved a constant, fickle hassle as it would error out in odd, different ways for each machine. It might error out depending on the order of configuration lines or if I used Rainer-script style or used Legacy style or used the machine's hostname in the cert's CN or didn't, etc, etc, etc.</p>
  
  <p>Although, the exact specifics of what each mode does is not well documented (after looking at sparse explanations like this: <a href="http://www.rsyslog.com/doc/ns_gtls.html" rel="nofollow">http://www.rsyslog.com/doc/ns_gtls.html</a>), I am choosing not to use "x509/name" because it doesn't seem to serve any purpose for me. Unless I am mistaken "x509/name" matches the CN of the machine cert installed on the server to whatever is in <code>PermittedPeers</code>. However, contrary to all the examples, my machines do not have DNS entries, hence the cert's CN is entirely arbitrary. (However, for this last machine's config, gtls continued to fail until I made the CN match my hostname. Coincidence or what's going on...?)</p>
  
  <p>I just want the signing certs on each machine to be verified against each other (since they are the same signing cert and the reason I'm using "x509/certvalid"). I am not opposed to getting verification by certificate fingerprint, also, if I could ever get it to work (or find documentation on exactly how).</p>
  
  <p>On my last machine, I am getting an error saying that the remote host's name (the rsyslog server) does not match the permitted peers. <i>Why</i> it even <i>needs</i> that for <b>"x509/certvalid"</b>, I do not know. I then tried adding the server cert's fingerprint to permitted peers (in my best guesses for the expected format, with or without colons, ":", or "SHA1:"). All failed the same way and I cannot figure out why.</p>
  
  <p>It may be worth noting, this setup on THIS machine actually worked before I had to change out all the certs on all the machines (using the same method that I always use: <a href="http://www.rsyslog.com/doc/tls_cert_machine.html" rel="nofollow">http://www.rsyslog.com/doc/tls_cert_machine.html</a>). Then a series of ridiculous failures followed: failed to load gtls, failed to use the Legacy options with the new style <code>action(type="omfwd"...)</code>, etc,etc, with <code>service rsyslog restart</code>, <code>systemctl restart rsyslog</code> and <code>kill -HUP $(pidof rsyslog)</code> all hanging or leaving it in odd different states. After a final config polish and a full machine restart (boo, not sure if this is a systemd problem or something else...), I was left with a permitted peer error generated from this client...</p>
  
  <p>The client machine's rsyslog version:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>Snippet of the client machine's <code>rsyslog.conf</code>:</p>
  
  <pre><code>$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
  </code></pre>
  
  <p>Client machine's error:</p>
  
  <pre><code>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 ]
  </code></pre>
  
  <p>Snippet of server machine's rsyslog.conf:</p>
  
  <pre><code>$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
  </code></pre>