[CPANEL-33077] Letsencrypt transition to ISRGs Root (Important!!!!!)
-
We"ll be shipping a fix soon to supported cP versions that configures our standalone OpenSSL verifications always to ignore extra intermediates
I guess that means you are rebuilding the Cpanel openssl 1.0.2 package with
That flag does not ignore extra intermediates buts changes how it walks up the chain to verify so essentially will ignore the expired DST ROOT CA X3 cert Or just using openssl verify with -trusted first flag which does the same thing0 -
I guess that means you are rebuilding the Cpanel openssl 1.0.2 package with not need to have trusted-first mode configured manually; only standalone verification seems to need it. You can see this if you `openssl s_client` to helloworld.letsencrypt.org.
0 -
OpenSSL 1.0.2 does not need to have trusted-first mode configured manually
Yup same from my tests as long as expired root is removed from the trust store - ca-certificates yum updated0 -
We"ll be shipping a fix soon to supported cP versions that configures our standalone OpenSSL verifications always to ignore extra intermediates. This will allow us to install that extra intermediate again, which will restore compatibility with old Android devices that may not have the new LE root (and don"t care about the expiration of DST Root CA X3).
Hello, Can you please be more specific for "We"ll be shipping a fix soon". You have any timeline when this problem will be fixed and all Android issues been correct? Thank you.0 -
@net@work - I don't have any timelines at this point. I'll be sure to update this thread when I get them. 0 -
@net@work - I don't have any timelines at this point. I'll be sure to update this thread when I get them.
Can you please check it, days are passing and we lose a lot of customers0 -
@jorbox I just checked in and am also not seeing a timeline as Rex reported. I apologize for any inconvenience and thank you for your patience. 0 -
At this point I know we weren't able to get to it in the next v98 release coming out. However, we're hoping it will get to the one after that. I'll be sure to post once I get more details. 0 -
Can you please check it, days are passing and we lose a lot of customers
Why don't you simply switch the AutoSSL provider to cPanel instead of LetsEncrypt? That's about a 5 minute job and your customers should all be happy again.0 -
Switching to cPanel causes issues for customers who have created a CAA record to only allow let"s Encrypt and will also cause problems for customers who require wildcard certificates. 0 -
Why don't you simply switch the AutoSSL provider to cPanel instead of LetsEncrypt? That's about a 5 minute job and your customers should all be happy again.
Thank you but Sub domains, wildcard are not enabled with cPanel being an AutoSSL provider, even mail.domain.com, a lot of customers will have problems with their websites, its less than a 5 minute job but it will make hours of problems, my customers wont be happy they may kill me instead.0 -
I was wondering if there is any way to resolve this for those still on Centos 6? I've recently purchased a business that has about 130 Wordpress sites on a Centos 6 server running cPanel 86.0.40. I've run the steps here RHEL/CentOS 6 OpenSSL client compatibility after DST Root CA X3 expiration to get a newer version of openssl and updated certificates installed but I suspect this isn't the problem here from reading the post-mortem. I full understand that I need to get these sites off this server but that takes time so in the meantime is there a way we can manually patch autossl so that it doesn't spam Let's Encrypt for new certificates? as this is also causing issues when trying to migrate sites to a new server when we're unable to issue a certificate on that server due to rate limiting! :) 0 -
At this point I know we weren't able to get to it in the next v98 release coming out. However, we're hoping it will get to the one after that. I'll be sure to post once I get more details.
v100 release is out You have news? Thanks0 -
Hello! I will check on this with our team when they are in tomorrow and update this thread. 0 -
I was wondering if there is any way to resolve this for those still on Centos 6? I've recently purchased a business that has about 130 Wordpress sites on a Centos 6 server running cPanel 86.0.40. I've run the steps here [CODE=bash] yum install wget yum install krb5-devel zlib-devel lksctp-tools-devel util-linux make gcc rpm-build curl -o openssl-1.0.2k-21.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/openssl-1.0.2k-21.el7_9.src.rpm rpm -i openssl-1.0.2k-21.el7_9.src.rpm cd ~/rpmbuild/SOURCES/ sed -i 's/secure_getenv(/getenv(/g' *patch cd ../SPECS/ sed -i 's/%patch68 -p1 -b .secure-getenv/#%patch68 -p1 -b .secure-getenv/g' openssl.spec rpmbuild -bb openssl.spec cd ../RPMS/x86_64 rpm -U openssl-libs-1.0.2k-21.el6.x86_64.rpm openssl-1.0.2k-21.el6.x86_64.rpm openssl-devel-1.0.2k-21.el6.x86_64.rpm
Do this to rebuild the certificate store: [CODE=bash] yum install asciidoc java-1.6.0-openjdk mkdir -p /dl/ca-cert; cd /dl/ca-cert; curl -o ca-certificates-2020.2.41-65.1.el6_10.src.rpm https://vault.centos.org/6.10/updates/Source/SPackages/ca-certificates-2020.2.41-65.1.el6_10.src.rpm rpm -i ca-certificates-2020.2.41-65.1.el6_10.src.rpm curl -o ca-certificates-2021.2.50-72.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/ca-certificates-2021.2.50-72.el7_9.src.rpm rpm2cpio ca-certificates-2021.2.50-72.el7_9.src.rpm | cpio -idmv cp certdata.txt ~/rpmbuild/SOURCES/ sed -i 's/Version: 2020.2.41/Version: 2021.2.50/g' ~/rpmbuild/SPECS/ca-certificates.spec cd ~/rpmbuild/SPECS rpmbuild -bb ca-certificates.spec cd /root/rpmbuild/RPMS/noarch/ rpm -U ca-certificates-2021.2.50-65.1.el6.noarch.rpm
That's verbatim from the linked page except that I added the installation of the openssl-devel package as that is required by cPanel. I turned off AutoSSL for a couple of days to allow the rate limits to expire, then turned it on and tested one site. It renewed successfully and now no longer complains about the broken trust chain. I must add that I did run the fix script mentioned in previous posts but I didn't think that would have worked because my version of WHM is too old. Perhaps this also contributed to things working again.0 -
As an update! While I can't make any guarantees, it looks like the fix was proposed for version 102. 0 -
By the time the "fix" gets rolled out. Everyone affected will have either upgraded to a supported OS or moved to another system where this works. 0 -
For CentOS 6 and cPanel I found the cleanest way is just to spin up a hourly CentOS 7 VPS server with the likes of Upcloud or Hetzner and install cPanel trial license and then do a WHM data transfer from CentOS 6 cPanel to CentOS 7 cPanel. Then I rebuild the CentOS 6 server with CentOS 7 and then migrated data back. Only took a few hours so hourly VPS cost was low. 0
Please sign in to leave a comment.
Comments
198 comments