-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected tls packet, unable to activate tls using gtls #5372
Comments
Enviroment: I am trying to enable gtls. @rgerhards, you mentioned switching to ossl. If possible, I would like to avoid that, because our security benchmarks want gtls. As a last resort, we could try switching to ossl. You mentioned that this points to tls not being enabled on the client. Can you elaborate? The rsyslog-client.conf seems to set tls as wanted. Do you mean outside of the rsyslog conf? Thanks in advance for any help :) |
I had expected that you follow the advise here, before blindly opening a new issue... pls do now. |
can you do openssl for a test? again, gnutls is notoriously bad in reporting errors. |
I noticed the two messages "Unknown ca" and "wrong version number". Maybe like I asked earlier a problem with the certificates? Server log:
Full config server:
Full config client:
|
Please create a debug log. Instructions: https://www.rsyslog.com/doc/v8-stable/troubleshooting/howtodebug.html Be sure that the problem in question occurs at least once during the debug run. Once this is done, please post the debug log (e.g. via pastebin or github). After that, we can review the contents and check how exactly rsyslog processing worked. This is probably a problem that @alorbach should look at. |
Here is the debug log. The problem happens at line 32110 for example. |
Thx, pls keep the log online for @alorbach , but I think this is the relevant part:
boils down to "unkonwn CA" |
I just noticed this (sry, pretty late). You wrote:
Yes, to check the cert validity, all machines need to have the same CA (or set of interim certs, to be more precise). |
This is weird. While recreating the certs, I noticed that the rsyslog server is logging the same "Handshake failed" messages even when the rsyslog client is marked as inactive/failed. What is sending the server a signal then? Maybe something else is sending packets to the rsyslog port for some reason? Im looking into it. |
Some other sender might be a good explanation ;-) |
After some more testing, I executed this command
TLS1.2 and lower is disabled on the machine our rsyslog server runs on. I know about the gnutlsprioritystring, is there a similar option for the ossl library? How can I force both client and server to use TLS1.3? This is what I had in my config as an option to the imctp listener, does this also work when using ossl? |
This looks like server and client are not finding a shared cipher.
Indead there is, you can actually use "gnutlsprioritystring" to set OpenSSL properties, for example this should work for you: More details in the doc or see ossl testcases in "tests" folder:
|
Im honestly lost. I am not sure whether I have an issue with my certificates, rsyslog, or both. I would greatly appreciate if any of you could take a look at this. Here are the facts:
I also added I have four certificate files per domain, aka client and server. gd_bundle.crt, ca.cer, domain.cer and domain.key. This is the output when both sides have gd_bundle.crt as their CAfile:
This is the output of
Now, when I change the ca-file setting for rsyslog server and client to the ca.cer, following output is produced:
It seems to me like gd_bundle.crt is the better choice, even though it confuses me why a fullchain for the CA-file option seems to work better than the ca file? And then is the question, why is it unable to get the issuer certificate. I googled a lot and found some questions to that, but nothing seemed quite right/like it would help me. I did not update to a newer rsyslog version before these outputs. I will do so now and see if it changes anything. I would be really grateful if you can help me with this. If you need any further info, let me know. |
Could someone take a look at what Im providing below and tell me if they see any obvious things? @rgerhards
We generate the certificates using an acme.sh script. The scripts are generated on the machine, without any knowledge of other machines/domain names. Could that also be a problem? Do the certificates on the clients have to be generated with a dependency on the server certificate?
The machines are on CentOS9 Stream.
Full config of server:
Full config of client:
Server logs:
Client logs:
Originally posted by @Elekam in #3940 (comment)
The text was updated successfully, but these errors were encountered: