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?
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
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.
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.
and in
/etc/dovecot/conf.d/10-ssl.conf
ssl_cert = </etc/letsencrypt/live/mail.tofmail.eu/cert.pem
ssl_key = <//etc/letsencrypt/live/mail.tofmail.eu/privkey.pem
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.
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.
Hi,
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.
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?
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
CONNECTED(00000003)
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:
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
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 mail.tofmail.eu:587 mail.tofmail.eu:993
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
AES256-GCM-SHA384
AES128-GCM-SHA256
AES256-SHA256
AES128-SHA256
AES256-SHA
CAMELLIA256-SHA
AES128-SHA
SEED-SHA
CAMELLIA128-SHA
IDEA-CBC-SHA
EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA
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.
