[CPANEL-33077] Letsencrypt transition to ISRGs Root (Important!!!!!)
-
Patch seems to be working. Now running into Lets Encrypt rate limits ( 429, Too Many Requests) when getting a nonce. May be due to living in a cPanel heavy server farm and running into the " 500 Accounts per IP Range within an IPv6 /48 per 3 hours" limit. See what happens over the next few hours. 0 -
I run the script succesfully. The SSL tests I can run confirm the problem is fixed. However, I have customers using Apple Mail that still get the certificate warning after the fix. I've told them to restart mail, restart the computer, all to no avail. Any ideas? 0 -
After I ran the fix recommended by cPanel, I had to update the SSL certificates for each of the domain names as someone recommended above. (WHM->List Accounts->Choose an account->SSL/TLS->Manage SSL Sites->Update Certificate->Autofill by Domain->Install Certificate) Once I did that, Dovecot and Exim started to show the proper common names for the domain names. (If you need to check your certificates for a particular port, let me recommend 0 -
The script worked for me, however I did have to manually trigger a rebuild of the Dovecot SNI configuration afterwards using the command: /scripts/build_mail_sni --rebuild_dovecot_sni_conf && /scripts/build_mail_sni --restartsrvs 0 -
For us the fix worked but the exim SNI seems not to be serving the certificates and we get the server certificate. I already opened a ticket with cPanel support but don't know if and when they will reply, anyone having a fix for that? 0 -
In our end it's working properly. Some accounts were switched to Sectigo, but others not, as Sectigo seems to be too busy. After applying script, returning to Let's Encrypt and run AutoSSL for all users, remaining accounts seems to be SSL protected again. BTW, affected server is a cPanel v86 with CentOS 6.
I am running the same, but for some reason the script didn't seem to do anything for me - an AutoSSL run still returns errors: 9:48:15 AM ERROR TLS Status: Defective Certificate expiry: 12/30/21, 7:07 AM UTC (89.93 days from now) ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (0:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (1:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (2:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (3:10:CERT_HAS_EXPIRED). Manually reinstalling the certificates as suggested does get things working again, but not an ideal fix when there's 70+ accounts to deal with0 -
The fix released is expected to perform a re-install for existing certificates that were issued by Let's encrypt. If you are seeing continued issues like the SNI not being rebuilt or the certificates not passing validation checks through Apache due to this same error, please open a support request so that we can review any possible conflicts with the autorepair task performing as expected. 0 -
I have done the original working patch that was recommended but still have common name problems with mail clients. For me neither 1. /scripts/build_mail_sni --rebuild_dovecot_sni_conf && /scripts/build_mail_sni --restartsrvs neither 2. WHM->List Accounts->Choose an account->SSL/TLS->Manage SSL Sites->Update Certificate->Autofill by Domain->Install Certificate solves the issue, the common name is still the main server hostname and thus giving problems with mail clients. Does anyone have a working fix? I have ran update several times, autossl for all users several times. 0 -
Any of you having cert errors on Windows 7 even after applying the patch from cPanel ? 0 -
SNI config in exim is still broken SNI in dovecot works fine You can test with: FAILS: openssl s_client -showcerts -connect mail.company.com:465 -servername mail.company.com
WORKS:openssl s_client -showcerts -connect mail.company.com:995 -servername mail.company.com
Make suremail.company.com
is actually for a client certificate and not the server's service certificate0 -
Exact same issue here all clients have problems with SMTP connection! SNI configuration in exim still incorrect 0 -
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. 0 -
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. 0 -
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. 0 -
@Misiek - I won't be able to answer individual questions here as I'd like to keep this on the overarching problem instead of certain instances. If you're seeing odd behavior, it would be best to submit a ticket to our team so we can check that out directly. 0 -
@cPRex, it affects alot of people, if you can paste the correct snippets for exim.conf it would be awesome!! SNI config in exim is still broken SNI in dovecot works fine You can test with: FAILS:
openssl s_client -showcerts -connect mail.company.com:465 -servername mail.company.com
WORKS:openssl s_client -showcerts -connect mail.company.com:995 -servername mail.company.com
Make suremail.company.com
is actually for a client certificate and not the server's service certificate0 -
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! 0 -
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. 0 -
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. 0 -
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: I'll continue to post updates as I get them.
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?0 -
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. 0 -
@mtindor: CL 7.9, cPanel 98.0.8, yum update done, patches run @cPRex: switching to Sectigo does not solve the exim problem either (port 465 returning certificate with system hostname as common name and not mail.company.com) 0 -
@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. 0 -
@cPRex thanks for the update. Can you advise when the autofixer runs? Is it part of the cPanel update cron? 0 -
That's correct - the autofixer ones as part of the overnight cPanel udpate. 0 -
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.
For everyone here is Let's Encrypt's Certificate Compatibility list for the new ISRG Root X1 certificate:0 -
@cPRex The problem is solved in computers but still have him in some Android phones, how can we solve this?. Thank you very much. 0 -
@MindServer - If they aren't working by now, they may be too old to work with modern SSL systems. 0 -
@mtindor: CL 7.9, cPanel 98.0.8, yum update done, patches run @cPRex: switching to Sectigo does not solve the exim problem either (port 465 returning certificate with system hostname as common name and not mail.company.com)
Not sure what to say about that. No issues here with Exim on CL6 ELS.0
Please sign in to leave a comment.
Comments
203 comments