Exim 4.92

i have the same on some older servers

--make[1]: Entering directory `/usr/local/directadmin/custombuild/exim-4.92/build-Linux-i386'
>>> version 4.92 #4

>>> version 4.92 #5

gcc -DMACRO_PREDEF macro_predef.c
In file included from exim.h:482,
from macro_predef.c:11:
structs.h:757: error: 'NS_MAXMSG' undeclared here (not in a function)
make[1]: *** [macro_predef.o] Error 1
make[1]: Leaving directory `/usr/local/directadmin/custombuild/exim-4.92/build-Linux-i386'
make: *** [all] Error 2

*** The make has failed, would you like to try to make again? (y,n):
---

did anyone resolved this?

Please press Ctrl+Z when getting this message.

Then do:
vim /usr/local/directadmin/custombuild/exim-4.92/build-Linux-x86_64/structs.h

Type:
:set number

Go to line 747, before the typedef struct, press i, and add:
#ifndef NS_MAXMSG
# define NS_MAXMSG 65535
#endif

Press escape, type:
:wq!

Followed by enter, type the following commands:
fg
y

Build should proceed, if there are any additional errors, please download latest openssl-1.0.2s and compile it. This can be done with:

cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.2s.tar.gz
tar -xvzf openssl-1.0.2s.tar.gz
cd openssl-1.0.2s
./config --prefix=/usr no-threads shared
make
make test
make install

Please do the builds of apache, php, exim and dovecot again after updating openssl.
 
I spoke too soon..... Clients say their email is being bounced.....

TLS error on connection from mail-ed1-f66.google.com [209.85.208.66] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib

What is going on?!


What has changed in 4.92?

OS is Debian 8....
 
Last edited:
I've been running Exim version 4.92 #5 built 14-Feb-2019 05:23:06 until now without any issue on Debian 7.11 (yes, it is EOL) with OpenSSL 1.0.1t .

Re-compiled fine: Exim version 4.92 #5 built 15-Jun-2019 11:51:26


Emails are coming fine on my end:

Code:
2019-06-15 11:55:01 1hc5On-0006GW-2E <= [email protected] H=mail-lj1-f171.google.com [209.85.208.171] P=esmtps X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=3532 DKIM=gmail.com [email protected] T="Test" from <[email protected]> for [email protected]

Whatever reason might be in your case, it should be investigated. Probably your exim config is too strict in terms of allowed TLS protocols and ciphers.
 
Whatever reason might be in your case, it should be investigated. Probably your exim config is too strict in terms of allowed TLS protocols and ciphers.
I also have a Debian 7 box, and exim 4.92 is fine.

All my exim configs are the default.

Debian 7: OpenSSL 1.0.1t 3 May 2016
Debian 8: OpenSSL 1.0.1t 3 May 2016

:confused:
 
We're still having major issues with clients using TLS. Exim still returns an error.

Code:
error:1412E0E2:SSL routines:ssl_parse_clienthello_tlsext:clienthello tlsext

Fun. Now we have to decide whether we would like servers to get hacked or if we want to send email.
 
The issue seems to be related to SNI. Not sure why or how but I have been digging into this a little deeper this afternoon.

In 4.92 the following has been implemented:

JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server side. Previously we would continue as if no SNI had been received."

In /etc/exim.variables.conf there is this snippet:

Code:
tls_certificate=${if exists{/etc/virtual/snidomains}{${lookup{$tls_in_sni}nwildlsearch{/etc/virtual/snidomains}{${if exists{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.cert.combined}{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.cert.combined}{/etc/exim.cert}}}{/etc/exim.cert}}}{/etc/exim.cert}}
tls_privatekey=${if exists{/etc/virtual/snidomains}{${lookup{$tls_in_sni}nwildlsearch{/etc/virtual/snidomains}{${if exists{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.key}{/usr/local/directadmin/data/users/${extract{1}{:}{$value}}/domains/${extract{2}{:}{$value}}.key}{/etc/exim.key}}}{/etc/exim.key}}}{/etc/exim.key}}

We're connecting to smtp.domain.com. This domain exists in /etc/virtual/snidomains. The username exists. And there is a certificate for domain.com in /user/local/directadmin/data/users/[username]/domains too. In this particular case it's a wildcard certificate for *.domain.com.

As soon as I empty /etc/virtual/snidomains things start to work. I have no idea what's going wrong here.
 
After a LOT of debugging we have found the issue. It turned out to be a problem on our end that never showed until now. The combined certificate and key didn't match due to an incomplete entry in the systems that manage our servers.

We're not seeing any errors on our servers anymore. Please do not let my previous posts hold you back in updating your servers. It's vital that you do.
 
Doubt this is my issue....... I'm confused it is just Debian 8....... I have 7, 8 and 9, all have the same config and compile files........

I had a Google, and didn't really help.
 
Please press Ctrl+Z when getting this message.

Then do:
vim /usr/local/directadmin/custombuild/exim-4.92/build-Linux-x86_64/structs.h
...

Thanks AndriesLouw, much appreciated reply.
I was in a dead lock with some old ancient servers. i did mitigate it by putting a spam proxy solution in front of it, with only allowing the ip's of the spam proxy to send email to it.
but your solution gives also others in the same situation a solution. Thanks again. this gives some time to fase these old servers out.

Soul.
 
Code:
cd /usr/local/directadmin/custombuild
./build update
./build set exim yes
./build exim

Thank you for this. Both my 4.91 servers are now updated to 4.92. Kind of wish there was a more formal way of addressing these things from the direct admin site rather than looking for it through the forums. If there is forgive me and if you'd kindly point me to it?
 
Am I the only one with the problem stated in post #22

Anyone else have Debian 8.11?

I'm running out of ideas to get this sorted.

Edit:

I only see this error only with certain hosts, Google being one, eg.
2019-06-13 06:04:58 TLS error on connection from mail-ed1-f49.google.com [209.85.208.49] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:05:57 TLS error on connection from [77.40.27.144] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:05:58 TLS error on connection from (localhost.localdomain) [77.40.27.144] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
2019-06-13 06:06:21 TLS error on connection from webgridf011.emsecure.net [91.230.176.11] (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
 
Last edited:
I've checked Debian 8.11 on our end. No issue found.

- A server has been running Exim version 4.92 since 26-Feb-2019

Code:
root@server:/usr/local/directadmin/custombuild# exim --version
Exim version 4.92 #5 built 26-Feb-2019 01:27:39
...


with OpenSSL 1.0.1t 3 May 2016



- For testing purposes I've re-compiled Exim:

Code:
Exim installation complete
Moving exim binary.
Enabling exim in systemd...
Exim 4.92 Installed.
Restarting exim.

- Exim version is the same, and built date updated:


Code:
root@server:/usr/local/directadmin/custombuild# exim --version
Exim version 4.92 #5 built 18-Jun-2019 13:02:48
...

I've sent a testing email from my @gmail.com account:

Code:
2019-06-18 13:04:18 1hdHWr-0001AD-Sh <= ***hidden***@gmail.com H=mail-lf1-f41.google.com [209.85.167.41] P=esmtps X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=4014 DKIM=gmail.com id=eme727f101-c5cf-4be4-b33e-10c93952c590@echobook T="Test" from <***hidden***@gmail.com> for [email protected]
2019-06-18 13:04:18 1hdHWr-0001AD-Sh => poralix <[email protected]> F=<***hidden***@gmail.com> R=localuser T=local_delivery S=4142
2019-06-18 13:04:18 1hdHWr-0001AD-Sh Completed

The email delivered fine.

You might open a ticket with DirectAdmin support if you want them to check your server.
 
We have found the same issue today with one of our customer domains - (SSL_accept): error:20074002:BIO routines:FILE_CTRL:system lib
And this was a file permission issue - exim was unable to read key and certificate from /usr/local/directadmin/data/users/.../domains/ because file owner is diradmin:diradmin
Issue resolved after we changed permissions for .key and .cert.combined files to 640 diradmin:mail

So what's the reason for that issue and how this SNI-support supposed to work?
Because now for every SSL-enabled domain on the server we are getting:
Code:
# openssl s_client -quiet -connect localhost:465 -servername userdomain.com
34380880456:error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name:/usr/src/crypto/openssl/ssl/s23_clnt.c:802:
until we fix permissions as stated above.
 
Last edited:
In response to ClayRabbit.

I can see a domain.cert.combined.combined with permissions of diradmin:mail on my Debian 7 box..... but not on my Debian 8 box, I see domain.cert.combined with permissions of diradmin:diradmin


Bug or what?

Note: I only see combined.combined for some domains, which I think are from 2018.

So my question is, is this really a permission issue with 4.92? That said, diradmin:diradmin works with other boxes with 4.92 {shrug emoji}
 
Last edited:
Good catch. To set correct permissions run

Code:
/usr/local/directadmin/scripts/set_permissions.sh da_files

it should set to diradmin:access 640

- domains/*.cert
- domains/*.cacert
- domains/*.cert.combined
- domains/*.key
 
It didn't..... it set them to diradmin:diradmin......
Code:
set /usr/local/directadmin/data/users/{user}/domains/*.cert diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.cert.combined diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.cacert diradmin:diradmin 640 flag
set /usr/local/directadmin/data/users/{user}/domains/*.key diradmin:diradmin 640 flag



Is the access group a default now, or do we need to add something to directadmin.conf?
 
What do you see?

Code:
/usr/local/directadmin/directadmin c |grep '^secure_access_group='

if it's empty you need to run:

Code:
echo "secure_access_group=access" >> /usr/local/directadmin/conf/directadmin.conf
service restart directadmin
echo "action=rewrite&value=secure_access_group" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin//dataskq


then run set_permissions.sh da_files again.
 
Last edited:
It was empty, ran task queue, then the permission script....... Nothing changed........

No wonder, the set_permissions.sh has diradmin:diradmin hard-coded upon inspection :rolleyes:
 
Hi guys,

We've had a few tickets on this and it appears to plausibly be enforcement of something that should have been enforced before, and the fix simply enforces some other error. So it's just exposing problems with the cert/key pairs being used, rather than silently giving up and using the server cert.

A few options can be used, so there are 3 ways to go about sorting out the issue:

  1. Simply to ensure that the cert/key pair being used for this SNI connection is valid, as it appears the invalid pair that "should fallback to the main cert"?, instead fails the handshake entirely. This is recommended.
    Martynas and I have written a script to help check your cert/key pairs, it can be found here. Instructions below.
  2. Or disable the /etc/virtual/snidomains (rename the file for now), but this means that valid ones in question would no longer work, so probably not what you want.
  3. Fallback to exim 4.91, again not a great solution.

The change log for 4.92 is here:
https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog

The change most likely to be the trigger is this one:
JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server side. Previously we would continue as if no SNI had been received.

That being said, we can see there are already a whole slew of OpenSSL related to change for 4.93 (not yet released), perhaps they're addressing it in one of those, but possibly not.

For #1, to test your cert/key pairs, use the mentioned script, like this:
Code:
wget http://files.directadmin.com/services/all/ssl/verify_certs/verify_snidomains_certs.sh
chmod 755 verify_snidomains_certs.sh
./verify_snidomains_certs.sh
note that it uses /bin/bash, so ensure you have bash present.
If there are any errors, they'll end up in verify_snidomains_certs.sh.log, right beside the script.

It's possible that the cases in question are in fact a truly broken cert/key pair, in which case it's not an exim bug at all, just either expired or no longer valid, not sure.
If you happen to hit this error and can narrow down exactly which state the cert/key pair are in (.combined is preferred over the .cert), let us know, and we could even add it a nightly check on certs if needed (although, LetsEncrypt certs are already checked, so not sure exactly what people are running in to)

Any issues, feel free to let us know so we can sort out the exact cause/scenarios, and add preventative measures if needed.

John
 
It was empty, ran task queue, then the permission script....... Nothing changed........

No wonder, the set_permissions.sh has diradmin:diradmin hard-coded upon inspection :rolleyes:

I've updated my post, as it was missing a couple of steps. Please try again.
 
Back
Top