Sectigo issue
Hello,
We see "The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests" in the last hours.
Do you know about this issue?
I see some planned maintenance for later today Sectigo
Thanks.
-
Things are back to normal now.. 0 -
We're still unable to issue SSLs through AutoSSL, were previously getting the same error like you @PlotHost, but now we see The response to the HTTP (Hypertext Transfer Protocol) "GET" request from "https://store.cpanel.net/json-api/ssl/certificate/free/xxxxxx" indicated an error (502, Bad Gateway): 502 Bad Gateway
and after that:WARN (XID zhybnv) The system failed to send an HTTP (Hypertext Transfer Protocol) "GET" request to "https://store.cpanel.net/json-api/ssl/certificate/free/xxxxxx" because of an error: Unexpected end of stream while looking for line
EDIT: It works now.0 -
Yes, there are issues... I see in logs that certs are generated after a few attempts. I see a notice in the namecheap account :) [QUOTE]Heads Up! We regret to inform you that our SSL support team is experiencing heave load at the moment. 0 -
There is definitely an issue upstream with Sectigo's CA bundle that we're currently investigating further. There is a related OpenSSL case and an article from Sectigo that are related to this: We're currently testing a patch to resolve this and are currently relaying the following: [QUOTE]cPanel is aware of widespread issues affecting new installations, AutoSSL, and EasyApache. This is related to a CA Root certificate expiring, and these issues should be resolved at this time. If you are still seeing expired certificates in the cPanel UI, unexpected SSL behavior on sites, or other SSL-related errors please run AutoSSL for all users to issue updated certificates: 0 -
I'm still getting the error: 5:51:45 PM The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later. 5:51:46 PM The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later. As far as I know this problem only affects very old browsers, right? 0 -
I have the exact same issue: [QUOTE] The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later.
Ticket submitted: #934922620 -
I'm still getting the error: 5:51:45 PM The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later. 5:51:46 PM The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later. As far as I know this problem only affects very old browsers, right?
I am getting the same thing right now. I have tried multiple times to run for that user and even to run for all users, same result.0 -
5:51:45 PM The provider "cPanel (powered by Sectigo)" cannot currently accept incoming requests. The system will try again later.
Same thing here...We didn't remove Let's Encrypt from AutoSSL providers so I'm unsure what you're referencing here.
Like zhongshan mentioned, I also don't see Let's Encrypt in the options of SSL Vendors, only cPanel (powered by Sectigo).0 -
Still running into the issue here as well. Anyone know any ETA to resolution? 0 -
Thanks for that @PlotHost The issue with Sectigo not accepting requests is related to this issue as well due to the volume of requests they're receiving we have an article on it here: AutoSSL Runs not Completing - Error: cPanel (powered by Sectigo) cannot currently accept incoming requests 0 -
The recommended /scripts/autorepair update_sectigo_cabundles shows errors like below when run as root: Checking *******.com... Updating cabundle for "*******.com"....Can't locate Cpanel/YAML.pm: /root/perl5/lib/perl5/Cpanel/YAML.pm: Permission denied at /usr/local/cpanel/Cpanel/CachedDataStore.pm line 125. :Permission denied at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1596. This certificate was already installed on this host. The system updated the Certificate Authority bundle for the current SSL installation.. Done 0 -
The recommended /scripts/autorepair update_sectigo_cabundles shows errors like below when run as root: Checking *******.com... Updating cabundle for "*******.com"....Can't locate Cpanel/YAML.pm: /root/perl5/lib/perl5/Cpanel/YAML.pm: Permission denied at /usr/local/cpanel/Cpanel/CachedDataStore.pm line 125. :Permission denied at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1596. This certificate was already installed on this host. The system updated the Certificate Authority bundle for the current SSL installation.. Done
@rch7, Do you have any customizations in/root/.bashrc
that affect the PATH used? What does the following command show, if anything? [CODE=bash]egrep '(PATH|PERL)' /root/.bashrc
Edit: If you findPERL5LIB
, try to unset that first, then re-execute the autorepair script. [CODE=bash]unset PERL5LIB /usr/local/cpanel/scripts/autorepair update_sectigo_cabundles0 -
There is definitely an issue upstream with Sectigo's CA bundle that we're currently investigating further. . . . We're currently testing a patch to resolve this and are currently relaying the following: cPanel is aware of widespread issues affecting new installations, AutoSSL, and EasyApache. This is related to a CA Root certificate expiring, and these issues should be resolved at this time. If you are still seeing expired certificates in the cPanel UI, unexpected SSL behavior on sites, or other SSL-related errors please run AutoSSL for all users to issue updated certificates:
0 -
There is a related OpenSSL case and an article from Sectigo that are related to this:
We are seeing issues related to on-server applications trying to send mail and being unable to connect with the mail server "error establishing ssl connection: certificate verify failed". All of the mitigation suggestions have already been tried. This doesn't appear to be an AutoSSL issue at this point, it is an OpenSSL issue.0 -
We are seeing issues related to on-server applications trying to send mail and being unable to connect with the mail server "error establishing ssl connection: certificate verify failed". All of the mitigation suggestions have already been tried. This doesn't appear to be an AutoSSL issue at this point, it is an OpenSSL issue.
I configure email to requires SSL for email send/receive, and have not seen a problem using Thunderbird, or iPhone (IMAP connection), nor have any users reported an issue (most use Outlook or Thunderbird). I would assume it's related to how the email client reacts to the expired cert. What client are you seeing issues with? -Pete0 -
What client are you seeing issues with?
Not user level clients but applications (like ecommerce) that produce emails and use the hosting server to send them via SMTP.0 -
Not user level clients but applications (like ecommerce) that produce emails and use the hosting server to send them via SMTP.
I see. I am not seeing issues with custom PHP scripts sending, nor WP sending, but they use sendmail.0 -
So, are you saying that all cPanel servers should have this resolved but now? ("This is related to a CA Root certificate expiring, and these issues should be resolved at this time.") I see no issues on my server's performance (in modern browsers), nor with AutoSSL, nor errors reported when running AutoSSL for all users, but I did notice when FTPS started to fail connections if the client didn't like the certificate chain having an expired cert in it. I can work around that, but isn't the issue of the expired cert in the chain still present? (
As I said in my initial response, if you have a cert affected by this and you need to resolve it immediately you can rerun autossl it will detect the expired CA Root and regenerate the cert with the non-expired CA Root Certificate. The only issue with that was the fact that Sectigo became overwhelmed by the number of requests it was receiving. We have completed work on an AutoFixer script for this at this time that will automatically update the CA Root Cert on affected SSL certificates this can be run with the following:/scripts/autorepair update_sectigo_cabundles
And is detailed in the documentation link I sent with my response: SSL Certificates Showing as Expired Please let me know if there are still uncertainties on what you should or need to do to resolve this.0 -
We are seeing issues related to on-server applications trying to send mail and being unable to connect with the mail server "error establishing ssl connection: certificate verify failed". All of the mitigation suggestions have already been tried. This doesn't appear to be an AutoSSL issue at this point, it is an OpenSSL issue.
Did you follow the suggested steps to resolve the issues with your certificates (if they were issued prior to May 1st) including your hostname certificate.0 -
As I said in my initial response, if you have a cert affected by this and you need to resolve it immediately you can rerun autossl it will detect the expired CA Root and regenerate the cert with the non-expired CA Root Certificate. The only issue with that was the fact that Sectigo became overwhelmed by the number of requests it was receiving. We have completed work on an AutoFixer script for this at this time that will automatically update the CA Root Cert on affected SSL certificates this can be run with the following:
/scripts/autorepair update_sectigo_cabundles
And is detailed in the documentation link I sent with my response: SSL Certificates Showing as Expired was not above anywhere that I can see. But that did it! :) The second command was what I needed (/usr/local/cpanel/bin/checkallsslcerts "force). The first had already been run automatically (same a as running AutoSSL for all users in WHM, I suspect). Now the server certificate chain is 100% good. Thanks! -Pete0 -
Actually, the link to
That's my mistake at the time of the original writing all we had was but the new article that I linked is more detailed on the issue and was put out AFTER I wrote the response I'm glad that fixed the issue! There's also the official announcement thread on this that may be useful to follow if you continue to have issues with this as well though I don't anticipate that.0 -
I tried many things, but I think the one that did it was that I found some files in ~username/ssl/certs for the account that was having this specific problem. At the time I wasn't sure if this was happening server wide, I knew of the issue specifically with one account and was scrambling to get that solved. Once I renamed that directory and restarted appropriate server processes the issue resolved. The certs directory was recreated but is now empty. The files in that directory were over 10 years old and some of them were cabundles. It's been so long that I no longer know why those files were there in the first place. But this appears to have been the issue. All seems fine now. 0 -
This explains why my email stopped working the other morning. Luckily, no customers mentioned anything about it. Glad it's been fixed. 0 -
All issues associated with this should now be resolved and the autofixer for both the AutoSSL and hostname certificates has been published. 0 -
I did not run into this issue until today, and I've set up at least 6 new accounts in the past 8 weeks, and all got issued their cert within a few minutes. I've tried /scripts/autorepair update_sectigo_cabundles Still no joy. Anyone else still encountering this? EDIT: Never mind, seems working now. I can only assume the Sectigo servers were very busy for while. 0
Please sign in to leave a comment.
Comments
27 comments