How to get iOS email to accept cert renewals for IMAP and SMTP servers?

Help
1

Required fields are flled out below, at the bottom of this message.

The problem I'm reporting is not with letsencrypt/certbot itself, but rather, with the iOS email client not being able to process the 90-day cert renewals. I use letsencrypt certs for my IMAP and SMTP domains (email is managed on linux via dovecot and postfix). All email clients except those under iOS offer the user the option to accept the changed certificates, but that doesn't happen under iOS. Instead, a popup comes up for these users saying, "Cannot verify server identity", and no "Accept" dialog or anything similar is offered.

I know this is specific to iOS, but I'm asking here, in case anyone here has solved this.

I searched on line, but all I could find concerning iOS recognizing the renewed certs is to remove and re-create each email account on the iOS client. However, I cannot ask my multiple email users on iOS to do this every 90 days for each and every one of their email accounts on each of their iOS devices.

Is anyone using letsencrypt certificates with postfix/dovecot with iOS email clients? Has anyone been able to tell iOS to renew the cert automatically, or at worst case, by the user clicking "Accept" or something like that?

Am I out of luck, or has anyone figured out a way to get around this problem under iOS?

Thank you very much.

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

My domain is:
imap.aaa-aardvark.us

I ran this command:
Any IMAP or SMTP command via the iOS email client

It produced this output:
Popup in iOS saying "Cannot verify server identity"

My web server is (include version):
This pertains to email. not the web.
Running dovecot 2.2.13 and postfix 2.11.3

The operating system my web server runs on is (include version):
Email servers run on Debian Linux 8

My hosting provider, if applicable, is:
N/A

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):
No

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

2

That shouldn't happen at all, not for iOS and not for other e-mail clients too.

1 Like
3

That shouldn't happen at all, not for iOS and not for other e-mail clients too.

Which shouldn't happen? Offering the option, or not being offered the option?

Under my Android email client, I am allowed to accept the changed cert. Same under Thunderbird.

4

Every renewal should go unnoticed to the user. There should be no popup at all.

3 Likes
5

OK. Thank you. But my iOS email users are complaining about this. Today under Thunderbird, I got dialogs for all my clients about the cert being unrecognized, but I was allowed to accept.

Same under my Android mail client.

This is after certbot cert renewals.

1 Like
6

Well, at the moment your SMTP certificate and IMAP certificate are expired. Did you reload Postfix and Dovecot after the renewal or did you not yet renew the certificates?

1 Like
7

Oh ... I thought I renewed it. Maybe there was an error that I missed. I will check.

Thank you.

1 Like
8

I do see multiple valid certificates issued about a month ago:

However, your mailservers are still using an older certificate from back in April.

After renewal, all software using the renewed certificates should be reloaded to actually start using the new certificate.

It also seems you're getting three identical certificates at every renewal? I'm puzzled, why is that? Do you have three servers with each server getting its own certificate? If you just have a single server which is getting three certs at a time, I would urge you to delete two of those triple certificates and keep just a single certificate. More than one identical cert on the same server is wasting precious Let's Encrypt resources.

1 Like
9

Thank you. I'll fix the multiple server issue. However, first I want to get this email problem fixed. The pem files for my *.aaa-aardvark.us servers are dated June 23, and I just now restarted my email servers. Not sure if the problem is fixed now.

Trying to figure that out ...

1 Like
10

And just now you're serving the most recent certificates :wink:

It seems you're not reloading your services after renewal. You should do/fix that.

I believe your users were getting "certificate expired" warnings as soon as the certificate used by the mailservers actually expired. Even though you had a renewed and valid certificate laying around on your servers disk, the mailservers weren't actually using it. Once you reloaded your mailservers, probably for something else entirely, the current certificate was loaded and used again.

If you didn't reload your mailservers for something else, you might just have been using certificates from years ago :scream:

1 Like
11

I will fix that. Thank you again!

Now, how can I find and delete the duplicate certs? Or what do I NOT need to do in order to prevent the dups. I am renewing both *.aaa-aardvark.us and aaa-aardvark.us

Is that redundant?

1 Like
12

Please post the output of the command: certbot certificates

1 Like
13

Here's the subset of that output which pertains to those domains ...

Found the following certs:
  Certificate Name: aaa-aardvark.us
    Serial Number: 43f949706d253313f09517a2810632ddac2
    Key Type: RSA
    Domains: aaa-aardvark.us *.aaa-aardvark.us
    Expiry Date: 2021-09-21 18:12:48+00:00 (VALID: 60 days)
    Certificate Path: /etc/letsencrypt/live/aaa-aardvark.us/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/aaa-aardvark.us/privkey.pem
14

How do you mean "subset"? I was expecting to find two more certificates for those domain names, with serial numbers:

Can you triple check if those certs are also included in the certbot certificates output?

1 Like
15

By "subset", I mean that I have a few dozen domains, and so I only showed you the aaa-aardvark.us entries.

Neither of those two keys that you mentioned appear in the "certbot certificates" output.

What I showed you was the only data for the aaa-aardvark.us domain

16

So that would mean that specific server is not generating any duplicate/triplicate certificates.. But something is.. :thinking: Any idea what could get certificates for those two hostnames too?

1 Like
17

I don't know. I will check to see if there might be some old, legacy software running somewhere which might be doing this.

Anyway, assuming I figure that out and kill any old, unneeded software, how do I get rid of the extra certs?

18

No need to remove those certs once the legacy software has been fixed. Actually, once a certificate is issued, it'll keep existing on the internet forever in certificate transparancy logs :slight_smile: So you can't remove them.

Of course if you're absolutely sure no service is actually using those duplicate certs, you can remove them from your system in the legacy software, but once you disabled renewal on those legacy software, all is good from a Let's Encrypt "keeping the load down" perspective :wink:

1 Like
19

Got it. I'll get rid of any software that might be doing those spurious renewals, and I'll be careful about this in the future.

Thank you again for all your help!

2 Likes
20

By the way, to reload your Postfix and Dovecot, you could use the --deploy-hook option in certbot. Read more about that hook (and others) at User Guide — Certbot 1.16.0.dev0 documentation.

1 Like