Certificates renewal and Apple OS Mail

Hi All,
I apologize in advance because the topic is quite similar to this topic, this topic, this topic and this topic. However, the solutions provided do not seem to apply to my case.

I use postfix/dovecot as our mail server on grepa.ca. There is no issue with everything that is browser related. However, each time the certificates expire, Apple clients (mail on Mac OS, Mail on Apple OS, etc.) complain that the certificates can no longer be trusted. The problem does not seem to pervade to Windows/Linux clients, or third party mail clients installed on Android (e.g. Nine).

I have found two "solutions" thus far:

  1. Asking clients to delete and re-install their email accounts. (known to work).
  2. Each time the certificates are renewed, restart postfix and dovecot. I think this second option reloads both daemons with the latest certificates, but I do not know yet if it works (I will have to wait three months).

Obviously, workaround 1 is not a viable one from a client/customer perspective. As my server is not hosted with Plesk the discussion on the plesk forum is not really applicable to my case. My assumption is also that Apple has some better knowledge than me on the management of certificates, which leads me to think that I probably have a configuration issue.

That being said, the problem is beyond my expertise. I am happy to provide any details to help resolve the matter.

This is always required after certificate renewal and that includes webservers too. However, not everyone knows this, as for example the nginx and apache installer plugins of the certbot ACME client reload the webserver during the installation part of their activities, including at renewals. So for some users, this just happens without their knowledge. However, a reload is always mandatory and for services such as Postfix/Dovecot, this has to be done manually or through a --deploy-hook in certbot.

1 Like

This, in some form, is going to be necessary with any service that uses a certificate--when you get a new cert (and a "renewal" is still a new cert--same information, different dates), you need to tell the service to use the new cert. Some services (most web servers, for example) have a mechanism to "reload" the configuration, which will re-read the server's configuration files and certificate(s) without service interruption--I don't know if postfix or dovecot support this. Otherwise, simply restarting the service should work.

The problem this will solve is if your mail server is still serving the old cert after a new cert has been issued. If the problem is instead that the new cert isn't being recognized (i.e., you're serving the new cert, but the client system doesn't like it for some reason), this won't help you.

Edit: At the moment, postfix is serving a certificate issued a month ago to your domain name:

 dan@Dan-MacBook-Pro-2013  ~  openssl s_client -starttls smtp -crlf -connect grepa.ca:587
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = grepa.ca
verify return:1
Certificate chain
 0 s:/CN=grepa.ca
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
issuer=/C=US/O=Let's Encrypt/CN=R3
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
SSL handshake has read 3286 bytes and written 324 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: D2F46861F4D9C568B4DB30002865B76A48CE719F99F38997E8678CEF5CA6A402
    Master-Key: 60C8182E1FB743803D92055A62FACF2CBF1657E7B8F127C9DFA30105E52C5D7D5146B35446308AC93AC37C869E4A8A0D
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 7a 81 a5 e4 7a 32 cb 9f-14 48 6f f3 58 4d 20 a2   z...z2...Ho.XM .
    0010 - 8a e6 cf 5b 4c 73 a1 ad-55 c0 70 d2 84 6d cf 69   ...[Ls..U.p..m.i
    0020 - 78 9f 5d f2 ac 8b dd 9e-9c 09 06 8c 6f c7 e8 83   x.].........o...
    0030 - 61 43 c9 ab 0a 37 99 7a-35 f1 a5 06 07 64 86 1b   aC...7.z5....d..
    0040 - 98 04 16 bf 5a f2 c6 ec-c2 bf 91 82 ad 39 4d 83   ....Z........9M.
    0050 - 34 da d2 c9 1e 10 7d 46-0f 3b c8 b5 6e 2a da b7   4.....}F.;..n*..
    0060 - 8b d9 a4 c1 ff 82 11 6b-6d e7 07 c4 de c8 f3 00   .......km.......
    0070 - 94 19 13 ba 1b ef ee ce-a2 e8 73 78 c9 c3 37 fb   ..........sx..7.
    0080 - 29 6f 04 06 c3 99 3f 00-ce 1d 1a 64 cc 61 ee 82   )o....?....d.a..
    0090 - 3c 6e 6f 0a 3b 82 27 c0-86 63 49 ad 75 cc f1 e6   <no.;.'..cI.u...

    Start Time: 1622129071
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

I then pasted the cert into Certificate Decoder - Decode certificates to view their contents to get the valid dates; openssl can do this for you as well, but I don't remember the incantation to make it do so. But right now, it's looking good. To test before three months are up, you could force-issue a cert now, reload postfix, and try the same check to see if it's serving the new cert.


A simple postfix reload would suffice and on my Gentoo my Dovecot init script also has a reload option. The latter seems to be sending the HUP signal to Dovecot somehow.

This seems to be the problem. As I embed my certbot renew commands within a broader shell script, I simply added the systemctl restart [posftix/dovecot] commands at the end of the script.

Yep, I just reloaded the deamons.

Thanks very much for the fast and supportive answers. I might come back in 59 days... :slight_smile:

1 Like

Note that restart could theoretically lead to a supersmall amount of downtime. It might be wise to check if the systemctl stuff also has a reload command for postfix/dovecot.


They do. I replaced the restart with the reload verb in the script.



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