Mailing List Archive

Problem with self CA + certificates.
I try on my (central) rsyslog server to set up a certificate authority (CA) and the certificates for the clients.
I follow the steps from the following very interesting and useful documentation pages:
* https://www.rsyslog.com/doc/master/tutorials/tls_cert_ca.html
* https://www.rsyslog.com/doc/master/tutorials/tls_cert_machine.html
* https://www.rsyslog.com/doc/master/tutorials/tls_cert_server.html

but unfortunately I do not have the expected result.
For some reason the (self-signed) CA certificate is not accepted from rsyslog.

## Server
```The logs as I generated it
certtool --generate-privkey --outfile ca-key.pem
certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
```
```logs
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Common name:
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: 6938417459922577638):

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

Extensions.
Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint):
Is this a TLS web client certificate? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N):
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):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used to sign other certificates? (y/N): y
Will the certificate be used to sign CRLs? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
Version: 3
Serial Number (hex): 604a35eb220da8e6
Validity:
Not Before: Thu Mar 11 15:23:24 UTC 2021
Not After: Wed Dec 06 15:23:28 UTC 2023
Subject:
Subject Public Key Algorithm: RSA
Algorithm Security Level: Medium (2048 bits)
Modulus (bits 2048):
00:da:ae:33:95:48:8b:9d:27:4d:d6:80:a6:2d:c0:40
3c:7d:6a:c6:64:c2:e2:23:f9:42:e1:2d:32:56:d3:ba
[ ...... ]
2f:68:d2:d9:73:a1:31:09:d6:05:18:ed:20:06:45:8b
9b
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): TRUE
Subject Alternative Name (not critical):
RFC822Name:
Key Usage (critical):
Certificate signing.
Subject Key Identifier (not critical):
7b34103e9dc02d497d78c303fc547f78d6f6318d
Other Information:
Public Key ID:
7b34103e9dc02d497d78c303fc547f78d6f6318d
Public key's random art:
+--[ RSA 2048]----+
| o+=.+ .. |
[ ... ]
+-----------------+

Is the above information ok? (y/N): y
Signing certificate...
```

```
chmod 400 ca-key.pem
```

## Client
```
certtool --generate-privkey --outfile key.pem
```
```
certtool --generate-request --load-privkey key.pem --outfile request.pem
Generating a PKCS #10 certificate request...
Common name:
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:
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): n
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Is this a TLS web client certificate? (y/N): y
Is this a TLS web server certificate? (y/N): y
```

```
certtool --generate-certificate --load-request request.pem --outfile 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: 6938404153755168037):

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): y
Path length constraint (decimal, -1 for no constraint):
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:
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):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used to sign other certificates? (y/N):
Will the certificate be used to sign CRLs? (y/N):
[...]
Is the above information ok? (y/N): y

Signing certificate...
```

After that I config my (centra) rsyslog to read the certificates:

```/etc/rsyslog.conf
$DefaultNetstreamDriverCAFile /root/rsyslog-server/ca.pem
$DefaultNetstreamDriverCertFile /root/rsyslog-server/cert.pem
$DefaultNetstreamDriverKeyFile /root/rsyslog-server/key.pem
```

```
rsyslogd -N1
rsyslogd: version 8.24.0-57.el7_9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
```

```# systemctl status rsyslog -l
? rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-03-11 17:26:01 EET; 2s ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 6693 (rsyslogd)
CGroup: /system.slice/rsyslog.service
??6693 /usr/sbin/rsyslogd -n

Mar 11 17:26:01 testVM systemd[1]: Starting System Logging Service...
Mar 11 17:26:01 testVM rsyslogd[6693]: [origin software="rsyslogd" swVersion="8.24.0-57.el7_9" x-pid="6693" x-info="http://www.rsyslog.com"] start
Mar 11 17:26:01 testVM rsyslogd[6693]: error reading certificate file '/root/rsyslog-server/ca.pem' - a common cause is that the file does not exist [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2078 ]
Mar 11 17:26:01 testVM rsyslogd[6693]: could not load module '/usr/lib64/rsyslog/lmnsd_gtls.so', rsyslog error -2078 [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2068 ]
Mar 11 17:26:01 testVM systemd[1]: Started System Logging Service.
Mar 11 17:26:01 testVM rsyslogd[6693]: tcpsrv could not create listener (inputname: 'imtcp') [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2068 ]
Mar 11 17:26:01 testVM rsyslogd[6693]: activation of module imtcp failed [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2068 ]
```

```ls -alh /root/rsyslog-server/ca.pem
-rw-r--r--. 1 root root 1.5K Mar 11 17:24 /root/rsyslog-server/ca.pem
```

I do not understand why this is happening. I can not find the problem.
Where is the problem ?

I want to create a pair of certificates for all my machines (not separately for each machine).
These machines may have completely different domain names but I want all of them to send their logs with the same certificate (for convenience) to a central rsyslog machine.
* Central rsyslog VM OS : CentOS 7

Thanks in advance.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
> Mar 11 17:26:01 testVM rsyslogd[6693]: error reading certificate file '/root/rsyslog-server/ca.pem' - a common cause is that the file does not exist [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2078 ]


As you can see, the rsyslog daemon cannot - for some reason - read the file.

Fistly - the obvious question - are you sure you didn't do a typo or
something? (have you checked copy-pasting paths from config file and
reading the files?)

Secondly - CentOS7 by default ships with SELinux enabled. So even though
rsyslogd by default runs as root in CentOS7, it won't be able to access
the files because selinux context mismatch.

This location is bad, anyway. You shouldn't put configuration elements
in root's home directory. It's what /etc is for.


> I want to create a pair of certificates for all my machines (not separately for each machine).
> These machines may have completely different domain names but I want all of them to send their logs with the same certificate (for convenience) to a central rsyslog machine.
Bad idea. If you're going for encryption, do it properly.

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
??????? Original Message ???????
On Friday, March 12, 2021 10:07 AM, Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com> wrote:

> > Mar 11 17:26:01 testVM rsyslogd[6693]: error reading certificate file '/root/rsyslog-server/ca.pem' - a common cause is that the file does not exist [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2078 ]
>
> As you can see, the rsyslog daemon cannot - for some reason - read the file.
>
> [ --%< snipped %<--- ]
>
> Secondly - CentOS7 by default ships with SELinux enabled. So even though
> rsyslogd by default runs as root in CentOS7, it won't be able to access
> the files because selinux context mismatch.
>
> This location is bad, anyway. You shouldn't put configuration elements
> in root's home directory. It's what /etc is for.

Yes, the problem arose because of SELinux - I forgot that it was enable.
And of course the location of the certificates made the situation worse. When I created them under the /etc, they had the right SELinux rights.
Would it be useful to note this here: http://www.rsyslog.com/e/2078 ?


> > I want to create a pair of certificates for all my machines (not separately for each machine).
> > These machines may have completely different domain names but I want all of them to send their logs with the same certificate (for convenience) to a central rsyslog machine.
>
> Bad idea. If you're going for encryption, do it properly.

The right way is to create a certificate per client - right ? I understand that - it makes sense.
In addition to security/safety/privacy, can I get additional benefits from rsyslog (central) side with different certificates per client ?
For example, can I check the certificate with rsyslog and do something ?



_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
On 23.03.2021 08:43, odrzen wrote:
> ??????? Original Message ???????
> On Friday, March 12, 2021 10:07 AM, Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com> wrote:
>
>>> Mar 11 17:26:01 testVM rsyslogd[6693]: error reading certificate file '/root/rsyslog-server/ca.pem' - a common cause is that the file does not exist [v8.24.0-57.el7_9 try http://www.rsyslog.com/e/2078 ]
>> As you can see, the rsyslog daemon cannot - for some reason - read the file.
>>
>> [ --%< snipped %<--- ]
>>
>> Secondly - CentOS7 by default ships with SELinux enabled. So even though
>> rsyslogd by default runs as root in CentOS7, it won't be able to access
>> the files because selinux context mismatch.
>>
>> This location is bad, anyway. You shouldn't put configuration elements
>> in root's home directory. It's what /etc is for.
> Yes, the problem arose because of SELinux - I forgot that it was enable.
> And of course the location of the certificates made the situation worse. When I created them under the /etc, they had the right SELinux rights.
> Would it be useful to note this here: http://www.rsyslog.com/e/2078 ?

I suppose the idea is that if you're administering a system you know
what you're doing ;-)

So the information that you don't have permission to read the file
should be enough. SELinux issues are very specific to a particular OS
and if you use it you should understand it. (and yes, I sometimes get
hit by SELinux permission issues myself if I forget to adjust my policies).

>>> I want to create a pair of certificates for all my machines (not separately for each machine).
>>> These machines may have completely different domain names but I want all of them to send their logs with the same certificate (for convenience) to a central rsyslog machine.
>> Bad idea. If you're going for encryption, do it properly.
> The right way is to create a certificate per client - right ? I understand that - it makes sense.
> In addition to security/safety/privacy, can I get additional benefits from rsyslog (central) side with different certificates per client ?
> For example, can I check the certificate with rsyslog and do something ?
>
Yes, the proper way, since the certificate ties a cryptographic material
to a particular subject (in this case - a server) is to use separate
certificates per each client.

Unfortunately you can't use the information from the certificate during
event processing (at least I don't know of any way to - for example -
extract subject data from the certificate and use it in a ruleset). But
you can limit access to inputs based on client name and allow only
certain peers to connect.

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
Hello Mariusz,

??????? Original Message ???????
On Wednesday, March 24, 2021 10:40 AM, Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com> wrote:

> [ --%< snipped %<--- ]
>
> I suppose the idea is that if you're administering a system you know
> what you're doing ;-)
>
> So the information that you don't have permission to read the file
> should be enough. SELinux issues are very specific to a particular OS
> and if you use it you should understand it. (and yes, I sometimes get
> hit by SELinux permission issues myself if I forget to adjust my policies).

Yes, OK, I agree with you. You're right.
Yes, I know and I feel you!


> > > > I want to create a pair of certificates for all my machines (not separately for each machine).
> > > > These machines may have completely different domain names but I want all of them to send their logs with the same certificate (for convenience) to a central rsyslog machine.
> > > > Bad idea. If you're going for encryption, do it properly.
> > > > The right way is to create a certificate per client - right ? I understand that - it makes sense.
> > > > In addition to security/safety/privacy, can I get additional benefits from rsyslog (central) side with different certificates per client ?
> > > > For example, can I check the certificate with rsyslog and do something ?
>
> Yes, the proper way, since the certificate ties a cryptographic material
> to a particular subject (in this case - a server) is to use separate
> certificates per each client.
>
> Unfortunately you can't use the information from the certificate during
> event processing (at least I don't know of any way to - for example -
> extract subject data from the certificate and use it in a ruleset). But
> you can limit access to inputs based on client name and allow only
> certain peers to connect.

"client name" - You mean by this option `Enter the dnsName of the subject of the certificate` when create a certificate for the clients ?
and after that with the following directive on central rsyslog configuration:
```
$InputTCPServerStreamDriverPermittedPeer machine-1.example.com
```
?

Can I use it multiple times for different pears, something like that:
```
$InputTCPServerStreamDriverPermittedPeer machine-1.example.com
$InputTCPServerStreamDriverPermittedPeer machine-2.example.com
$InputTCPServerStreamDriverPermittedPeer machine-Y.example.com
$InputTCPServerStreamDriverPermittedPeer machine-x.test.com
```

or with this way:
```
$InputTCPServerStreamDriverPermittedPeer *.example.com machine-Y.example.com machine-x.test.com
```

?

By the way, can I have many CAs certificates in the same configuration ?
For example :
```
# For devel:
$DefaultNetstreamDriverCAFile /etc/.../ca-devel.pem
$DefaultNetstreamDriverCertFile /etc/.../devel-client-cert.pem
$DefaultNetstreamDriverKeyFile /etc/.../devel-client-key.pem
# For production:
$DefaultNetstreamDriverCAFile /etc/.../ca-prod.pem
$DefaultNetstreamDriverCertFile /etc/.../prod-client-cert.pem
$DefaultNetstreamDriverKeyFile /etc/.../prod-client-key.pem
# or. for another DC...
```

I thought this because I see the `$Default` prefix in these directives.
So, can I have more directives besides the defaults?


Thank you all for your help
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
On 24.03.2021 12:54, odrzen wrote:
>> Yes, the proper way, since the certificate ties a cryptographic material
>> to a particular subject (in this case - a server) is to use separate
>> certificates per each client.
>>
>> Unfortunately you can't use the information from the certificate during
>> event processing (at least I don't know of any way to - for example -
>> extract subject data from the certificate and use it in a ruleset). But
>> you can limit access to inputs based on client name and allow only
>> certain peers to connect.
> "client name" - You mean by this option `Enter the dnsName of the subject of the certificate` when create a certificate for the clients ?
> and after that with the following directive on central rsyslog configuration:
> ```
> $InputTCPServerStreamDriverPermittedPeer machine-1.example.com
> ```
> ?
>
> Can I use it multiple times for different pears, something like that:
> ```
> $InputTCPServerStreamDriverPermittedPeer machine-1.example.com
> $InputTCPServerStreamDriverPermittedPeer machine-2.example.com
> $InputTCPServerStreamDriverPermittedPeer machine-Y.example.com
> $InputTCPServerStreamDriverPermittedPeer machine-x.test.com
> ```
>
> or with this way:
> ```
> $InputTCPServerStreamDriverPermittedPeer *.example.com machine-Y.example.com machine-x.test.com
> ```
>
> ?
>
> By the way, can I have many CAs certificates in the same configuration ?
> For example :
> ```
> # For devel:
> $DefaultNetstreamDriverCAFile /etc/.../ca-devel.pem
> $DefaultNetstreamDriverCertFile /etc/.../devel-client-cert.pem
> $DefaultNetstreamDriverKeyFile /etc/.../devel-client-key.pem
> # For production:
> $DefaultNetstreamDriverCAFile /etc/.../ca-prod.pem
> $DefaultNetstreamDriverCertFile /etc/.../prod-client-cert.pem
> $DefaultNetstreamDriverKeyFile /etc/.../prod-client-key.pem
> # or. for another DC...
> ```

OK. With TLS it all gets tricky.

Firstly, to get it out of the way, you should not use the legacy config
directives. So instead of $InputTCPServerStreamDriverPermittedPeer you
should use a PermitedPeer option of an input(type="imtcp" [...])
directive and so on.

Having said that - as I wrote - TLS is a bit tricky because it works a
bit differently depending on the underlying TLS library and its version,
and some parameters can be a bit vague (like said PermittedPeer option
which, quoting from the docs, "<id-string> semantics depend on the
currently selected AuthMode and network stream driver
<https://www.rsyslog.com/doc/master/concepts/netstrm_drvr.html>.
PermittedPeer may not be set in anonymous modes. PermittedPeer may be
set either to a single peer or an array of peers either of type IP or
name, depending on the tls certificate").

Having multiple CAs is not that easy, and doesn't work with openssl
1.0.x AFAIR. So you might have to do a bit of reading.

Firstly - https://www.rsyslog.com/doc/master/tutorials/tls.html

Then - docs for the appropriate input/output modules

Finally you'd need some testing probably.

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
??????? Original Message ???????
On Wednesday, March 24, 2021 2:58 PM, Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com> wrote:

> >
> > [ --%< snipped %<--- ]
> >
>
> OK. With TLS it all gets tricky.
>
> Firstly, to get it out of the way, you should not use the legacy config
> directives. So instead of $InputTCPServerStreamDriverPermittedPeer you
> should use a PermitedPeer option of an input(type="imtcp" [...])
> directive and so on.

Yes you are right, I didn't notice that, because I already found the legacy configuration on the central rsyslog machine and and it works..
--> https://www.rsyslog.com/doc/v8-stable/configuration/modules/imtcp.html#permittedpeer

But, is there any porting guide from "legacy" to "current" configuration ?


So, according to the following guides:
* https://www.rsyslog.com/doc/master/tutorials/tls.html#server-setup
* https://www.rsyslog.com/doc/master/concepts/ns_ossl.html#supported-authentication-modes
all this central legacy configuration:
```
$ModLoad imtcp
$DefaultNetstreamDriver gtls
$InputTCPServerStreamDriverMode 1

$DefaultNetstreamDriverCAFile /etc/.../ca.pem
$DefaultNetstreamDriverCertFile /etc/.../client-cert.pem
$DefaultNetstreamDriverKeyFile /etc/.../client-key.pem

$InputTCPServerStreamDriverMode 1
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.example.domain.com
$InputTCPServerRun 6514
```

can it be replaced with the following configuration:
```
global(
DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/path/to/contrib/gnutls/ca.pem"
DefaultNetstreamDriverCertFile="/path/to/contrib/gnutls/cert.pem"
DefaultNetstreamDriverKeyFile="/path/to/contrib/gnutls/key.pem"
)

# load TCP listener
module(
load="imtcp"
StreamDriver.Name="gtls"
StreamDriver.Mode="1"
StreamDriver.Authmode="x509/name"
PermittedPeer=["*.example.domain.com", "*.prod.example.com"]
)

# start up listener at port 6514
input(
type="imtcp"
port="6514"
)
```

?


> Having said that - as I wrote - TLS is a bit tricky because it works a
> bit differently depending on the underlying TLS library and its version,
> and some parameters can be a bit vague (like said PermittedPeer option
> which, quoting from the docs, "<id-string> semantics depend on the
> currently selected AuthMode and network stream driver
> https://www.rsyslog.com/doc/master/concepts/netstrm_drvr.html.
> PermittedPeer may not be set in anonymous modes. PermittedPeer may be
> set either to a single peer or an array of peers either of type IP or
> name, depending on the tls certificate").
>
> Having multiple CAs is not that easy, and doesn't work with openssl
> 1.0.x AFAIR. So you might have to do a bit of reading.
>
> Firstly - https://www.rsyslog.com/doc/master/tutorials/tls.html
>
> Then - docs for the appropriate input/output modules
>
> Finally you'd need some testing probably.


Thank you very much for this very interesting and important information!
Your note about the underlying TLS library and its version its very important to to emphasize.
For example, according to you and for my current system - not currently supported:
```
openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
```

Finally, note that the guide you sent me (which helps a lot) is:
"Written by Rainer Gerhards (2008-05-06)"
Could we try to renew it together ? ^_^'


Thank you very much for your time and help


_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Problem with self CA + certificates. [ In reply to ]
On 24.03.2021 23:54, odrzen wrote:
> ??????? Original Message ???????
> On Wednesday, March 24, 2021 2:58 PM, Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com> wrote:
>
>>> [ --%< snipped %<--- ]
>>>
>> OK. With TLS it all gets tricky.
>>
>> Firstly, to get it out of the way, you should not use the legacy config
>> directives. So instead of $InputTCPServerStreamDriverPermittedPeer you
>> should use a PermitedPeer option of an input(type="imtcp" [...])
>> directive and so on.
> Yes you are right, I didn't notice that, because I already found the legacy configuration on the central rsyslog machine and and it works..
> --> https://www.rsyslog.com/doc/v8-stable/configuration/modules/imtcp.html#permittedpeer
>
> But, is there any porting guide from "legacy" to "current" configuration ?
>
>
> So, according to the following guides:
> * https://www.rsyslog.com/doc/master/tutorials/tls.html#server-setup
> * https://www.rsyslog.com/doc/master/concepts/ns_ossl.html#supported-authentication-modes
> all this central legacy configuration:
> ```
> $ModLoad imtcp
> $DefaultNetstreamDriver gtls
> $InputTCPServerStreamDriverMode 1
>
> $DefaultNetstreamDriverCAFile /etc/.../ca.pem
> $DefaultNetstreamDriverCertFile /etc/.../client-cert.pem
> $DefaultNetstreamDriverKeyFile /etc/.../client-key.pem
>
> $InputTCPServerStreamDriverMode 1
> $InputTCPServerStreamDriverAuthMode x509/name
> $InputTCPServerStreamDriverPermittedPeer *.example.domain.com
> $InputTCPServerRun 6514
> ```
>
> can it be replaced with the following configuration:
> ```
> global(
> DefaultNetstreamDriver="gtls"
> DefaultNetstreamDriverCAFile="/path/to/contrib/gnutls/ca.pem"
> DefaultNetstreamDriverCertFile="/path/to/contrib/gnutls/cert.pem"
> DefaultNetstreamDriverKeyFile="/path/to/contrib/gnutls/key.pem"
> )
>
> # load TCP listener
> module(
> load="imtcp"
> StreamDriver.Name="gtls"
> StreamDriver.Mode="1"
> StreamDriver.Authmode="x509/name"
> PermittedPeer=["*.example.domain.com", "*.prod.example.com"]
> )
>
> # start up listener at port 6514
> input(
> type="imtcp"
> port="6514"
> )
> ```
>
> ?


To be fully honest with you I don't have the time at the moment to check
the completness of this configuration but on the first glance looks more
or less OK. One thing - here you use gtls as stream driver whereas in
the paragraph below you say you're using openssl. It doesn't add up.

>
>> Having said that - as I wrote - TLS is a bit tricky because it works a
>> bit differently depending on the underlying TLS library and its version,
>> and some parameters can be a bit vague (like said PermittedPeer option
>> which, quoting from the docs, "<id-string> semantics depend on the
>> currently selected AuthMode and network stream driver
>> https://www.rsyslog.com/doc/master/concepts/netstrm_drvr.html.
>> PermittedPeer may not be set in anonymous modes. PermittedPeer may be
>> set either to a single peer or an array of peers either of type IP or
>> name, depending on the tls certificate").
>>
>> Having multiple CAs is not that easy, and doesn't work with openssl
>> 1.0.x AFAIR. So you might have to do a bit of reading.
>>
>> Firstly - https://www.rsyslog.com/doc/master/tutorials/tls.html
>>
>> Then - docs for the appropriate input/output modules
>>
>> Finally you'd need some testing probably.
>
> Thank you very much for this very interesting and important information!
> Your note about the underlying TLS library and its version its very important to to emphasize.
> For example, according to you and for my current system - not currently supported:
> ```
> openssl version
> OpenSSL 1.0.2k-fips 26 Jan 2017
> ```

Yes, I struggled with OpenSSL 1.0.2k myself (CentOS7, I presume?)

In my case I needed the rsyslog server to be able to present a full
chained certificate and verify the peer's certificate with just a root
CA cert which is impossible with rsyslog with OpenSSL-1.0. It ended with
me rebuilding rsyslog packages to use OpenSSL-1.1 (openssl11-libs
package from EPEL).

> Finally, note that the guide you sent me (which helps a lot) is:
> "Written by Rainer Gerhards (2008-05-06)"
> Could we try to renew it together ? ^_^'

The guide is still pretty current. The configuration is still done the
way it's described there. OK, it could use a bit of a stress on the fact
that some details of TLS are heavily dependent on the underlying TLS
library and you can run into some "quirks" with it.


_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.