In Progress [CPANEL-33077] Letsencrypt transition to ISRG’s Root (Important!!!!!)

[spikey221]

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!

I can confirm that following the instructions here worked. You can do this if you are stuck on Centos 6 and an out of date version of WHM/cPanel:

RHEL/CentOS 6 OpenSSL client compatibility after DST Root CA X3 expiration

@ Osiris - thx - it's working like a charm with the manually compiled RPMs! For the sake of completeness, here again the complete workflow to solve the DST Root CA X3 expiration problem with Centos / RHEL 6 ... yum install wget yum install krb5-devel zlib-devel lksctp-tools-devel util-linux...

community.letsencrypt.org

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:

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.

 

[cPanelAnthony]

As an update! While I can't make any guarantees, it looks like the fix was proposed for version 102.

 

[sparek-3]

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.

 

[eva2000]

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.