• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved SSL It! - LE Cert fails: The operation takes too long. Please try later.

SteveITS

Basic Pleskian
We started having trouble with LE cert renewal several days ago, on multiple servers. The automatic renewal fails more frequently on sites with multiple aliases, hence multiple domains. Some renew fine but for 1-2 on each site we see either:
Timeout during connect (likely firewall problem)
and/or
Redirect loop detected
...often in the same email, sometimes changing over time. The latter message shows even if HTTP to HTTPS redirection is not enabled.

I have found that I can sometimes manually issue a new cert for the domains, however for sites with multiple aliases it still frequently fails, and the process will also sometimes end after around 10-15 minutes (I haven't timed it exactly) with Plesk message:

"The operation takes too long. Please try later."

If I watch proxy_access_log during this 10-15 minutes, I can see LE sometimes takes 5+ minutes to even log the first attempt at retrieving its file.

Is LE just really slow lately?

Is there a way to extend the Plesk timeout to say 30 minutes? Of course that's not ideal but that last message sounds to me like Plesk is giving up waiting for the task to finish.
 
I should note that I checked our router's Suricata which isn't blocking the connection. Presumably LE servers aren't on threat lists like Spamhaus DROP or ET or CINS, though I did just try to remove that block temporarily to test, to no avail.

Does LE verify over IPv4? The log entries I saw were only IPv6...

Just now the one I tried, after about 5 minutes logged two requests for www.example.info, an alias that was unable to verify on Saturday and Sunday, and (only) one for www.example.org. Then two minutes later three requests for another alias, before ending a few minutes later at the "The operation takes too long. Please try later." error in Plesk.
 
Yet another example...this site had all certs fail to renew yesterday but it retried automatically overnight and worked for some of them, so now we've got to hammer it until it works for the rest of the domains, limited by LE's daily cert limits. "Permanent SEO-safe 301 redirect from HTTP to HTTPS" is off for this site, though it is WordPress so it does redirect. There is no redirecting if I pull up the (actual) URLs flagged below.

Renewal of the following Let`s Encrypt certificates has failed:

<none>

The following Let`s Encrypt certificates have been renewed without some of their Subject Alternative Names:

** 'Lets Encrypt example.com' **
[+] example.com
[+] www.example.com
[+] theexample.com
[+] example.net
[-] www.theexample.com
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/97163709340.
Details:
Type: urn:ietf:params:acme:error:connection
Status: 400
Detail: Fetching http://example.com/.well-known/acme-challenge/rxtYTOHwiDrV5gGjyLebnOG7RhckkXGSsYRalO9GVP0: Redirect loop detected
[-] www.example.net
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/97163709350.
Details:
Type: urn:ietf:params:acme:error:connection
Status: 400
Detail: Fetching http://example.com/.well-known/acme-challenge/7X768B4BKlFnneglZoIt4pIkzD7dAQQUPzGIDr1i4p4: Redirect loop detected
 
Support says a cert for any additional domain aliases is unnecessary and we should only create certs for the primary domain. :eek: I guess the "solution" is to validate only certain domains so it doesn't time out.
 
After banging on this a while I eventually found there was an IPv6 routing issue in the data center, outside of our equipment. It was a bit subtle as it only affected some IPv6 connections, both inbound and outbound, so was not easy to pick up in testing...most pinging was fine but the occasional test had 100% loss. Turns out the data center had replaced a core router around the time these behaviors started. I suspect it was just getting worse over time. LE seems to only verify over IPv6 if it's in use. Human site visitors presumably could "retry" the page in their browser, and apparently not think much of it.
 
Back
Top