Since yesterday afternoon, the Mail program of my macOS complains that it can validate the certificate of my imap server.
The weird thing is that I could access my imap mail account for months without problem. I renewed the certificate the 1 sept. The Let’s Encrypt X3 certificate is appended to the server certificate returned by my server.
Another weird thing is that if I restart the Mail program I can access my imap mails and macOS’s mail doesn’t complain. The warning started only since yesterday in the middle of the day. Never had a problem before. Does Mac mail skip certificate verification in this case ?
Could there be a MITM attack ? Mail asked me to trust the certificate, but I don’t do that unless I understand and I’m sure of what is going on. I’m a noob with macOS so I don’t know where to look up the CA. This happend at my work place.
I had a similar problem with thunderbird on windows and linux. But in this case it would just block all access. I had to add the Let’s Encrypt X3 certificate obtained from the Let’s Encrypt site. This happened at my workplace and at home. So I suspect there is a missing certificate in thunderbird.
This really doesn’t look right. How can we be sure we have the correct certificate and I’m not in a glasshouse ?
I’d be curious about the full error message you’re seeing. The exact hostname of your IMAP server would also be useful in checking for any configuration errors.
Without that, it’s hard to speculate what’s going on here. The root certificate Let’s Encrypt chains up to is trusted by both Apple’s and Mozilla’s root program, so this sounds more like a configuration issue or a hostname mismatch (e.g. you’re connecting to imap.example.com, but the certificate was issued for mail.example.com).
Manually importing the “Let’s Encrypt X3” intermediate certificate should never be necessary.
Thank you very much for such a quick reply. The host name is imap.meessen.net. I use a tiny python script to create and assemble the certificate.
I append the intermediate Let’sEncrypt X3 certificate obtained from the Let’s Encrypt web site to the server certificate file so that it is sent along with the certificate.
I had to do that because firefox wouldn’t validate my certificate without it. The root CA (I never manage to remember it’s name) was preinstalled in firefox.
For thundebird, it was indeed very weird that I had to install Let’s Encrypt X3 on all my instance so that it could validate the certificate.
It looks like your server is sending the wrong intermediate certificate. When Let's Encrypt launched, certificates were issued under the "Let's Encrypt Authority X1" intermediate. It was replaced by "Let's Encrypt Authority X3" at some point in the first half of 2016, to fix some compatibility issues. Some clients decided to hard-code the intermediate certificate (despite the spec warning against this, and providing a way to resolve it correctly ), which tends to lead to issues like this one.
You can find the PEM-encoded version of the latest intermediate certificate here. Here's an openssl snippet to verify the fix:
That was fast and extremely helpful! I now understand many problems.
Indeed I did the first tests and configuration at the beginning of 2016.
I wasn’t aware I used X1 as intermediate certificate.
I knew I was supposed to use X3. The figure on the Let’s Encrypt web site makes it very clear. I was laking the feedback that I was providing X1 instead of X3. I should have verified that.
Is there a way I can express my thank to you ? e.g. a karma upvote ?
certbot, the recommended Let’s Encrypt client, recommends checking the server configuration with SSL Labs after issuance, which would cover issues with the certificate chain (and many others). However, that tool is only intended for HTTPS servers on port 443, not other types of TLS servers like IMAPS.
There’s also some ongoing effort to make it simpler for clients to get this right by providing a combined certificate + chain file by default (which is what the majority of TLS servers ask for anyway), rather than asking clients to fetch the certificate chain separately. It’s likely that this will be included in a future version of the ACME specification that powers Let’s Encrypt.
), which tends to lead to issues like this one.