Can't receive external email on all domains after updating SSL certificate for 1 domain

Yesterday I updated an expired SSL certificate for a domain. After doing so:

I noticed that /etc/postfix/ has some oddities at the end of the file, although I don’t have the technical expertise to understand it. But the server that I updated was the ONLY record at the end, which seemed odd. Here’s the lines I saw at the end of the file: inet n - n - - smtpd -o smtpd_tls_cert_file=/home/DOMAINNAMEHERE/ssl.cert -o smtpd_tls_key_file=/home/DOMAINNAMEHERE/ssl.key -o smtpd_tls_CAfile=/home/DOMAINNAMEHERE/ inet n - n - - smtpd

Server is CentOS 5 with latest version of virtualmin.

Any help would be greatly appreciated!

Were you using the same cert for email as you were for this web domain? This cert update may have overwritten the proper cert you were using system-wide for email. I have found this to be the case when using the “Copy to …” buttons under “Manage SSL Certificate”. It may not be possible to have more than one cert in play for the whole group of virtual servers. And verify that your DNS MX and TXT records are configured right - you might be failing identity checks.

It would be helpful to know what error message is associated with “email stopped working”, as you know there are thousands of reasons this could happen. :slight_smile: You might need to increase your log level while you troubleshoot this.

I installed a cert to the domain for and copied it to dovecot and postfix using those copy to buttons under manage ssl certificate. I am pretty sure the DNS MX and TXT records are right but to honest I’m not sure. How do I confirm this?

Does Virtualmin (you?) offer paid support? (Or do you know of anyone who can help me?)


Also, how do I increase the log level to provide you with the additional information you need? When I say email stopped working, when I send an email to an address on the server, say the mail does not get received. I do not get a bounce back either but it has been less than 24 hours though to be fair.

If i go to the user’s email account directly via virtualmin, I will not see the email in there either, so it isn’t just a matter of not being able to check my email etc.

I can’t offer my services for hire - I’m just a fellow Virtualmin user like you. :slight_smile:

I advise against using those “Copy to” buttons because what they do is not explained/documented, and there is no “revert” button to save us. They need more explanation. Last night, I was locked out of my web admin after clicking “Copy to Webmin”! Only one of your virtual server’s domain certs can be installed for ALL Virtualmin/Webmin users, and one other for ALL Usermin users. Whichever cert you install for Postfix, is also presented to your other domain email user’s client. Obviously, that’s not cool if you’re selling web & email hosting, and/or letting your customers admin their own sites. Everyone should be able to seamlessly access the admin resources using their own certs. It’s better to just leave the self-signed cert and explain away the warning. I can’t ask one customer to use another customer’s domain name to log into his own Webmin admin or Usermin email!

Troubleshooting email/DNS settings is something I run into occasionally, and manage to fix with help from forum discussions. Just be sure and include it as a serious possibility. I’m still learning, so I don’t know just what to tell you. Undoubtedly there are some good tutorials out there.

The important thing is getting error messages to work with. Perhaps you have another server machine, which you can send email from, and see what errors appear from it’s perspective?

You should “tail -F var/log/procmail.log /var/log/syslog” in a separate open terminal window while you send test emails. There is a whole bunch of further ways to gather activity data here: