Acme challenge: "Redirect loop detected" on CertSage

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.

My domain is: oneplanet.international (also kayarchy.co.uk, kayarchy.com, the holyimage.co.uk, linguetic.co.uk, centpourcentanglais.com)

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

1 Like

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.

1 Like

Welcome Back to the Let's Encrypt Community, @Nico1! :slightly_smiling_face:

Let me take a look... :thinking:

2 Likes

Sorry for the delay.

I tested all six domain names:

  • oneplanet.international
  • kayarchy.co.uk
  • kayarchy.com
  • holyimage.co.uk
  • linguetic.co.uk
  • centpourcentanglais.com

for:

  • http://domain/.well-known/acme-challenge/PhcOwmJgQZrhFMHEa86cQBlS7KPKi8a-PFLlTHdtVvQ
  • http://www.domain/.well-known/acme-challenge/PhcOwmJgQZrhFMHEa86cQBlS7KPKi8a-PFLlTHdtVvQ
  • https://domain/.well-known/acme-challenge/PhcOwmJgQZrhFMHEa86cQBlS7KPKi8a-PFLlTHdtVvQ
  • https://www.domain/.well-known/acme-challenge/PhcOwmJgQZrhFMHEa86cQBlS7KPKi8a-PFLlTHdtVvQ

...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.

2 Likes

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

2 Likes

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)

5 Likes

That's great detective work, @MikeMcQ! :clap:t2:

I'm not sure why I didn't see that same pattern with redirect-checker.org. :thinking:

3 Likes

Don't know. Maybe TSOHost recognized the requester IP?

3 Likes

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?

2 Likes

Yes.

Note no "Server:" header and location back to itself

curl -i http://kayarchy.com/.well-known/acme-challenge/Test404
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /.well-known/acme-challenge/Test404

But just with "new" requester IP. An immediate retry from same server gets:

curl -i http://kayarchy.com/.well-known/acme-challenge/Test404
HTTP/1.1 404 Not Found
Date: Wed, 12 Jun 2024 15:50:31 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Accept-Ranges: bytes
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html

This example is probably clearer why Let's Encrypt calls the first one a redirect loop :slight_smile:

3 Likes

Completely agree, @MikeMcQ. Thanks for confirming that behavior.

(@Osiris, I think you'll get a chuckle here too.)

The server's response here sounds like the vizier's conversation with the physician in the Arabian Nights miniseries:

VIZIER: ''You're no help.''

PHYSICIAN: ''Patients often say that, but what do they know?''

VIZIER: ''Shall I get a second opinion?''

PHYSICIAN: ''Why not? I can come back tomorrow.''

4 Likes