there is only one file: dovecot.pem and the date is from April 20, 2022. When running dovecot -n under the protcols = imap pop3 section there is an ssl_cert = </etc/pki/dovecot/certs/dovecot.pem. When running the following command:
We get the certificate that matches what’s in the dovecot.pem file. Seeing as how we have requested a new SSL cert, the file date on dovecot.pem should be today’s date, but it is not. How do we get this to a new valid cert? Under the “Current Certificate” tab in the SSL Certificate page for domain1.com in Virtualmin the line for “Used by services” has Webmin, Usermin, and Dovecot listed.
So, is there a way to manually copy a cert? If so, what cert do we use and where is it located? Finally, if we have to manually copy the cert this time, what happens in a few months when Let’s Encrypt renews again?
One thing not tried:
Go to another domain on the server and click the button for “Copy SSL Certificate to Services” for Dovecot. Then go back and do it for domain1.com. Not sure if this would just make things worse.
Dovecot was working fine until the cert expired for all clients using the domain1.com for in&out going mail servers. When asking the for a cert from Let’s Encrypt through Virtualmin it executes just fine, you can even see the updating of Apache in the status, just don’t see Dovecot updating. Its like the script skips Dovecot when the new cert comes in.
I also had all kinds of problems with Let’s Encrypt on CentOS 7 (though not that particular problem). They never seemed to update automatically. I always figured it was because I updated Postfix outside of Virtualmin to get ANI. But I guess not.
I understand that Niel (@calport) is a mail guru extraordinaire. Perhaps he can help.
Thanks Richard for the compliment. It gets harder to keep up with the tech as I age and I hope I will be able to live up to the labels that you have so generously assigned to me but I will try.
Does anyone know how the script for Let’s Encrypt creates the “pem” file for Dovecot? I’m wondering if I could just replace the contents of the cert for domain1.com’s apache file into the current dovecot.pem file.
Another thought might be to delete the current dovecot.pem file (by simply renaming it) then rerun the Let’s Encrypt to get a new cert and see if it just creates the missing file on its own.
renamed the dovecot.pem file to something else and requested a new certificate thinking that would update/recreate the “pem” file. DID NOT WORK.
Turned off SSL for the domain1.com account and then added the service back and requested a new certificate thinking that would update the “pem” file. DID NOT WORK.
Copied the dovecot.pem file and renamed. Then opened the original dovecot.pem file and pasted in the certificate values found in /home/domain1/ssl.cert. Restarted dovecot. DID NOT WORK.
Noticed that there are two other domains on the server that have dovecot listed in “Used by services” on there individual SSL Certificate Virtualmin pages.
Saw in /etc/dovecot/conf.d/10-ssl.conf that the lines for “ssl_cert”, “ssl_key”, and “ssl_ca” have a " < " in front of the path names. Removed these and tried to restart Dovecot. DID NOT WORK.
So, now I have reached the limit of Let’s Encrypt requests and have to wait until the 14th to try again. I still DO NOT have solution as to why the SSL cert is not getting copied over to Dovecot. All of my Outlook and iPhone users are getting frustrated with the connection for email not working correctly.
I’m just not sure which ones to use for dovecot. We haven’t had any problems until this summer. Our Dovecot cert that is there is not (the one that is expired) is from the late spring. It expired in July. We have done several rounds of updates to Virtualmin after the last renewal. I suspect something in a script must have changed and when the Let’s Encrypt script renewed recently it failed to make the copy. Don’t want to manually do this, loved the way it used to work.
When one clicks the “Copy SSL Certificate to Services” button (for Use this SSL certificate for requests to this domain in Dovecot) on the SSL Certificate page for a domain in Virtualmin, what files get updated on the server?
So here’s something interesting. When we run the command
dovecot -n
We get a list of a bunch of “local_name” in the dovecot config. But not all of our domains hosted are listed. And what’s even stranger, we tried removing SSL from a domain thinking it would remove all of the places where a SSL cert would be used, like Dovecot, and the domain is still listed in the output even after restarting Dovecot once the domain’s SSL cert was removed.
I assume that this output should only have one domain listed in it if the Dovecot is only assigned the server’s host domain as the IN/OUTPUT server for mail, right?
Since we have a bunch of domains and a few subdomains listed in the output of dovecot -n we set out to remove all of the domains from the output. To do this we do the following:
Virtualmin >> select a domain >> Edit Virtual Server >> under "Enabled features" we uncheck the "Apache SSL website enabled" box >> save buttons >> Server Configuration >> SSL Certificate >> then click the "Delete SSL Certificate" button >> restart Dovecot
Then after each domain has been removed, we go back to Edit Virtual Server and turn the “Apache SSL website enabled” box back on. This will request the a new SSL cert from Let’s Encrypt and this time Dovecot is not listed in the “Used by services” section of the Current Certificate tab. And the domain does not show in the output of dovecot -n.
INTERESTING PART: when attempting the above for a subdomain, the removal works fine. But when we tried to turn SSL back on, Dovecot was added to the “Used by services” section and appears in the dovecot output. It appears that the subdomains are forced to have Dovecot applied an SSL cert. We verified this by creating a completely new subdomain and as soon as you activate the “Apache SSL website enabled” box, Dovecot is assigned the new cert.
I’ve deployed numerous Virtualmin instances & the letsencrypt options always have issues at some point, unreliable.
I deploy a script into /etc/cron.daily to run all renewals daily & cycle related services only upon detected certificate changes.
The certs paths are changed either directly in the /etc/webmin/miniserv.conf or through the UI in a few places for both webmin & usermin - SSL Encryption > SSL Per-IP
I personally prefer postscreen configured instead of the offered greylisting option etc.
Our original issue is that we are getting an expired cert when accessing dovecot with Outlook or and iPhone. And we have gone down the rabbit hole trying to figure out why and where the expired cert is and what the best/automated way to keep it update should now be.
This isn’t a complete example but something like this
#!/bin/bash
#
#
RESTART_SERVICES=0
domains=( www.example.com admin.example.com mail.example.com imap.example.com smtp.example.com )
for var in "${domains[@]}"
do
certbot certonly -a webroot -i apache -w /var/www/html -d ${var} --debug-challenges -vvvv --email user@domain.com --agree-tos --renew-by-default -n
if [ $? != "0" ]; then
RESTART_SERVICES=1
fi
done
if [ $RESTART_SERVICES != "0" ]; then
echo "Apache2 daemon will reload for updated SSL certificates"
systemctl reload apache2
fi
exit
Of course this just recycles the apache service but in production all the related services would be recycled, apache2/nginx, postfix, dovecot, webmin, usermin, etc…
You stated dovecot with outlook or iphone. I assume you are referring to the connection to IMAP or POP. I imagine your SMTP connection complains about the cert not matching?
Use nmap or openssl to verify your certs nmap -sV -sC -p 993 hostname.whatever.com
cycle through each port to verify the cert response etc.