TLS library problem: error:0A000126

[JDunphy]

Code: Select all

postfix/smtps/smtpd[19907]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:304:

And emails are being successfuly sent anyway so... But I don't like these lots of errors in log. Today about 4000.

These are warning messages from postfix which makes it a little less bad - is that proper english?

I used Vince's search term and this thread came up and seems to be exactly what you are seeing: https://www.mail-archive.com/postfix-us ... 95796.html because the OP also saw client disconnects abruptly without sending QUIT.

If I understand that thread; a lot of applications using openssl 1.1.1 and earlier were not calling SSL_shutdown(). The TLS error 0A000126 is the important message because when they don't shutdown correctly (thinking SSL_Shutdown() calls close_notify()), the logic is to print out this 0A000126 message indicating unexpected EOF. At some point, the developers of openssl wanted developers to terminate correctly as there was an attack against this shutdown behavior in some instances. SMTP doesn't appear to be one of them.

When Zimbra moved to openssl 3.0, you got the "benefit" of this notification alert. Postfix used the "SSL_OP_IGNORE_UNEXPECTED_EOF" option to silence these notifications when an older client doesn't issue a SSL_shutdown(). Unfortunately, that resolution in postfix is in a newer version which you are not running.

Further background on this close_notify() and 0A000126:
Ref: https://www.ibm.com/docs/en/datapower-g ... tification

For a postfix server probably not going to be a problem because SMTP has it's own message framing and is somewhat resilient against any message truncation at the connection close which also explains why everything continues to work.

As for the extra noise, there are ways to filter this out with rsyslog. When we moved to RHEL8 from RHEL6 with systemd, I had a fit with all the extra "help" in the logs which you probably can relate to. So you could come up with a custom rule to not log this information. Here is an example if you are not familiar with the syntax.

Code: Select all

% cat /etc/rsyslog.d/mydomain-rsyslog.conf 
# systemd
if $programname == "systemd" and 
   ($msg contains "Starting Session" or 
   $msg contains "Started Session" or 
   $msg contains "Created slice" or 
   $msg contains "Starting user-" or 
   $msg contains "Starting User Slice of" or 
   $msg contains "Removed session" or 
   $msg contains "Removed slice User Slice of" or 
   $msg contains "Stopping User Slice of") then stop

That was an Interesting problem and not exactly what I initially thought.

Jim

[loocek]

First of all - thank you for deep analyze

Second - maybe this is because of my commercial SSL certificate (Sectigo) ?
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
Maybe it's been generated without this OCP option or how is called... ?

Anyway emails are working. All that's left for me is making these warnings silent. You're suggesting doing this by rsyslog.
Isn't some way to doing this by changing/adding some parameter to openssl.cnf ?
Someone on Google suggests adding :

Code: Select all

[ssl_default_sect]
Options = SSL_OP_IGNORE_UNEXPECTED_EOF

but I don't see section "[ssl_default_sect]" in openssl.cnf .....

[JDunphy]

Second - maybe this is because of my commercial SSL certificate (Sectigo) ?
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
Maybe it's been generated without this OCP option or how is called... ?

Anyway emails are working. All that's left for me is making these warnings silent. You're suggesting doing this by rsyslog.
Isn't some way to doing this by changing/adding some parameter to openssl.cnf ?
Someone on Google suggests adding :

Code: Select all

[ssl_default_sect]
Options = SSL_OP_IGNORE_UNEXPECTED_EOF

but I don't see section "[ssl_default_sect]" in openssl.cnf .....

I don’t think this has anything to do with your certificate. The nagging warnings were added in OpenSSL 3.0 to enforce stricter TLS session handling. For most of its life, your Zimbra Postfix was linked with the OpenSSL 1.1.1 branch, which didn’t include this behavior. OpenSSL developers tried to add it in one of the 1.1.1 releases, but they removed it after receiving a lot of complaints.

When Postfix started linking with OpenSSL 3.0, admins began noticing these warnings because a lot of older mail clients don’t properly close TLS connections. Postfix itself was still receiving all the necessary SMTP data from these clients, so the warnings weren’t indicative of a real problem. The Postfix team eventually added a fix to suppress these unnecessary warnings, but until your system gets updated with that version of postfix, they’ll still appear. I’m simplifying this, but that’s the gist of it.

I saw the stuff about openssl.cnf and thought it was for the openssl client and utilities that you run from the shell but I could be wrong. I know very little about openssl and it's a huge code base but that is how I always thought about that configuration file. I did not think it had any effect on the compiled library postfix has linked to.

Looks like the openssl 3.0.9 branch was included with 8.8.15 P41 ... From doing a ldd on postfix, it would appear they are dynamically linking openssl 3.0.9 so those warnings would have started with this patch.

Most likely you are unlucky and have many older mail clients connecting to port 465 that do not close the TLS connection properly. It could also be that port 587 startls clients are more recent or have different code paths in these clients but this is all speculation as I moved off of 8.8.15 at EOL Dec 2023. I don't have any warnings in my logs either and I have port 465 mail clients blocked by the firewall.

Ref: https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P41

Jim

[loocek]

So until I don't upgrade Zimbra to e.g. version 10 - warning will stay. Ultimately I will ignore these warnings or try to disable them by rsyslog as you suggested.

Thank you again for analyzing this complicated issue.
Regards.