• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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