"The cPanel (powered by Sectigo) provider cannot currently accept incoming requests."
Apparently this was an issue a couple of years ago, anyone know why it might be happening again? Thanks.
-Michael
-
If you have an SSL that's getting close to the expiration date (3 days) and isn't renewing properly, create a ticket with our team and we'll check things on our end. 0 -
@cPRex this has been like this since Feb 27, 2022 3:06:01 AM issued for update but nothing, 03/013022 @ 11:17:43 AM ERROR TLS Status: Defective ERROR Certificate expiry: 3/4/22, 12:00 AM UTC (2.28 days from now) ERROR Defect: ALMOST_EXPIRED: The certificate will expire very soon. I think there was a workaround to backup the ssl or a file and then try autossl again and see if it renews? I can't find the link, I could try that first if not then put in a ticket I guess there is also another domain going to expire in 6 days as well. 0 -
Sounds like a good candidate for a ticket for sure. 0 -
Hello Would this remove the certificate request and then possibly we can run autossl again for the particular domain / sub domain and see if that works ? How can I clear the AutoSSL queue? Answer Simply move and rename the AutoSSL Sqlite3 database and it will be recreated when AutoSSL is re-run. This file is located at /var/cpanel/autossl_queue_cpanel.sqlite 0 -
It can't hurt to try it, but that isn't going to change Sectigo's handling on their end. 0 -
Sounds like a good candidate for a ticket for sure.
Ticket number #94421455 unfortunatley my license is from my host provider and not direct from cPanel so I hope they can get to fix it before the 2 days :( thanks @cPRex0 -
Hello Would this remove the certificate request and then possibly we can run autossl again for the particular domain / sub domain and see if that works ? How can I clear the AutoSSL queue? Answer Simply move and rename the AutoSSL Sqlite3 database and it will be recreated when AutoSSL is re-run. This file is located at /var/cpanel/autossl_queue_cpanel.sqlite
Did not work but was worth a try0 -
Thanks for that - I'm following along on my end now. 0 -
It's not required to have them in there, but if you're typically blocking traffic it's a good idea to have them in the allow list. That list of IPs is still valid as of this time. 0 -
Thanks for that - I'm following along on my end now.
Update: from Support: I noticed the following issues:curl -I mydomain.com HTTP/1.1 301 Moved Permanently Date: Tue, 01 Mar 2022 22:27:55 GMT Location: https://mydomain.com/ Server: AUTOM8N-nginx curl -I dev.mydomain.com HTTP/1.1 301 Moved Permanently Date: Tue, 01 Mar 2022 22:28:44 GMT Location: https://dev.mydomain.com/ Server: AUTOM8N-nginx
There will be a problem with the validation check when the site redirects from HTTP to HTTPS. I also see that you are running a third party version of Nginx: nginx-nDeploy-1.21.6-3.el8.x86_64 Please either switch to Apache solely or use the supported version of Nginx temporarily. After switching from the third party version of Nginx, please try having the SSL issued again. Edit2: my response Hello I have gone ahead and disabled the plugin, the 301 redirect is at each cPanel account mydomain> under domains>Force HTTPS Redirect is OFF the AutoSSL worked prior with my plugin Nginx from autom8n and with Force https Redirect in Domains. - so I am a little confused as to why now I would have to turn off the plugin and turn off Force Https redirects please advice ?[root@server1 ~]# curl -I mydomain.com HTTP/1.1 301 Moved Permanently Date: Tue, 01 Mar 2022 22:44:28 GMT Server: Apache Location: https://mydomain.com/ Content-Type: text/html; charset=iso-8859-1 [root@server1 ~]# curl -I dev.mydomain.com HTTP/1.1 301 Moved Permanently Date: Tue, 01 Mar 2022 22:44:53 GMT Server: Apache Location: https://dev.mydomain.com/ Content-Type: text/html; charset=iso-8859-1
UPDATE#3 I also added those 4 IP's of Sectigo to CSF and in Home>Security Center> cPHulk Brute Force Protection > Whitelist ManagementSectigo validates the DCV file from the following IP addresses: 178.255.81.12 178.255.81.13 91.199.212.132 199.66.201.132 Important: Sectigo uses these IP addresses to attempt to access the cPanel server. You must allow these IPs in the server firewall. For more information, read our How to Configure Your Firewall for cPanel & WHM Services documentation.
THEN: I turned off in cpanel the 301 redirect at each cPanel account > under domains>Force HTTPS Redirect is ON and finally it updated???5:10:01 PM Polling for "mydoman1""s new certificate for "mydomain.com" (order item ID "27382738") " 5:10:03 PM The certificate is available. Installing "mydomain.com""s new certificate " 5:10:05 PM SUCCESS Success! 5:22:01 PM Polling for "mysubdomain2""s new certificate for "dev.mydomain.com" (order item ID "2762674373") " 5:22:02 PM The certificate is available. Installing "dev.mydomain.com""s new certificate " 5:22:04 PM SUCCESS Success!
The Problem is now, - why did AutoSSL work before with Autom8n-Nginx and Force HTTPS Redirect ON. - if we have 100's of clients and they have this feature (Force HTTPS Redirect ON for their domains and sub.domains - how will they know to turn this feature off to get an updated AutoSSL ? I'm sure I am not the only one using this 301 redirect ( otherwise if someone types in mydomain.com the site will not show the certificate as SSL secure. unless they type in https;//mydomain.com - also if I wanted to have www.mydomain.com or just mydomain.com or the popup login windows will not function properly. so I have it redirect to0 -
Oh for sure, I completely agree. We're exploring options on our end too, both long and short term, which is why I'm keeping this thread updated. There isn't a case number though since development isn't involved as the current issues wouldn't be fixed with updates to the product. I'll definitely keep you guys updated as I find out more.
@cPRex Any updates on this? There were a couple days without the error, then it happened again on March 7th, but it looks like from the 8th - 13th it hasn't recurred (yet, and I really only checked 1 of the 5 servers I manage). I have not seen any notices on the progress of the issue though, was there an actual resolution as far as you know, or is it still hit or miss? Thanks! -Michael0 -
I wish I had more to report on this, but I don't have anything new on my end to add. At this point things are still hit-and-miss on the Sectigo side. 0 -
FYI: Restarting PDNS & Apache resolved this issue for me. Thanks! 0 -
Unfortunately we're still seeing issues with the Sectigo system with errors like "provider cannot currently accept incoming requests. The system will try again later." @cPRex Is cPanel applying whatever pressure it can on Sectigo to fix these on-going issues? My understanding was that Sectigo was not meant to have rate limiting but that isn't the reality? Certs are meant to be renewed up to 15 days in advance? So the recent failures we're seeing mean the Sectigo system has been unable to process the renewal after potentially up to 15 days of attempts? The following KB article is 10 months old and has no resolution. As a webhost it makes us & cPanel look bad when we're offering a solution that is not robust. 0 -
@cPRex Is cPanel applying whatever pressure it can on Sectigo to fix these on-going issues?
Absolutely. While we haven't seen as much of this the last few weeks, it's still happening far more than we'd like to see.0 -
This is happening far too much lately to not get priority from cPanel. 0 -
@mscruse - I promise we're working on things and I'll make a post once I have more details. For now, switching to Let's Encrypt is the best plan. 0 -
WHM 102.0.10 - Having the same issue on 2 sites: The "cPanel (powered by Sectigo)" provider cannot currently accept incoming requests. The system will try again later. I wish WHM/Cpanel would work properly with Cloudflare's free Certs. 0 -
these past few days, we have seen a LOT of these 2 errors (19 servers all running latest cpanel ver) 1 error The response to the HTTP (Hypertext Transfer Protocol) "POST" request from " indicated an error (500, Internal Server Error): 0 -
@mscruse - I promise we're working on things and I'll make a post once I have more details. For now, switching to Let's Encrypt is the best plan.
But that won't work for the system ssl certificates still, right?0 -
have you tried adding the IP's in your firewall and cphulk see cPanel (powered by Sectigo) provider cannot currently accept incoming requests" issue more frequently in the past couple days. After adding the IPs to CSF allow, big improvement and certs are starting to renew.
0 -
@Spirogg - although your reply was to someone else, thanks very much for the reminder about this. I had forgotten to add those to my CSF/LFD allow lists, and was starting to encounter the "cPanel (powered by Sectigo) provider cannot currently accept incoming requests" issue more frequently in the past couple days. After adding the IPs to CSF allow, big improvement and certs are starting to renew.
I"m glad I reminded you ;)0 -
"cPanel (powered by Sectigo) provider cannot currently accept incoming requests" I understand errors will always happen from time to time but this issue with the cPanel/Sectigo AutoSSL system has been going on for years. @cPRex Please can you clarify under what circumstances this error can occur? Is it normally caused by a capacity issue at Sectigo? The request reaches Sectigo but their service is too busy to process it? Or is it another communication issue from/to the web server? I'm sure cPanel have had many thousands of support tickets on this error, so what are the general findings? All our server use CSF firewall which already whitelists 5 IPv4 addresses and 2 IPv6 ranges belonging to Sectigo. We don't think the requests are being blocked anywhere else. For example, we don't use cPhulk and the Sectigo IPs are not in the ModSecurity log files. Sometimes running the "/usr/local/cpanel/bin/autossl_check --all" script fixes the issue, sometimes restarting Apache appears to help, sometimes not. 0 -
"cPanel (powered by Sectigo) provider cannot currently accept incoming requests" I understand errors will always happen from time to time but this issue with the cPanel/Sectigo AutoSSL system has been going on for years. @cPRex Please can you clarify under what circumstances this error can occur? Is it normally caused by a capacity issue at Sectigo? The request reaches Sectigo but their service is too busy to process it? Or is it another communication issue from/to the web server? I'm sure cPanel have had many thousands of support tickets on this error, so what are the general findings? All our server use CSF firewall which already whitelists 5 IPv4 addresses and 2 IPv6 ranges belonging to Sectigo. We don't think the requests are being blocked anywhere else. For example, we don't use cPhulk and the Sectigo IPs are not in the ModSecurity log files. Sometimes running the "/usr/local/cpanel/bin/autossl_check --all" script fixes the issue, sometimes restarting Apache appears to help, sometimes not.
just out of curiosity - do any of the accounts have Force https redirect ON. i had this issue and i whitelisted the 4 IP's 178.255.81.12 178.255.81.13 91.199.212.132 199.66.201.132 and turned OFF that setting for the domains under cPanel accounts) that we were having issues with. then ran the script again and it worked. but I agree there has been many post and thread on this issue. I think they are working on somesort of solution. or since there are millions of cert being renewed it could be anyone of the servers delaying this in a queue. sectigo cpanel ? thats just my 2 cents.0 -
@Spirogg Thanks for your reply. The 4 IPs you listed (and 1 other) are whitelisted already by CSF firewall. Where did you whitelist them? The IPs were not recorded anywhere in the server log files (including ModSecurity), and we don't use cPhulk, so I don't think they're being blocked anywhere. Today I'm checking 5 different accounts on 1 server. None of them have "Force HTTPS Redirect", although I don't see why that would cause an issue because the redirect syntax added to an .htaccess file would usually contain an exception for AutoSSL. The issue I'm seeing today appears to be a communication issue with Sectigo. 0 -
@Spirogg - although your reply was to someone else, thanks very much for the reminder about this. I had forgotten to add those to my CSF/LFD allow lists, and was starting to encounter the "cPanel (powered by Sectigo) provider cannot currently accept incoming requests" issue more frequently in the past couple days. After adding the IPs to CSF allow, big improvement and certs are starting to renew.
Oh well, so much for thinking that was helping. Right back to SSDD with this issue. :(0 -
Oh well, so much for thinking that was helping. Right back to SSDD with this issue. :(
me too last night having this issue. I have been getting 500 errors trying to update SSL. one server that has a few of my own websites i just tried letsencrypt and no issues updated right away. so go figure. I am going to test tonight on one server - switching provider back to Sectigo from letsencrypt and see if that updates. will report back my findings here0 -
Oh well, so much for thinking that was helping. Right back to SSDD with this issue. :(
ok so did that now.. and it worked.. I went and selected Sectigo for AutoSSL. then saved.. then went to my cpanel account for that domain. and uninstalled the certificate for mydomain.tld www . mydomain.tld and mail. mydomain.tld ( these were to only ones I had certificates for from letsencrypt. just fyi) so after uninstalling the letsencrypt certificate, I went back to cPanel for the domain and ran AutoSSL and it worked.. also below you can see that cpanel updated with Sectigo for this domain right now.. if in dire need you may want to try this ? I will test again on another domain on another server a little later that does not have letsencrypt. but I uninstalled the certificate of Sectigo and it won't reinstall via AutoSSL. so this time I will install Letsencrypt and use AutoSSL and install a cert. then switch to Sectigo then uninstall cert from letsencrypt then re run AutoSSL from Sectigo and see if success again. will post again my findings0
Please sign in to leave a comment.
Comments
231 comments