Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: CertSage "acquire production certificate"
It produced this output: urn:ietf:params:acme:error:connection
92.205.3.60: Fetching /.well-known/acme-challenge/PhcOwmJgQZrhFMHEa86cQBlS7KPKi8a-PFLlTHdtVvQ: Redirect loop detected
My web server is (include version): Apache 2.4.59
The operating system my web server runs on is (include version): Linux
My hosting provider, if applicable, is: TsoHost (now = GoDaddy?)
I can login to a root shell on my machine (yes or no, or I don't know): Don't know
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): 110.0 (build 20)
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): CertSage 1.2.0
Replying to my own post here - I've been a happy CertSage user for years (and yes, I do occasionally send Griffin some money!) but on trying to do the three-monthly renewal on 5 June I got the error message in my post - "redirect loop detected". I had already received a Google "heads up", three days before the expiry of the SSL certificates on 8 June: "New reasons prevent pages being indexed - Redirect error".
I certainly haven't made identical configuration changes to each of my six websites in the last three months. In fact, I don't think I've touched some of them this year, other than to renew the SSL certificate.
I have asked my webhost tech support people about this; they suggest I ask CertSage.
...and found that none of them produce a redirect loop. The only redirect that was present for each was https://domain/x -> https://www.domain/x . The exception was holyimage.co.uk, which returned no valid response.
I think you might have Apache rewrites that are interacting badly with the builtin cPanel redirects.
That's very kind, and very quick, thank you.
I must admit it doesn't mean very much to me (I was 20 before electronic calculators became widely available, and I still have a slide rule in my desk drawer...) but I have forwarded it to tech support at TsoHost.
They've always managed to get there in the end, so fingers crossed for this time,
Nicholas
We have seen this before with TSOHost (and other GoDaddy services)
They have some sort of security protection which affects the first request from a new requester IP. It does not affect browsers because they follow the faulty "loop" request once and show the resulting page. But, Let's Encrypt detects the faulty redirect right away and stops with that error.
Maybe show TSOHost the below sequence and see if they can disable the setting for your domains
# First request from my own test server
# Note the redirect to / which is back to itself (a loop)
# Also note there is no "Server:" response header value
curl -I http://oneplanet.international
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /
# If I immediately follow that redirect I get redirected by Apache
curl -I http://oneplanet.international/
HTTP/1.1 301 Moved Permanently
Date: Wed, 12 Jun 2024 15:00:01 GMT
Server: Apache
Location: https://www.oneplanet.international/
Content-Type: text/html; charset=iso-8859-1
If I wait only a short time and try the first curl request again I do NOT get redirected to the / location. But, if I wait several minutes I again get that odd redirect. I am guessing the security system only remembers a requester IP for a short time and then goes through the initial check again.
# Just 1m30s later the original curl does not redirect to /
curl -I http://kayarchy.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 12 Jun 2024 15:01:33 GMT
Server: Apache
Location: https://www.kayarchy.com/
Content-Type: text/html; charset=iso-8859-1
# But, 8min later it does (still my same test server)
date
Wed Jun 12 15:08:16 UTC 2024
curl -I http://kayarchy.com
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /
We have seen this and similar a number of times. Below is just one example that is just like yours (was the easiest for me to find)
You might be right. I never saw the anomalous redirect in four isolated sessions of redirect checker. I also seem to have misinterpreted your findings at the time in your linked post.
Could it be because I was never hitting an empty path (with no trailing slash)? Can you reproduce this same anomaly with a trailing, sample, acme-challenge path from your end?
Just as a heads up, the suspect redirect behavior here will likely impair any ACME client (not just CertSage) with any ACME CA (not just Let's Encrypt). I've started a separate conversation with staff regarding this topic.
The device or software must be identified first. There is no "Server" header so it does not look like their Apache that does it. They'd have to work with TSOHost. Others have tried with various results (GoDaddy in general of which TSOhost is just one in their group).
