Exim gives a wrong version number error

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: mail.home.bouzou.org

I ran this command:
openssl s_client -starttls smtp -crlf -connect mail.home.bouzou.org:25

It produced this output:

Connecting to 192.168.1.252
CONNECTED(00000005)
001F320902000000:error:0A00010B:SSL routines:tls_validate_record_header:wrong version number:ssl/record/methods
/tlsany_meth.c:85:
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 264 bytes and written 1586 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

My web server is (include version): exim4

The operating system my web server runs on is (include version): Ubuntu 24.04.2 LTS

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 4.1.1

Additional info:
03_exim4-config_tlsoptions contains:

MAIN_TLS_CERTKEY = /etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/mail.home.bouzou.org/privkey.pem

I made sure that the Debian-exim user can access the certificate files:

sudo -u Debian-exim more /etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem

Please help

2

Normally port 25 does not use a certificate for TLS

What instructions are you following for exim?

1 Like
3

It does with starttls, which is what the openssl command is using.

I don't seem to be able to connect at all to that name from my mail server, though. And it having a private IP listed in the openssl output above is a bit odd as well.

3 Likes
5

I guess I should have been clearer. Are they sure they have configured exim to reply to TLS requests on port 25?

Just setting a cert file name isn't enough. They need the proper TLS Connect configuration: 43. Encrypted SMTP connections using TLS/SSL

4 Likes
6

I see what you're saying. My memory of openssl s_client's starttls option is that it's pretty primitive, so if the server were replying to the STARTTLS command with an error message, I could see openssl trying to instead interpret it as the start of a TLS handshake and giving that error, but not showing the error the server was actually replying with.

4 Likes
7

I've forwarded the right port and enabled port 587, so you can try connecting at mail.home.bouzou.org port 587 and tell me what you think. I'm stumped at the moment. It seems to work with the self-signed certs in the /etc/exim4 directory, but not with the ones generated by certbot. I'd really like to "do the right thing"...

Thanks in advance for any advice!

BTW, the instructions I followed are the ones at eff.org, titled

From Encrypting the Web to Encrypting the Net: A Technical Deep Dive on Using Certbot to Secure your Mailserver

(not posting a link, as that got my account deactivated last time.)

8

Does the exim log show any more info? Should be one/more mainlog files in /var/log/exim4 directory

A --debug of openssl shows this 454 TLS currently unavailable error

0000 - 53 54 41 52 54 54 4c 53-0d 0a                     STARTTLS..
read from 0x581fdfd1a2e0 [0x581fdfc71670] (8192 bytes => 31 (0x1F))
0000 - 34 35 34 20 54 4c 53 20-63 75 72 72 65 6e 74 6c   454 TLS currentl
0010 - 79 20 75 6e 61 76 61 69-6c 61 62 6c 65 0d 0a      y unavailable..

I am pretty sure exim allows ECDSA certs but you might try re-issuing your cert as RSA.

PS:

I think you had a post rejected because it was ONLY a link. Such posts look like spam. Giving a link within a post with other info should be fine.

3 Likes
9

Ok, so I tried re-issuing the certificate as RSA, but I still get errors:

  • Running openssl s_client -starttls smtp -crlf -connect mail.home.bouzou.org:587 gives:
CONNECTED(00000003)
40E70AD39D700000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 280 bytes and written 355 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

and in /var/log/exim4/mainlog, I see

2025-07-19 14:37:34 TLS error on connection from iad1-shared-b8-42.dreamhost.com (mail.example.com) [173.236.245.64] (cert/key setup: cert=/etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem key=/etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem): The requested data were not available.
10

I think this is likely a permissions problem. I believe that exim is complaining that it cannot read these files:

Those ../live/.. files are just symlinks to files in ../archive/..

The symlinks are readable by all (usually) so check permissions on /archive

2 Likes
11

They were wrong for the new certificate, so I fixed them. Now

sudo -u Debian-exim ls -l /etc/letsencrypt/archive/mail.home.bouzou.org/

gives me

total 32
-rw-r--r-- 1 root Debian-exim 1302 Jul  5 14:49 cert1.pem
-rw-r--r-- 1 root Debian-exim 1801 Jul 19 14:00 cert2.pem
-rw-r--r-- 1 root Debian-exim 1566 Jul  5 14:49 chain1.pem
-rw-r--r-- 1 root Debian-exim 1801 Jul 19 14:00 chain2.pem
-rw-r--r-- 1 root Debian-exim 2868 Jul  5 14:49 fullchain1.pem
-rw-r--r-- 1 root Debian-exim 3602 Jul 19 14:00 fullchain2.pem
-rw-r----- 1 root Debian-exim  241 Jul  5 14:49 privkey1.pem
-rw-r----- 1 root Debian-exim 1704 Jul 19 14:00 privkey2.pem

and

sudo -u Debian-exim more /etc/letsencrypt/archive/mail.home.bouzou.org/fullchain2.pem

prints out the file. But I still get the same error. What am I missing?

12

Well, not wrong for Certbot but maybe not what you need for your system :slight_smile:

I think you'll need to ask on an exim support channel. See: GitHub - Exim/exim: Exim Mail Transport Agent - source, testsuite and documentation

Make sure you have followed the instructions here: EximServerSslCertificate · Exim/exim Wiki · GitHub

I don't see anything wrong with your certs. I don't know if Certbot will retain the chgrp for the next renewal. I just don't remember how it handles that. Usually if you want special perms you should copy the cert files you need and update them in your own location. Use a Certbot --deploy-hook to automate that. That is, generally best not to modify the files within the Certbot directory structure.

2 Likes
13

This looks like it's trying to use the same file for both the cert and the key? Are you doing some hook to put both in the same file?

In general, if certbot's files aren't doing what you want (in content, or permissions, or whatever), it's best to leave them alone and use a deploy-hook to copy them somewhere else, with the permissions and format you need, so that you're not messing with certbot's internal stuff.

3 Likes
14

Good catch! That's strange because my /etc/exim4/conf.d/main/03_exim4-config_tlsoptions file reads:

MAIN_TLS_CERTKEY = /etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/mail.home.bouzou.org/privkey.pem
2 Likes
15

Did you do the update-exim4? Isn't that needed with split config?

Otherwise that could be a bug in the error message. That all said, this still is better handled elsewhere. Maybe even ServerFault or something.

3 Likes
16

I found it! It turns out that I was setting MAIN_TLS_CERTKEY, which sets both cert and key to the same value. Changing the setting in 01_exim4-config_listmacrosdefs to

MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/mail.home.bouzou.org/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/mail.home.bouzou.org/privkey.pem

solved the issue.

Victory! Thanks for your time, guys!

3 Likes
17

Now that it's working be sure you review my earlier comment. I just ran a test with the current version of Certbot and it will NOT retain permission changes to the group of the fullchainX.pem file in /archive. It will for the privkey but not fullchain.

Interestingly, I couldn't find that certkey setting in any of the docs for exim. But, I did see a comment in the exim4 template config about it. I include it here for future reference.

# Full paths to Certificate and Private Key. The Private Key file
# must be kept 'secret' and should be owned by root.Debian-exim mode
# 640 (-rw-r-----). exim-gencert takes care of these prerequisites.
# Normally, exim4 looks for certificate and key in different files:
#   MAIN_TLS_CERTIFICATE - path to certificate file,
#                          CONFDIR/exim.crt if unset
#   MAIN_TLS_PRIVATEKEY  - path to private key file
#                          CONFDIR/exim.key if unset
# You can also configure exim to look for certificate and key in the
# same file, set MAIN_TLS_CERTKEY to that file to enable. This takes
# precedence over all other settings regarding certificate and key file.
4 Likes
18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.