Configure secure logging with rsyslog TLS to remote log server (CentOS/RHEL 7)

In my last article I shared the steps to securely transfer files between two machines using HTTPS. Now I will share the steps to configure secure logging with rsyslog to remote log server using TLS certificates in CentOS/RHEL 7 Linux. This document describes a secure way to set up rsyslog (TLS certificates) to transfer logs to remote log server. A secure logging environment requires more than just encrypting the transmission channel. Below are some of the security benefits with secure remote logging using TLS

• syslog messages are encrypted while travelling on the wire
• the syslog sender authenticates to the syslog receiver; thus, the receiver knows who is talking to it
• the syslog receiver authenticates to the syslog sender; thus, the sender can check if it indeed is sending to the expected receiver
• the mutual authentication prevents man-in-the-middle attacks

Why do I need secure logging to remote log server?

I had already written an article to perform logging on remote log server using rsyslog over TCP protocol, but even if you are using TCP for sending log messages to a remote server, there's no encryption or anything applied while the message is in transit, and that might not be acceptable. If your organisation needs a higher level of security, you need to set up secure logging to remote log server. Secured remote logging is going to use TLS.

My Setup:

• I will use two different nodes to demonstrate secure logging to remote log user using rsyslog with TLS certificates i.e. node2 and node3.
• Both the nodes are installed with CentOS 7.4 Linux. In this article node2 will act as a client which will forward the rsyslog messages to node3 (remote log server).
• So node2 will be our client and node3 will act as the remote log server.

[root@node2 ~]# systemctl status chronyd

[root@node2 ~]# date
Tue Apr 16 14:10:12 IST 2019

[root@node3 ~]# systemctl status chronyd

[root@node3 ~]# date
Tue Apr 16 14:10:06 IST 2019

Generate CA certificates

To create a self-signed certificate for secure forwardof syslog to remote log server, we will use certtool which is part of GnuTLS. So let us first install GnuTLS rpm using yum.

[root@node2 ~]# yum -y install gnutls-utils

Generate the private key

[root@node2 ~]# certtool --generate-privkey --outfile ca-key.pem
Generating a 2048 bit RSA private key...

Check the new key which we have just created

[root@node2 ~]# ls -l
total 44
-rw-------. 1 root root 1899 Feb 17 17:45 anaconda-ks.cfg
-rw-------  1 root root 5813 Apr 16 14:12 ca-key.pem
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Desktop
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Documents
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Downloads
-rw-r--r--. 1 root root    0 Feb 17 17:48 initial-setup-ks.cfg
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Videos

This key needs the appropriate permissions to make it readable for the root user only

[root@node2 ~]# chmod 400 ca-key.pem

Now create the (self-signed) CA certificate itself. This command queries you for a number of things. Use appropriate responses. When it comes to certificate validity, keep in mind that you need to recreate all certificates when this one expires. So it may be a good idea to use a long period, eg. 3650 days (roughly 10 years). You need to specify that the certificates belongs to an authority. The certificate is used to sign other certificates.

[root@node2 ~]# certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Common name: node2.example.com
UID:
Organizational unit name:
Organization name:
Locality name:
State or province name:
Country name (2 chars):
Enter the subject's domain component (DC):
This field should not be used in new certificates.
E-mail:
Enter the certificate's serial number in decimal (default: 6680410231240074733):


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint): -1
Is this a TLS web client certificate? (y/N): n
Will the certificate be used for IPsec IKE operations? (y/N): n
Is this a TLS web server certificate? (y/N): n
Enter a dnsName of the subject of the certificate: node2.example.com
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Will the certificate be used to sign OCSP requests? (y/N): n
Will the certificate be used to sign code? (y/N): n
Will the certificate be used for time stamping? (y/N): n
Will the certificate be used to sign other certificates? (y/N): y
Will the certificate be used to sign CRLs? (y/N): y
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5cb595b602f325ed
        Validity:
                Not Before: Tue Apr 16 08:43:36 UTC 2019
                Not After: Fri Apr 13 08:43:44 UTC 2029
        Subject: CN=node2.example.com
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: Medium (2048 bits)
                Modulus (bits 2048):
                        00:b7:d6:0b:dd:52:72:77:87:d6:16:8d:c6:93:69:6b
                        23:19:65:3e:28:cf:63:72:39:11:98:d9:6c:51:fe:da
                        2f:f3:2c:52:24:37:79:b2:36:ce:cd:8e:a2:45:51:96
                        a0:03:ef:7f:9b:f5:7f:f4:67:2e:08:25:fb:0b:69:41
                        f8:7c:15:b7:44:3d:65:a0:c8:97:51:f2:5c:fb:4f:fb
                        db:5a:c0:db:d9:78:35:c4:01:dc:68:d4:d2:9f:9b:29
                        47:4c:6e:44:d2:f4:b8:b4:f7:0a:dd:1c:45:d3:32:c8
                        cf:86:50:c3:49:4d:0f:24:61:e4:a6:10:c5:6a:f2:58
                        84:f4:94:e3:9d:65:33:c2:36:60:30:f0:f7:7a:55:9a
                        68:d4:0b:62:59:4f:9b:a0:60:e2:78:b9:1e:90:a5:95
                        9a:e9:45:c0:ba:6f:4c:09:72:d8:b0:fb:3b:77:c7:a8
                        ee:75:6e:f8:96:24:8c:14:06:57:85:73:eb:d2:e9:d9
                        a2:9e:d6:17:c0:6c:ac:ba:2a:47:49:9d:df:35:4a:75
                        be:4c:68:4e:36:43:04:a7:7c:a2:47:5d:62:24:1b:00
                        a9:10:63:90:3e:b1:8a:5c:01:e5:ac:21:7b:5e:19:ab
                        4e:04:5c:82:00:7e:27:d6:31:66:db:c7:1f:53:32:9b
                        59
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                        Path Length Constraint: 0
                Subject Alternative Name (not critical):
                        DNSname: node2.example.com
                Key Usage (critical):
                        Certificate signing.
                        CRL signing.
                Subject Key Identifier (not critical):
                        951acec5fda12e4b438d10bb48a5ddcdea33a1f8
Other Information:
        Public Key ID:
                951acec5fda12e4b438d10bb48a5ddcdea33a1f8
        Public key's random art:
                +--[ RSA 2048]----+
                |        o        |
                |       + = =     |
                |      o = * + .  |
                |     . + B + o . |
                |      . S = o .  |
                |       . + o     |
                |      . . B .    |
                |       . . *     |
                |        E .      |
                +-----------------+

Is the above information ok? (y/N): y


Signing certificate...

Validate the newly created key.

[root@node2 ~]# ls -l
total 48
-rw-------. 1 root root 1899 Feb 17 17:45 anaconda-ks.cfg
-r--------  1 root root 5813 Apr 16 14:12 ca-key.pem
-rw-r--r--  1 root root 1143 Apr 16 14:16 ca.pem
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Desktop
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Documents
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Downloads
-rw-r--r--. 1 root root    0 Feb 17 17:48 initial-setup-ks.cfg
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Videos

Generate machine certificate

In this step, we generate certificates for each of the machines. Please note that both clients and servers need certificates. The certificate identifies each machine to the remote peer.
Here --outfile reflects the name of the server that's going to use the private key i.e. node3-key.pem for us. This way it is easier to identify the key and the mapped node name.

[root@node2 ~]# certtool --generate-privkey --outfile node3-key.pem --bits 2048
** Note: Please use the --sec-param instead of --bits
Generating a 2048 bit RSA private key...

The remote log server still is node3, and the signing requests is what it needs to get the certificate signed. So just the fact of having private key is not enough. It must be signed by a certificate authority. Here we are raising a request using certtool to load node3-key.pem private key and sign this private key into outfile i.e. node3-request.pem.

Now this will again prompt you with a bunch of questions, answer them appropriately based on your environment.

[root@node2 ~]# certtool --generate-request --load-privkey node3-key.pem --outfile node3-request.pem
Generating a PKCS #10 certificate request...
Common name: node3.example.com
Organizational unit name:
Organization name:
Locality name:
State or province name:
Country name (2 chars):
Enter the subject's domain component (DC):
UID:
Enter a dnsName of the subject of the certificate: node3.example.com
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): n
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): n
Will the certificate be used to sign code? (y/N): n
Will the certificate be used for time stamping? (y/N): n
Will the certificate be used for IPsec IKE operations? (y/N): n
Will the certificate be used to sign OCSP requests? (y/N): n
Is this a TLS web client certificate? (y/N): n
Is this a TLS web server certificate? (y/N): n

Now validate the node3-request.pem which we have created.

[root@node2 ~]# ls -l
total 60
-rw-------. 1 root root 1899 Feb 17 17:45 anaconda-ks.cfg
-r--------  1 root root 5813 Apr 16 14:12 ca-key.pem
-rw-r--r--  1 root root 1143 Apr 16 14:16 ca.pem
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Desktop
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Documents
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Downloads
-rw-r--r--. 1 root root    0 Feb 17 17:48 initial-setup-ks.cfg
-rw-------  1 root root 5826 Apr 16 14:18 node3-key.pem
-rw-------  1 root root 2513 Apr 16 14:20 node3-request.pem
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Videos

And after doing all this, the procedure of creating the key material for the RSA's log server, as well as client, is going to be complete. In here, the private key of the certificate authority is used to sign the certificates that is going to be used by node3, and that is what is going to make sure that node3 is going to be trusted by everyone involved.

[root@node2 ~]# certtool --generate-certificate --load-request node3-request.pem --outfile node3-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 6680412331704980564):


Activation/Expiration time.
The certificate will expire in (days): 1000


Extensions.
Do you want to honour the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: node3.example.com
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): n
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): n
Will the certificate be used to sign OCSP requests? (y/N): n
Will the certificate be used to sign code? (y/N): n
Will the certificate be used for time stamping? (y/N): n
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5cb5979f106a1454
        Validity:
                Not Before: Tue Apr 16 08:51:48 UTC 2019
                Not After: Mon Jan 10 08:51:53 UTC 2022
        Subject: CN=node3.example.com,DC=node3.example.com
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: Medium (2048 bits)
                Modulus (bits 2048):
                        00:a4:1d:87:b0:dd:6c:53:85:a7:3e:0d:93:18:d8:fc
                        9d:a4:c3:71:4d:c1:00:74:04:9f:42:e0:83:00:5a:f0
                        4d:9e:20:77:d3:6b:4e:1a:e5:fe:95:06:80:5d:48:33
                        30:0e:d9:15:72:5e:9c:c8:c2:f4:60:59:cb:f2:cc:2d
                        58:45:64:f3:33:1d:62:c5:bd:71:a9:13:fe:89:ba:cc
                        c6:35:8a:22:6e:b4:f5:71:58:79:48:e5:1d:d0:c9:42
                        7d:fc:36:d5:fd:3f:0e:3c:b7:97:f0:e2:ca:7f:84:4f
                        6d:64:42:8b:42:c2:ed:7c:97:eb:37:d8:5a:01:da:39
                        b6:a5:82:b0:a0:cf:af:54:20:fb:6d:4b:a6:b8:83:2a
                        6c:36:2a:32:cd:fc:a6:c8:54:d3:53:29:ad:f6:0b:df
                        bd:a5:44:fa:d4:46:a9:90:53:24:5f:68:fa:cb:94:9d
                        d6:69:16:d6:14:41:9d:65:9b:9d:17:f9:37:4e:c1:3b
                        17:d9:67:8a:de:ad:44:cd:00:cc:13:40:99:a5:e3:a4
                        e2:4c:af:04:1a:4c:cd:b4:75:dd:78:b8:80:d9:43:d5
                        54:1f:3e:f0:8a:17:63:a7:f3:1a:67:ca:a2:06:dc:e7
                        80:52:d1:ea:48:dc:81:45:63:18:cb:76:a1:b1:88:58
                        d9
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: node3.example.com
                Subject Key Identifier (not critical):
                        b6c708ceaebf5e2509d57f8fe5cf9ae84d5d7b27
                Authority Key Identifier (not critical):
                        951acec5fda12e4b438d10bb48a5ddcdea33a1f8
Other Information:
        Public Key ID:
                b6c708ceaebf5e2509d57f8fe5cf9ae84d5d7b27
        Public key's random art:
                +--[ RSA 2048]----+
                |        ..       |
                |       .  .      |
                |      .    .     |
                |       . .  . . .|
                |      . S .  . =.|
                |     o o *    ..=|
                |      o + o   Eo=|
                |     . . .   + o=|
                |    .+=.   .o +. |
                +-----------------+

Is the above information ok? (y/N): y


Signing certificate...

So now we have a signed certificates

[root@node2 ~]# ls -l
total 64
-rw-------. 1 root root 1899 Feb 17 17:45 anaconda-ks.cfg
-r--------  1 root root 5813 Apr 16 14:12 ca-key.pem
-rw-r--r--  1 root root 1143 Apr 16 14:16 ca.pem
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Desktop
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Documents
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Downloads
-rw-r--r--. 1 root root    0 Feb 17 17:48 initial-setup-ks.cfg
drwxr-xr-x. 2 root root 4096 Feb 25 21:02 Music
-rw-r--r--  1 root root 1249 Apr 16 14:22 node3-cert.pem
-rw-------  1 root root 5826 Apr 16 14:18 node3-key.pem
-rw-------  1 root root 2513 Apr 16 14:20 node3-request.pem

So next now we can delete node3-request.pem as it is not required any more

[root@node2 ~]# rm -f node3-request.pem

Distributing TLS certificates to enable secure remote logging

Next now we must copy these keys (certificates) to our remote node. So before we copy the keys we will create a directory on the server node to store these keys

[root@node3 ~]# mkdir /etc/rsyslog-keys
[root@node3 ~]# cd /etc/rsyslog-keys

Next copy the keys from node2 to node3

[root@node2 ~]# scp node3-*.pem node3:/etc/rsyslog-keys/
The authenticity of host 'node3 ()' can't be established.
ECDSA key fingerprint is SHA256:3RCFjBhKJLtOb78Jv+Yx2IPbwRT5P1hOGw9d08RlGzs.
ECDSA key fingerprint is MD5:b8:f9:09:06:91:48:de:a1:83:29:56:d5:94:3d:a6:d3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node3' (ECDSA) to the list of known hosts.
root@node3's password:
node3-cert.pem                                                                            100% 1249   729.7KB/s   00:00
node3-key.pem                                                                             100% 5826     2.9MB/s   00:00

[root@node2 ~]# scp ca.pem node3:/etc/rsyslog-keys/
root@node3's password:
ca.pem 			                                                                  100% 1249   729.7KB/s   00:00

Server configuration to forward syslog securely

Now we need to do some configuration changes on our remote log server (node3) to receive messages from our client (node2) over TCP using TLS certificates.

Create a new file /etc/rsyslog.d/logserver.conf. The name of the file is not important and you can give any name, just make sure the extension of the file is .conf. Dump the below content in this file.

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /etc/rsyslog-keys/ca.pem
$DefaultNetstreamDriverCertFile /etc/rsyslog-keys/node3-cert.pem
$DefaultNetstreamDriverKeyFile /etc/rsyslog-keys/node3-key.pem

$ModLoad imtcp  # TCP listener
$InputTCPServerStreamDriverMode 1  # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon
$InputTCPServerRun 6514  # start up listener at port 10514

Next install the below rpm (if not installed already), to install /usr/lib64/rsyslog/lmnsd_gtls.so module. Since we are using GTLS driver so this module must be installed on both client and server node.

[root@node3 ~]# yum -y install rsyslog-gnutls

Next restart the rsyslog service

[root@node3 rsyslog.d]# systemctl restart rsyslog

Check the service status

[root@node3 rsyslog.d]# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-04-16 15:21:41 IST; 2s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 7822 (rsyslogd)
    Tasks: 8
   CGroup: /system.slice/rsyslog.service
           └─7822 /usr/sbin/rsyslogd -n

Apr 16 15:21:41 node3 systemd[1]: Starting System Logging Service...
Apr 16 15:21:41 node3 rsyslogd[7822]:  [origin software="rsyslogd" swVersion="8.24.0-34.el7" x-pid="7822" x-info="http://ww...] start
Apr 16 15:21:41 node3 systemd[1]: Started System Logging Service.
Hint: Some lines were ellipsized, use -l to show in full.

So our configuration on the server side is completed, let us go to the client (node2) side to complete our secure remote logging.

Client configuration to receive log messages securely

Now let us configure our client (node2) to transfer the logs securely to our remote log server (node3).

The first step would be to create a directory to store our key

[root@node2 ~]# mkdir /etc/rsyslog-keys

Next copy ca.pem to this directory

[root@node2 ~]# cp ca.pem /etc/rsyslog-keys/

Next create a new file inside /etc/rsyslog.d

[root@node2 ~]# vim /etc/rsyslog.d/log-client.conf
# certificate files
$DefaultNetStreamDriverCAFile /etc/rsyslog-keys/ca.pem

# make gtls driver the default
$DefaultNetStreamDriver gtls
$ActionSendStreamDriverMode 1	# run driver in TLS-only mode
$ActionSendStreamDriverAuthMode anon

*.*     @@(o)node3.example.com:6514		# forward everything to remote server

This will forward every syslog message to your remote log server node3

Next install rsyslog-gnutls since we want to load gtls module for the secure remote logging to work.

[root@node2 ~]# yum -y install rsyslog-gnutls

We are all done, now restart the rsyslog service and check the status

[root@node2 ~]# systemctl restart rsyslog

[root@node2 ~]# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-04-16 15:32:10 IST; 4s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 7784 (rsyslogd)
    Tasks: 3
   CGroup: /system.slice/rsyslog.service
           └─7784 /usr/sbin/rsyslogd -n

Apr 16 15:32:10 node2.example.com systemd[1]: Stopped System Logging Service.
Apr 16 15:32:10 node2.example.com systemd[1]: Starting System Logging Service...
Apr 16 15:32:10 node2.example.com rsyslogd[7784]:  [origin software="rsyslogd" swVersion="8.24.0-34.el7" x-pid="7784...start
Apr 16 15:32:10 node2.example.com systemd[1]: Started System Logging Service.
Hint: Some lines were ellipsized, use -l to show in full.

So we are all done with the configuration.

Verify the remote logging

Now we will try to send a dummy message from our server to our client and verify our configuration

[root@node2 ~]# logger "MESSAGE FROM NODE2"

Check the syslog on the server

[root@node3 ~]# less /var/log/messages
Apr 16 17:14:28 node2 root: MESSAGE FROM NODE2

And we have received the message as expected so all seems to work properly.

Applying log filter with rsyslog

Now here we are getting all the messages from node2 inside /var/log/messages of our remote log server node3 so logs are getting mixed up, let us filter the logs out and all the logs from node2 would be stored in a different log file.

To achieve this we will create a new file with the filter configuration on our remote log server node3

[root@node3 ~]# cd /etc/rsyslog.d/

[root@node3 rsyslog.d]# cat remotefilter.conf
:fromhost, isequal, "node2.example.com"         /var/log/node2/messages
:fromhost, isequal, "node2.example.com"         ~

Here the syntax itself is quite explanatory, the second line might look little confusing. Here the second line is going to make sure that nothing else will be done with messages that are coming from the server.

Next restart the rsyslog service

[root@node3 rsyslog.d]# systemctl restart rsyslog

[root@node3 rsyslog.d]# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-04-16 17:22:14 IST; 11min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 9436 (rsyslogd)
    Tasks: 8
   CGroup: /system.slice/rsyslog.service
           └─9436 /usr/sbin/rsyslogd -n

Apr 16 17:22:14 node3.example.com systemd[1]: Stopped System Logging Service.
Apr 16 17:22:14 node3.example.com systemd[1]: Starting System Logging Service...
Apr 16 17:22:14 node3.example.com rsyslogd[9436]:  [origin software="rsyslogd" swVersion="8.24.0-34.el7" x-pid="9436" x-info="http://www.rsyslog.com"] start
Apr 16 17:22:14 node3.example.com rsyslogd[9436]: warning: ~ action is deprecated, consider using the 'stop' statement instead [v8.24.0-34.el7 try http://www.rsyslog.com/e/2307 ]
Apr 16 17:22:14 node3.example.com systemd[1]: Started System Logging Service.

Now let us print a message on node2 and let's see if it is received on node3

[root@node2 ~]# logger "MESSAGE FROM NODE2 AGAIN"

And looks like the message is well received in our new location as expected.

[root@node3 rsyslog.d]# cat /var/log/node2/messages
Apr 16 17:22:05 node2 root: MESSAGE FROM NODE2 AGAIN

Lastly I hope the steps from the article to configure secure remote logging with rsyslog (TLS certificates) to remote log server on CentOS/RHEL 7 Linux was helpful. So, let me know your suggestions and feedback using the comment section.