I've relinked those certificates to the new ones issued to mail.burtman.net and I no longer have issues connecting new mail accounts. It looks like certbot linked the new certificates to the archive for some reason (because I certainly didn't), so even updated certificates were pointing at the old ones.
I still see the SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354 error but mail is accessible without certificate errors now, which was the biggest issue.
I will continue to investigate the other issue, as it doesn't appear to be related to certbot.
Thank you all kindly for your help. I always appreciate people taking time to help others.
can you describe what you mean by "I've relinked those certificates"
Because as earlier pointed out you should be able to point dovecot directly at the correct /etc/letsencrypt/live/ folder cert files. There shouldn't be any need to copy them or "relink" them
However, since the certbot certificates command shows the certificate path as... Certificate Path: /etc/letsencrypt/live/www.burtman.net/fullchain.pem Private Key Path: /etc/letsencrypt/live/www.burtman.net/privkey.pem
... I found that those paths were symlinked to the archive dir.
I'm not sure why this path is still being used, but since it's only a symlink, I relinked those files to their equivalents in the correct mail.burtman.net dir and now it all seems to be working.
As my main concern is getting mail working, this will do for now.
I will now create a server snapshot and play with configs on an offline clone and if I can safely make this correct, I will push those settings to the production box.
Yes, Certbot symlinks the /live to the /archive for that cert. This is also saved in the renewal config file in the /renewal folder.
If you manually change these folders you will almost certainly have a broken system. All Certbot folders are matched. You could copy the files pointed to by /live/ somewhere else if you wish but you should not be changing the symlinks or paths in these folders.
Why can't you just change the above and point directly to the valid /live/ folder that Certbot is managing? @Osiris noted earlier this works.
I don't agree with you that the dovecat paths were ok. If they were okay they wouldn't have been using the wrong cert.
You may have something working now but at the next renewal this is likely to be broken again.
I'm not sure I understand this. Why does it point to the archived cert? This seems to be the reason the server is issuing old certificates instead of the new one.
As far as I can see, the mail.burtman.net directory is the valid one.
The archive directory contains all the certificates, old ones and the latest, current one too. The live directory has a symbolic link to the latest certificate in the archive directory. You should always refer to or copy from the live directory. Do not interfere with the link in the live directory, the ACME client takes care of updating it if required.
Congratulations, you've now destroyed the inner workings of Certbot.
As you could have seen in the certbot certificates output, your certificate with the name www.burtman.netALSO contained the hostname mail.burtman.net. So that was just fine.
You shouldn't have your SSL directives listed twice in your dovecot config files. The incorrect certificate in the conf.d/10-ssl.conf file was taking precedence due to being processed last. That is the right place. It just had the wrong values while the right ones were in the wrong file.
Dovecot moved from using a single config file to using a conf.d folder approach a long time ago. Most changes should be placed in the correct file under the conf.d folder and not in the dovecot.conf file.
For future analysis of dovecot configs, you may want to use doveconf. It can show you the value that will be used by dovecot. This can be helpful if your confg contains mutiple instances of the same setting that hold conflicting values. Review the doveconf man page to choose the appropriate flags for the desired output.