On 5.06.2023 09:23, Andre Lorbach via rsyslog wrote:
On Fri, June 2, 2023 10:07 am, Andre Lorbach wrote:
-----Original Message-----
From: Derek Atkins <de...@ihtfp.com>
Sent: Freitag, 2. Juni 2023 15:27
To: alorb...@adiscon.com
Cc: rsyslog-users <rsyslog@lists.adiscon.com>; Derek Atkins
<de...@ihtfp.com>
Subject: RE: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
I'm not using client-authentication, which is why there is no client
cert.
Not sure why you consider it "unusual". But that's not the error I
am concerned about.
That is ok, but you will only have anon ciphers if you do not use a
client side certificate.
Yes, I know -- but setting up the client certs would be an added overhead
to
the system.
You could use the same client certificate on all clients, it's not that
uncommon.
It might be common, but it's wrong. If you're using cert-based
authentication, reusing the same certificate is effectively defeating
the purpose. True, in some specific use cases it might be OK but a
decision to do so should be preceeded by risk analysis. In general -
using the same cryptographic material to mass-authenticate multiple
clients does not differ significantly from not authenticating them at all.
It all depends on what you want to achieve. If you just want to limit
who can send to your "collector", you can as well do it with firewall
and drop the encryption completely (maybe saving some CPU cycles on the
way). If you want to have at least a bit of authentication of the actual
subject sending (and have some level of non-repudiation), you need
individual certs per subject.
YMMV of course
MK
_______________________________________________
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.
