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
CONNECTED(00000005)
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
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgISAzttNe4RnUVoYNoXsFuj4uM9MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA0MjcxMjIwMTJaFw0yMTA3MjYxMjIwMTJaMBMxETAPBgNVBAMT
CGdyZXBhLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvYtnZ1kM
ob6OqFmAuti8cfKILeWiIS/jdczS4gGa+vYqAUtbeMaFXX7YKqXEdlSfRtBDCQgw
Tq/dWq3o4wErRCZSX8N7A65fZsxJe4so+G057w6IJtREnsdPBFQiUI3yrrIe4ZJI
2iGeU7JAz3rRbigMSuyzaeqMGRkXWCGrFQpFyY7dv2mkaC001eC1Zs5XbJicQe5n
5LMWti1sR8TLq4aZYw5+WO0CNAQ0rPvrFnTzqzWfmhGFM4id/4iAJw9mj0T7isbP
M4qc65ApyMJGPk+luOZcmC48t4Y6jant0DMzy9/p9N7t+7Dj+rw3YhvpDBUKQCex
fOlbXVEb8RjaGwIDAQABo4ICQzCCAj8wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQN
fCeYyWx0wNbPvAypR67jZRLPJzAfBgNVHSMEGDAWgBQULrMXt1hWy65QCUDmH6+d
ixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxl
bmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLzATBgNV
HREEDDAKgghncmVwYS5jYTBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLf
EwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCC
AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AESUZS6w7s6vxEAH2Kj+KMDa5oK+2Msx
tT/TM5a1toGoAAABeRN8vLUAAAQDAEYwRAIgS0ceUCtT9aiFgFEuQS4EWi1LCjjr
x7REo319/0/GOg4CIAnJVbJEVR7FkUjQlZzLXQ335X5UAAsw5jyIsWbNYXRxAHcA
fT7y+I//iFVoJMLAyp5SiXkrxQ54CX8uapdomX4i8NcAAAF5E3y9hwAABAMASDBG
AiEAqyX7Q1nj6kA2ybjWZRasfkO7CUfvp3taeVk711T5oKoCIQCN5UOiG1DsqFKb
XFGUl0JkiwjdH1jDe1jcJ6qSMOH0FzANBgkqhkiG9w0BAQsFAAOCAQEAEjg8ZOGU
5I+bSn7g692JD5rhRw4Q2cb2Og6p5007wQqjjpBtse57rvkwSb3sMuaJL3+thxj5
yo61s8/GGThCggzq7yaCu7pIs5JVBKYAvDYXyNe2qDeN9dxRqBe1MOp3V72GtSur
d5tdCueb57gtZK6AzN7o2kqCFaGcBegqaRzZAPUNYbHSc5VZzCoyN9DzWb7PYJ+s
TPIo1aQwuE1uwtBn8k3JnbGEvrrVnDIUwIW49UO3K/4wv4XjgPRiF8usE99hIkBh
ldQnoAjHhq7q9PbGR2BJs+87nWQzWfVqEsFY92+JSlfdGBAOqDgRCG7Ar80sFGLy
7HEUQoIRz4sKxA==
-----END CERTIFICATE-----
subject=/CN=grepa.ca
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
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: D2F46861F4D9C568B4DB30002865B76A48CE719F99F38997E8678CEF5CA6A402
    Session-ID-ctx: 
    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)
---
250 CHUNKING
DONE

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.

2 Likes

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.

2 Likes

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

2 Likes

Nice!   

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