Iphone 5 not renewing certificate


i dont know where the problem is
LE is working fine, certs get renewed etc etc.
But every time the old certificate is renewed im getting complains from apple users that the have prolem with there emails.

The certificate is renewed after 60 days.
The problem starts when the old certificate expires (so 30 days later)

The server has allready installed the new certificate fine. So it is a problem with iphone/apple
Looks like they store the certificate and dont renewed them?

Anyone else have this problem?

Hi @Steffan,

Please let us know the specific domain name, and ideally also a screenshot of the error message people see on the iPhone. There are so many different reasons that a certificate can be misconfigured


so it would be really helpful to be able to see the specific error here.

The problem here is that there is nothing wrong with the certificate
tested it with tlscheck.com
only apple has problem with it after the 3 months.
All other moments there is no problems

so the iphone (5) imac is not taking the new certificate but is keeping the old certificate and after that email cant be collected with ssl (mail.tofmail.eu) is the mailserver name.

I dont have screenshots but the message was

identification of ‘mail.tofmail.eu’ cant be checked
check of SSL-server ‘mail.tofmail.eu’ not possible

It looks like your web server serves the intermediate cert as it should, but your IMAP server doesn’t. When I do openssl s_client -connect mail.tofmail.eu:993, it only serves the leaf cert.

im using this configuration in postfix

smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_CAfile = /etc/letsencrypt/live/mail.tofmail.eu/fullchain.pem
smtpd_tls_CApath = /etc/letsencrypt/live/mail.tofmail.eu

lrwxrwxrwx 1 root root 46 Oct 7 2016 smtpd.cert -> /etc/letsencrypt/live/mail.tofmail.eu/cert.pem
lrwxrwxrwx 1 root root 49 Oct 7 2016 smtpd.key -> /etc/letsencrypt/live/mail.tofmail.eu/privkey.pem

and in
ssl_cert = </etc/letsencrypt/live/mail.tofmail.eu/cert.pem
ssl_key = <//etc/letsencrypt/live/mail.tofmail.eu/privkey.pem

So what do i have to add?

i changed ssl.conf to
ssl_cert = </etc/letsencrypt/live/mail.tofmail.eu/fullchain.pem

then im getting Verify return code: 20 (unable to get local issuer certificate)
but that choeld be fine i think reading another post?

but is that a fix for the iphone problems?

I think it should be, at least on the IMAP side. I haven't checked SMTP though.

well i will see then in 2 months when the certificate expire :slight_smile:

For Postfix, smtpd_tls_cert_file should be the path to fullchain.pem and smtpd_tls_key_file should be pointing to privkey.pem. the tls_CA parameters should not be using Let’s Encrypt items, they are used to verify external server certificates.

For Dovecot, ssl_cert should be pointed to fullchain.pem and ssl_key to privkey.pem.

Your problem looks to be that you’re not sending the full chain with Dovecot, and it seems like you’re not sending the LE certs with Postfix at all.

1 Like

im sorry you lost me.

What do i have to change acording to you.
dovecot is now pointing to fullchain.pem

if i do
openssl s_client -showcerts -connect mail.tofmail.eu:993
im getting lets encrypt returned

you say “Your problem looks to be that you’re not sending the full chain with Dovecot, and it seems like you’re not sending the LE certs with Postfix at all.”

what do you want me to change:
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.tofmail.eu/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.tofmail.eu/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/mail.tofmail.eu/fullchain.pem
smtpd_tls_CApath = /etc/letsencrypt/live/mail.tofmail.eu

I can confirm your Dovecot configuration looks good now. I’m getting the full certificate chain on connect.

Remove the smtpd_tls_CA* lines. Those are used when Postfix needs to validate a remote server’s certificate. Change smtpd_tls_cert_file to point to fullchain.pem. That should get you serving all the correct certificate chains to the clients. As long as those clients support the DST Root, they will work fine.

Keep in mind that if users are connecting using a name that is not in the certificate, they will get a warning because of the name mismatch.


thanxs hopfely that wil fix the iphone problems

are you restarting Dovecot after updating the certificate?
If I remember correctly Dovecot reads the TLS related files only once on startup before dropping root privileges, so if you in the meantime update your certs without restarting the server, it will continue to use the old ones.
But in this case the issue ought to affect all your users, not just the iPhone/Apple ones, so I may also be misjudging the problem.

Yes it is restarted.

Only iphone costumers

Don’t know how many clients are using iphones.

Can you perhaps get any more information about the configuration that the iPhone users use, and the error message that they get when they try to connect?

multiple users with iphone 5
i dont know if all users are a iphone 5.
The error message that they recieve is:
(translated from dutch to englisch)

Identification of mail.tofmail.eu cant be checked
Checking of SSL-server mail.tofmail.eu not possible

from one user i had screenshots
They are using the servername as hostname.
Has SSL enabled
And is using port 587 for outgoing email.

Hi @Steffan,

I don't use Postfix nor iPhone so I don't know what are the configuration options you have but something you should check:

Your smtp server listening on port 587 is not starting a TLS negotiation directly, it starts the conversation in plain text and it offers start a TLS communication if the client uses STARTTLS.

I mean, if you try to connect with a client using TLS directly you get this "error":

 $ openssl s_client -connect mail.tofmail.eu:587
6870300:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:787:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 7 bytes and written 517 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

If the client supports STARTTLS the there is no problem at all:

$ openssl s_client -starttls smtp -connect mail.tofmail.eu:587
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate chain
 0 s:/CN=mail.tofmail.eu
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
No client certificate CA names sent
SSL handshake has read 3571 bytes and written 742 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 3FAA4D41FE79556D43FFB3A7CAEB42242BD9CA55EB67FE24FD5FFC2895C6B72E
    Master-Key: F95DE63A8A2CBD60E021D37A472E1C137F9E121175C52D3737FE858D03065655EFF07F396F36E257A9E5363F84B920CA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 3600 (seconds)
    TLS session ticket:
    0000 - fb 5b 41 0a e3 e5 29 63-e2 28 a9 01 c7 78 bd 9c   .[A...)c.(...x..
    0010 - eb 58 5c a3 23 eb a7 85-59 65 10 f3 d0 50 27 6d   .X\.#...Ye...P'm
    0020 - 60 25 bf 93 3c ab 1f 13-50 07 0f eb ac aa 75 21   `%..<...P.....u!
    0030 - 76 0e 92 c0 9b ee 7a 16-00 09 b8 14 53 34 1c 5b   v.....z.....S4.[
    0040 - 40 02 c2 ee 7e 2f f3 78-5f ba cd 52 99 9d b3 f9   @...~/.x_..R....
    0050 - 58 de 6a 3d c5 81 b8 57-70 49 09 c6 59 38 90 cb   X.j=...WpI..Y8..
    0060 - a4 e0 2a 90 14 85 52 7c-14 5e 80 e5 34 f4 c2 d6   ..*...R|.^..4...
    0070 - 9d 55 c9 fd 5c b6 01 e2-11 10 4b fb c2 94 86 b7   .U..\.....K.....
    0080 - 01 f5 b6 92 5b 72 6a 06-91 3b b4 ae 65 96 35 c0   ....[rj..;..e.5.
    0090 - a0 79 0d 40 be bf f3 12-01 08 3f 37 25 6e 81 0d   .y.@......?7%n..

    Start Time: 1503391171
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
250 DSN
ehlo test.com
250 DSN
221 2.0.0 Bye

That said, I don't know how the iOS mail app is trying to connect to your server when you select SSL and port 587, don't know if it is smart enought to select STARTTLS if it detects that the communication to that port is unencrypted. So, maybe you could ask the customer to try to activate SSL and use port 25 just in case the mail client can detect it and ask the user if he/she wants to use STARTTLS.


I know mailprogramms are abusing the names ssl, tls and starttls.
The mailaccounts normaly works
only on the days the old ssl expire this problems start to turn up
so it cant be the configuration of the mailclient.

When te user switch the hostname and after that change it back the cert is getting reread bij the iphone and it works again.

Its very strang, and i also dont own a iphone to test :frowning:

1 Like

If you’re still having issues, I do have an iPad I can use to test. As it’ll require an account temporarily so it can be configured on the device, you can send me a PM if you would like.

Please keep in mind the usual warnings about sending account information to strangers on the internet.

Just some findings… may be completely unrelated to your problem and it’s solution - but I thought I would mention them.
iPhone email connections use 587 and 993.
Checking on
found these ciphersuites (there may be others):
DHE-RSA-AES256-GCM-SHA384 Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-AES128-GCM-SHA256 Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-AES256-SHA256 Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-AES128-SHA256 Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-AES256-SHA Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-CAMELLIA256-SHA Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-AES128-SHA Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-SEED-SHA Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits
DHE-RSA-CAMELLIA128-SHA Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits

Using ciphers with 1024 bit DH primes as preferred can cause problems on systems that require higher DH primes as that parameter is NOT negotiated between client and server.

iOS 10 no longer supports DHE ciphers, so that should not be part of the problem with an updated iPhone 5.
(iOS 8 however does support DHE ciphers)

If at all possible, I would add ECDHE ciphers and prefer them on the list.
And remove any outdated or unused ciphers and protocols - to avoid things like downgrade attacks.