HTTPS fine, SMTP not

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: n/a

It produced this output: n/a

My web server is (include version): n/a

The operating system my web server runs on is (include version): Centos 6.10 kvm

My hosting provider, if applicable, is: JustHost

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): mixture of cPanel/WHM 82.017 and root shell

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


I am NOT an experienced server admin. I paid for this VM exclusively to avoid having my mail server blacklisted every time JustHost let another spammer onto their shared hosting.

I installed a letsencrypt certificate some time back, and it has been working for all services and auto-renewing fine.

Today, I started getting messages that the certificates were bad on my SMTP service. Instead of the mail client seeing my certificates, it seems to be fetching a generic justhost certificate.

I see my certificates were auto-renewed two days ago. About a month ago, I transferred two of my domain names (that were also on my combined certificate) to another organization, without recreating my existing certificate, which may or may not have had something to do with this issue.

I went back and used the instructions at to recreate the certificate from scratch. It worked 100% fine with no errors (a first for me). The certificate it created appears to be just what I asked for. However, it seems to apply only to apache and web traffic. My mail server is apparently still using the certificate generated two days ago, which appears to have all the right information in it (according to WHM) but in practice my mail client is giving me messages like, “Mail can’t verify the identity of the server… the certificate for this server is invalid…” and showing a generic justhost certificate in the details.

I tried using WHM to replace the existing mail certificate with the one I created today, but WHM allows you only to “browse” existing certificates, and apparently the places it browses don’t include /etc/letsencrypt.

Is the certificate I have suitable for use by EXIM, Dovecot, Calendars, etc., or is it only good for HTTPS traffic? If the answer is yes, how do I get WHM to pick it up?

1 Like

While researching what version of WHM I was using, I came across the following notes in the change log, which are also suspiciously coincident with my problem:

Change Log for 82.0.17

Entry: 2019-10-21, 17:30 (UTC)

  • Fixed case CPANEL-28797: Ensure that MySQL 5.6 dependencies are met during initial system installation.
  • Fixed case CPANEL-29522: Update rpm.versions for cpanel-phpmyadmin 4.8.5-5.cp1180.
  • Implemented case CPANEL-29751: Suppress “reset_autossl_provider” API and UI control.
  • Implemented case CPANEL-29782: Better handle LetsEncrypt Errors in AutoSSL interface.

Note that I have examined the logs for days in which certificates were upgraded, and no actual errors were apparent, just what looks like normal reissuance activity.

1 Like

Hi @macsrwe

checking your domain I don’t see an error -

Your ssl mail port 465 has the correct certificate


checking your other ports via OpenSSL + Starttls

Sample Port 143 - IMAP
openssl s_client -connect -servername -starttls imap

there is always the new certificate visible (25 - SMTP, 110 - POP3, 143 - IMAP).

One thing is curious: Your last 3 certificates:

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2019-10-20 2020-01-18,,,,,,,,, - 10 entries duplicate nr. 1
Let’s Encrypt Authority X3 2019-10-20 2020-01-18,,,,,, - 7 entries duplicate nr. 1
Let’s Encrypt Authority X3 2019-09-30 2019-12-29,,,,,,,,,,, - 12 entries

But your website uses another Letsencrypt certificate:
expires in 89 days,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, - 
37 entries

Or you use a subdomain mail … or another name and that name doesn’t have the correct certificate.

Your mail server (Imap) uses the certificate created 2019-09-30.


The answer is an undoubtedly YES.
Now… HOW is always particular to the system your on and the services it runs and the controls that manage them.

If all else fails, try rolling up your sleeves and going in under the hood (if your up for that kind of stuff).

Yes, I explained the different certificate for the website in my initial post. I tried regenerating a fresh certificate today with only the proper hostnames in it, and was successful, but the certbot script installed it only for apache, which is why things are in this state.

I don’t know what tool you used to obtain the output for “Your ssl mail port 465 has the correct certificate,” but if you would tell me what it is, I’d like to use it to check the same information for the mail servers I am actually using on that host, such as (mail.), (mail.), and a couple others. (There is indeed a mail server for, but I don’t happen to use it for anything.)

Thanks for the info.

Ouch! I guarantee you I would break something.

I’ve sussed out where in the hierarchy WHM looks for certificates (/home/username/ssl/certs), and I thought of simply copying the new certificates there and having WHM pick them up, but the file structure is entirely different. It is full of files named each-hostname_hexjunk.crt(.cache), while the files certbot created all end in pem. I can’t find any pems anywhere under /home/username/ssl/certs, so I’m FUDded out right now.

1 Like

Then maybe you can hit the books (or web search engines) and find a “HOW TO” on WHM and its’ cert uses.
I can’t spell WHM, so, I won’t try to direct you in anything related.

Normally you shouldn’t use cPanel and Certbot parallel. That may be part of the problem. Perhaps cPanel has created the correct certificate, your Certbot creates a certificate with missing domain names -> that crashes. If you use a cPanel with Letsencrypt support, let cPanel do the job.

The link is already shared


The problem is that cPanel refreshes the certificates only when they are about to expire. I can’t force the re-creation or re-installation of the certificates when I see that something is wrong. The only way I could find in your wiki to create a known-good certificate was using certbot, so I followed those instructions.

It looks like I bumbled my way through to a solution, or at worst, it appears that at least everything is working now, however fragile it might be.

1 Like

Fixing things as they break is the best way to learn! Sorry this comment is a couple of weeks late, and I hope I’m not misunderstanding what you posted or telling you what you already know.

To explicitly state how mail works, SMTP doesn’t go through Dovecot, it goes direct to Exim. The Let’s Encrypt certificate needs to be configured separately for each since they do different tasks.

When you check your mail, it’s Dovecot that’s retrieving it. That’s easy to understand and is straight forward. Your Let’s Encrypt certificate ensures your password is sent to the server securely, and mail is retrieved the same way. This is generally done via IMAPS.

But when you send mail, your mail client (e.g. Thunderbird, Roundcube, mobile client) connects directly to Exim. Your mail doesn’t pass through Dovecot at all. Then Exim will connect to the external mail server to pass your mail on. So you need to configure Exim to use your Let’s encrypt certificate too. In this case, your certificate is used to encrypt your mail while it’s in transit between your Exim server and the external server, not just you and your Exim server. Only sending mail is done via SMTP.

It gets messier. For authentication (ensuring “macsrwe” sent the mail, not somebody pretending to be you), Exim will often use Dovecot to verify username and password. When Exim receives mail to send along with username and password, it will pass the authentication step over to Dovecot, but not the mail.

So when you send an email, your mail client will connect directly to Exim and hand over the mail, Exim will then ask Dovecot to confirm your username and password, and only once confirmed by Dovecot will Exim actually connect to the external mail server and send your mail.

You said in your initial post that you’re not an experienced admin. I’m not either! I’m just an enthusiast that set up my first personal mail server back in 2004. It was up and running for YEARS before I realised just how insecure my configuration was.

Wrapping your head around what-connects-to-what-and-why is the steepest learning curve with mail. Once you’ve got that right in your head, suddenly it becomes obvious why all the online guides provide the various configuration tips they do.

Good luck! (I only wrote this because you worded your question in a way that made it sound like you thought Dovecot handled SMTP - nope, that’s purely Exim!)

1 Like

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