Mail server has new cert but mail app sees old one

Help
1

Hi, all.

My domain is mail.burtman.net
The operating system my mail server runs on is Ubuntu 20.04.
I have root on the server and I connect via SSH.
The version of my certbot client is 2.9.0.

When I add one of the mailboxes to thunderbird or evolution mail, I get "Cannot connect because an SSL/TLS certificate for 'mail.burtman.net' is not trusted."
The details of the certificate are shown in the box below the error but there is no certificate on the server that matches those details. That's an old certificate that has been deleted. The new certificate, which has 89 days left on it and covers only burtman.net, www.burtman.net and mail.burtman.net is not being sent/received (not sure which). In any case, the result is that nobody can get to their mail.

I've been trying to fix it for hours but of all the details I can find of people talking about TLS caches in dovecot and postfix, none of them have mentioned where those old certs are or how I can remove them.

Any help would save me going prematurely bald at this point.

2

Have you restarted the postfix and dovecot services since the certificate was renewed?

Have you can run sudo rgrep "*.pem" /etc/{dovecot,postfix} to see if you can find the path to the certificates defined in your mail server configs?

3 Likes
3

Yes, both have been restarted. This command has no results. I looked for paths in some of the config files, but so far, I found nothing useful. Is there perhaps a way to force the certificate cache to renew? The old certificate must be stored somewhere besides RAM, as it is still being issued. I installed Evolution Mail, as a new application would not have any previous certs cached, but it throws the same error as TBird, so I know it's actually coming from the server and not just TBird being lazy and trying to use a stored cert instead of requesting the current one.

4

How about grepping for "*fullchain*"?

3 Likes
5

No, only brings up the current certificates and a couple of configs that mention them, but none of those refer to anything other than the fullchain paths I was expecting. :confused:

6

I don't use those mail services but Dovecot's SSL files are pointed to by this isn't it? What do these point to? (example settings below from dovecot docs)

ssl = yes
# Preferred permissions: root:root 0444
ssl_cert = </etc/ssl/certs/dovecot.pem
# Preferred permissions: root:root 0400
ssl_key = </etc/ssl/private/dovecot.pem

Sorry if this is a silly reply. I'm just wondering if someone renamed the original .pem from Certbot to like .crt or .key and forgot to do it this time.

I agree though it looks like a server problem. I checked each mail port for that domain and they all use the cert from Mar2 which does not have the mail subdomain in it.

4 Likes
7

Are there any notes from when any of the previous certs were installed into the mail system?

4 Likes
8

My preference is to update those paths and filenames to use the default values where the current certificate is stored by certbot.

4 Likes
9

Oh, I agree. Though it wouldn't be the first time someone copied the original certs somewhere else. In this thread I only saw them checking for pem files in certain folders. Seems should be able to just look in the config and see where they should be.

That said, I only know Dovecot from its docs and not any clever options that might be possible :slight_smile:

3 Likes
10

I run dovecot and postfix, but examining my configs is not presently convenient. If this is still unresolved at the time, I'll look for anything relevant when I'm at a console.

4 Likes
11

Dovecot can use the files in /etc/letsencrypt/live/ just fine from within conf.d/10-ssl.conf. Same goes for Postfix.

On my system, Postfix as wel as Dovecot start as root (for the certificates, among others) and then drop privileges to a different user.

4 Likes
12

Thanks for the replies, all.
There are no notes from any previous certificates were installed. Everything was done in the same way and nothing has been moved, copied or renamed.

Inside /etc/dovecot/dovecot.conf:
ssl_cert = </etc/letsencrypt/live/mail.burtman.net/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.burtman.net/privkey.pem

Inside /etc/dovecot/conf.d/10-ssl.conf:
ssl_cert = </etc/dovecot/private/dovecot.pem
ssl_key = </etc/dovecot/private/dovecot.key

These certificates exist at these paths. There are no other configs that appear to make a difference to this problem.

When I run
openssl s_client -servername mail.burtman.net -connect mail.burtman.net:imap

I get the output:

CONNECTED(00000003)
80722181BB7F0000: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 5 bytes and written 322 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)
---

13

I'm currently investigating the routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:354 error...

14

You say they exist in both places but are they identical files?

3 Likes
15

No, they are not the same file. Should those in 10-ssl.conf be symlinks to those mentioned in dovecot.conf?

16

Are the dates of the ones in /etc/dovecot a lot older than the ones in /etc/letsencrypt/... ?

How did they get there? Does someone copy them manually? Or do you have a Certbot --deploy-hook that maybe isn't working any more?

More info from you is better than less when describing what you see :slight_smile:

5 Likes
17

/etc/dovecot/private/dovecot.pem
lrwxrwxrwx 1 root root 36 Dec 11 2021 /etc/dovecot/private/dovecot.pem -> /etc/ssl/certs/ssl-cert-snakeoil.pem

/etc/letsencrypt/live/mail.burtman.net/fullchain.pem
-rw-r--r-- 1 root root 3664 Mar 8 00:52 /etc/letsencrypt/live/mail.burtman.net/fullchain.pem

I have not used any certbot hooks, nor disabled or modified any default hooks that may exist. Crontab is used to renew certificates on all servers. Also, I haven't modified permissions on any of these, and I see 777 on that first one, which seems like a bad idea to me.

PS: Sorry for the repeated edits. I'm not sure why some things keep getting added as quotes and some things get unwanted formatting. Trying to keep the posts simple and clear.

18

What does the ls -l look like for above file? Usually snakeoil are not useful at all but I wonder if someone overlayed that with an older valid cert as a quick and dirty fix at one time.

The 777 is fine for the dovecot.pem since that is just a symlink. The permissions on what it points to will dictate.

4 Likes
19

ls -l /etc/ssl/certs/ssl-cert-snakeoil.pem
-r--r--r-- 1 root root 1078 Dec 11 2021 /etc/ssl/certs/ssl-cert-snakeoil.pem

There haven't been any hacks or workarounds on these servers, as they were set up strictly according to guides provided by digitalocean, who provides the VMs. Until this month, everything worked beautifully.

20

Well, obviously something has changed. It is just a matter of finding out what.

At this point I will defer to other volunteers who use dovecot/postfix. It seems odd to me that you point to a snakeoil cert but it looks too old to be the wrong one being used. Your Dovecot must be finding the older Mar2 cert some way.

It would help to see output of this now. You have gotten many certs recently so might help locate where the stale ones are coming from.

sudo certbot certificates

(omit sudo if you don't need it)

3 Likes