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

[Mehrdad Tari]

we have same issue
all of our hosting site over 2,000 site cert expired (Lets Encrypt)
i removed lets encrypt script and re-installed it and new letsencrypt version is installed.
but we have an error:
MASTER DCV: A rate limit prevents DCV.

This is while the letsencrypt says that it has removed the rate limit.

New certs failed with "A rate limit prevents DCV"

How's that AMD EPYC issuance server doing? I thought there was enough additional capacity there? After the dust has settled, would be curious to know the issuance numbers/rates it was handling

community.letsencrypt.org

Please tell me, What to do

thanks

 

[HostLABTR]

Hello there,

We think this is the right place to report this bug. The Autofixer you have published does not work correctly on servers older than v94. The output is as follows;

[[email protected] ~]# /scripts/autorepair update_lets_encrypt_cabundles2
Requesting script ... info [autorepair] Successfully verified signature for cpanel (key types: release).
Done
Auto Repair is running......Auto Repair is done.

Since Autofixer does not work correctly, requests are constantly sent to Let's Encrypt APIs and cause us to hang on rate limits. Can you start a case on this?

Thanks.

 

[Elephantino]

The new Let's Encrypt plugin has been released. The updated version is cpanel-letsencrypt-v2-1.02-1.2.1.cpanel.noarch.rpm

Update automatically?

Greetings
Andrew

 

[cPRex]

@Elephantino - that's correct - it will update automatically.

@HostLABTR - versions of cPanel older than the LTS version of 94.0.16 are not supported, so I would not expect the autofixer to work in those cases.

 

[Duplika]

Thanks for the updates @cPRex.

The previous command to fix permissions, is it included on the official fix, or should we run it if problems persists after running the fix?

 

[cPRex]

While the command is safe to run, we're still looking into *how* those permissions become corrupt in the first place for some users.

 

[Kent Brockman]

While the command is safe to run, we're still looking into *how* those permissions become corrupt in the first place for some users.

I run the command in dozens of servers and only 1/10 had the issue and were fixed. Maybe it happened due to some bug in previous versions.

 

[hartdesign]

our server is 100% up to date, we've run /scripts/autorepair update_lets_encrypt_cabundles2 and we're not seeing any progress. Around 50% of our clients are without ssl certificates :/ this Monday when they all realise their sites are effective offline, this is going to be a nightmare.

 

[vacancy]

/scripts/autorepair update_lets_encrypt_cabundles2 command unfortunately did not repair all certificates.

To repair corrupted certificates, it is necessary to whm > install certificate > autofill one by one. I was able to fix the broken certificates this way, but it is very challenging to do this for thousands of domains one by one.

If it is a new certificate, we still cannot receive it, we are constantly seeing the error 429, at least we are waiting for an urgent solution for mass correction of existing certificates. Instead of license price with a raise, produce a quick solution to this issue.

 

[hartdesign]

thanks @vacancy .. installing one by one will at least save us a lot of angry customers! good to finally have a fix for this

 

[HostLABTR]

@Elephantino - that's correct - it will update automatically.

@HostLABTR - versions of cPanel older than the LTS version of 94.0.16 are not supported, so I would not expect the autofixer to work in those cases.

However, this is a problem, causing the servers involved to constantly send requests to Let's Encrypt and get stuck at rate limits. Let's Encrypt detects traffic as an attack.

We don't expect you to add a new feature, it's just that it shouldn't be that difficult to make the released fix compatible with previous versions.

 

[Kent Brockman]

For those who /scripts/autorepair update_lets_encrypt_cabundles2 command didn't fix the issues, you can try this which fixed all in our case:

find /var/cpanel/ssl/domain_tls/* -type d -not -perm 755 -exec chmod -v 755 {} \;

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

 

[monarobase]

Be careful about that. As cPRex said that command could potentially change the permissions of the pending_delete directory.

 

[sajithgsm]

Today Cloudlinux provided a solution for this.

Fixing the issue with DST Root CA X3 Expiration on CloudLinux OS 6 ELS, CloudLinux OS 7, and CentOS 7

Fixing the issue with DST Root CA X3 Expiration on CloudLinux OS 6 ELS, CloudLinux OS 7, and CentOS 7

blog.cloudlinux.com

For CloudLinux OS 7 (and CentOS 7):
yum clean all
yum update ca-certificates

Try anyone and confirm its working or not please

 

[vacancy]

Today Cloudlinux provided a solution for this.

Fixing the issue with DST Root CA X3 Expiration on CloudLinux OS 6 ELS, CloudLinux OS 7, and CentOS 7

Fixing the issue with DST Root CA X3 Expiration on CloudLinux OS 6 ELS, CloudLinux OS 7, and CentOS 7

blog.cloudlinux.com

For CloudLinux OS 7 (and CentOS 7):
yum clean all
yum update ca-certificates

Try anyone and confirm its working or not please

This solution is not related to site certificates, it provides a solution to the problem of accessing cloudlinux rpm repositories.

 

[DHarry]

I've ran the autofixer and I think I'm confused as to what it's supposed to "fix".

Our issue is that our certificate chain looks like this:

   i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

We're also getting the verification error, "unable to get local issuer certificate".

Was the autofixer supposed to resolve this issue? Or, is there something else I need to attempt? Or, is this the exact issue still being researched?

Tomorrow is going to be hell for me if I cannot provide any updates.

 

[ciao70]

Hello,

This morning our site certificate was updated and the cross signature with DST Root is gone. Now all devices older than Android 7.1.1 get error

Did it happen to anyone else too?

I am really confused with all these problems

 

[MindServer]

Hello,

This morning our site certificate was updated and the cross signature with DST Root is gone. Now all devices older than Android 7.1.1 get error

Did it happen to anyone else too?

I am really confused with all these problems

Yes, I have the same problem, old Android versions cannot load the websites with SSL.

Have a nice day.

 

[ciao70]

Yes, I have the same problem, old Android versions cannot load the websites with SSL.

Have a nice day.

We fixed it by manually re-entering the third DST Root chain and disabled autossl for the time being

I had to download the cross signed ca cert and manually add it to combined cert used by apache

 

[[email protected]]

We fixed it by manually re-entering the third DST Root chain and disabled autossl for the time being

I had to download the cross signed ca cert and manually add it to combined cert used by apache

Hello,
As I have the same issue with older devices than Android 7.1.1 get error is possible to describe how we can manage to solve this? As most of us will have the exact same problem.

If we reinstall the certificate after cPanel plugin updated (2 days before - cpanel-letsencrypt-v2-1.02-1.2.1) will correct this problem or we must do something else?

The LetsEncrypt says: Extending Android Device Compatibility for Let's Encrypt Certificates how we can make that happened? cPanel letsencrypt plugin (after the update) it's not possible to insert a certificate that does that?

If we change to Sectigo as autossl provider will fix that kind of problem? The certificate will support android devices older than 7.1.1? Is a workaround or not?

Any suggestion? Thanks in advance!