SNI config in exim is still broken
SNI in dovecot works fine
You can test with:
FAILS:
WORKS:
Make sure
SNI in dovecot works fine
You can test with:
FAILS:
openssl s_client -showcerts -connect mail.company.com:465 -servername mail.company.comWORKS:
openssl s_client -showcerts -connect mail.company.com:995 -servername mail.company.comMake sure
mail.company.com is actually for a client certificate and not the server's service certificate
Exact same issue here all clients have problems with SMTP connection! SNI configuration in exim still incorrect
Hey everyone! I'm in now and monitoring the situation again. I'll continue to post as I get updates throughout the day and get up to speed on everything that happened overnight.
I likely will not be able to respond to individual questions in this thread at this point. If you have an older system (such as Windows 7) or clients using older software, it's highly likely that those will not be able to connect properly due to the nature of the updates that took place. That was a known side effect and not something we will be able to resolve. Some details on that are discussed here: Let’s Encrypt’s root certificate has expired, and it might break your devices – TechCrunch
I'll continue to post updates as I get them.
I'll continue to post updates as I get them.
That is not the issue cPRex - im on latest thunderbird on newest macosx or windows 11 all report same issue with SMTP not matching server certificate, exactly as TFyre post state.
@cPRex , it affects alot of people, if you can paste the correct snippets for exim.conf it would be awesome!!
I have Windows 10, Office 2019 with latest updates.
But my issue is exactly as TFyre stated, testing those commands show exactly what fails and what doesn't (465 fails because of returning the system's hostname, 993 is OK returning mail.company.com).
Please, if someone receives any information from support on how to fix this, keep this forum posted, because this is a global issue for everyone if I am not mistaking!
But my issue is exactly as TFyre stated, testing those commands show exactly what fails and what doesn't (465 fails because of returning the system's hostname, 993 is OK returning mail.company.com).
Please, if someone receives any information from support on how to fix this, keep this forum posted, because this is a global issue for everyone if I am not mistaking!
What operating system are you guys experiencing Exim issues on? And if you guys are running CL6 ELS or CL7, did you install the necessary OpenSSL updates on CL6 ELS and do the yum update for ca-cert* as instructed in other areas?
Just asking. I'm on a CL6 ELS server that had the Dovecot issues. I had updated OpenSSL on the CL6 ELS boxes and that resolved issues with /webmail , /cpanel (cpanel services) . Maybe the updated OpenSSL and/or updated ca-cert* package is required for your Exim to do its thing.
Just asking. I'm on a CL6 ELS server that had the Dovecot issues. I had updated OpenSSL on the CL6 ELS boxes and that resolved issues with /webmail , /cpanel (cpanel services) . Maybe the updated OpenSSL and/or updated ca-cert* package is required for your Exim to do its thing.
Hi,
When we open the websites in some mobile phones, returns the message: NET:CERT_AUTHORITY_INVALID
This not happens in Computers, only in mobiles, how can I solve him?.
Thank you very much. Have a nice day.
When we open the websites in some mobile phones, returns the message: NET:CERT_AUTHORITY_INVALID
This not happens in Computers, only in mobiles, how can I solve him?.
Thank you very much. Have a nice day.
Last edited:
Hey there Rex, after the provided patch is run, Windows 7 users should be able to connect again, is this correct? or the new intermediate certificate is not supported on those systems either?
Hello again, everyone. Here is the situation as I understand it at this time. I say "at this time" because things are constantly evolving. There were actually two separate issues that happened at the same time, with one of those issues being outside of our control. The first issue, as you all know, is that Let's Encrypt expired their main root certificate yesterday. Normally, this would not have been an issue as these changes do happen, but the second part of the problem is what we didn't anticipate.
The second issue, is that Android is specifically not designed to handle expiration dates on root certificates, so even after Let's Encrypt's updated root certificate was released it included an "Android-friendly" CA bundle that caused issues with the OpenSSL verification process for many systems. When an SSL is issued we get three certificates: the domain cert, the intermediate cert, and then Let's Encrypt provides an additional intermediate certificate which currently points back to the old, expired certificate for compatibility reasons.
The autofixer patch we released basically chops off the third portion of the certificate, which some of you discovered was a valid way to get the certificate to install. However, this will only work for SSL certificates that have already been installed - since the Let's Encrypt plugin itself has not been updated, *new* certificates will still continue to experience issues. The autofixer is only able to fix certificates that already exist on the system.
Older devices that are not Android (I don't have a list of any type at this point) will continue to experience issues even after these updates are applied to the server, as those are issues specific to the software and security of the device/applications themselves.
Ideally, we are looking into a long-term plan where there is logic applied to the OpenSSL tools to detect the Android-compatible certificate and just remove it, as it's not something that is required, but at this time, switching to the cPanel/Sectigo provider is the most reliable solution, although so many people have been making that switch that there have been delays and ratelimits applied that are slowing this down as well.
If there's a tl;dr I suppose it is this: our autofixer is working well in most cases, but it is designed to be a short-term fix. We're currently looking into a more permanent resolution for Let's Encrypt users.
The second issue, is that Android is specifically not designed to handle expiration dates on root certificates, so even after Let's Encrypt's updated root certificate was released it included an "Android-friendly" CA bundle that caused issues with the OpenSSL verification process for many systems. When an SSL is issued we get three certificates: the domain cert, the intermediate cert, and then Let's Encrypt provides an additional intermediate certificate which currently points back to the old, expired certificate for compatibility reasons.
The autofixer patch we released basically chops off the third portion of the certificate, which some of you discovered was a valid way to get the certificate to install. However, this will only work for SSL certificates that have already been installed - since the Let's Encrypt plugin itself has not been updated, *new* certificates will still continue to experience issues. The autofixer is only able to fix certificates that already exist on the system.
Older devices that are not Android (I don't have a list of any type at this point) will continue to experience issues even after these updates are applied to the server, as those are issues specific to the software and security of the device/applications themselves.
Ideally, we are looking into a long-term plan where there is logic applied to the OpenSSL tools to detect the Android-compatible certificate and just remove it, as it's not something that is required, but at this time, switching to the cPanel/Sectigo provider is the most reliable solution, although so many people have been making that switch that there have been delays and ratelimits applied that are slowing this down as well.
If there's a tl;dr I suppose it is this: our autofixer is working well in most cases, but it is designed to be a short-term fix. We're currently looking into a more permanent resolution for Let's Encrypt users.
@dandadude - for specific issues it's best to submit a ticket to our team. In a large thread like this where I'm mostly just posting updates and our future plans, it's just not going to be possible for me to reply to each individual user.
For everyone here is Let's Encrypt's Certificate Compatibility list for the new ISRG Root X1 certificate:
Certificate Compatibility - Let's Encrypt
The main determining factor for whether a platform can validate Let’s Encrypt certificates is whether that platform trusts ISRG’s “ISRG Root X1” certificate. Prior to September 2021, some platforms could validate our certificates even though they don’t include ISRG Root X1, because they trusted...
letsencrypt.org
