That's what I thought too but ...
5 Likes
Yes, but they [Go Papi] can.
4 Likes
Hi there,
I am another GoDaddy customer encountering a redirect loop while attempting to renew a Let'sEncrypt certificate. My domain name is andersongomes.tech.
My web server details are:
| IItem | Detail |
|---|---|
| Server Name | sg2plcpnl0227 |
| cPanel Version | 102.0 (build 24) |
| Apache Version | 2.4.56 |
| PHP Version | 7.4.33 |
| MySQL Version | 5.6.51-cll-lve |
| Architecture | x86_64 |
| Operating System | linux |
| Shared IP Address | 43.255.154.37 |
| Path to Sendmail | /usr/sbin/sendmail |
| Path to Perl | /usr/bin/perl |
| Perl Version | 5.10.1 |
| Kernel Version | 2.6.32-954.3.5.lve1.4.90.el6.x86_64 |
I have been using for around two years a Red Hat Ansible that uses the acme_certificate module to retrieve and install Let'sEncrypt certificates (source). Today, the renewal is failing with a "Redirect loop detected" error message.
I strongly suspect that the issue lies in GoDaddy's infrastructure; however, I called their Customer Service and failed to convince them that there is an issue on their end. They have recently changed something so that HTTP requests issued against their servers return HTTP 302 Found responses and same addresses as location targets before returning expected HTTP data.
To exemplify, a request to a static file that does not exist on my server is returning a HTTP 302 Found response before a HTTP 404 Not Found.
$ curl --verbose http://andersongomes.tech/.test/this-file-does-not-exist.txt
* Trying 43.255.154.37:80...
* Connected to andersongomes.tech (43.255.154.37) port 80 (#0)
> GET /.test/this-file-does-not-exist.txt HTTP/1.1
> Host: andersongomes.tech
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: close
< Pragma: no-cache
< cache-control: no-cache
< Location: /.test/this-file-does-not-exist.txt
<
* Closing connection 0
$ curl --location --verbose http://andersongomes.tech/.test/this-file-does-not-exist.txt
* Trying 43.255.154.37:80...
* Connected to andersongomes.tech (43.255.154.37) port 80 (#0)
> GET /.test/this-file-does-not-exist.txt HTTP/1.1
> Host: andersongomes.tech
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: close
< Pragma: no-cache
< cache-control: no-cache
< Location: /.test/this-file-does-not-exist.txt
<
* Closing connection 0
* Issue another request to this URL: 'http://andersongomes.tech/.test/this-file-does-not-exist.txt'
* Hostname andersongomes.tech was found in DNS cache
* Trying 43.255.154.37:80...
* Connected to andersongomes.tech (43.255.154.37) port 80 (#1)
> GET /.test/this-file-does-not-exist.txt HTTP/1.1
> Host: andersongomes.tech
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sat, 20 May 2023 02:37:05 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Content-Length: 1699
< Content-Type: text/html
<
$ curl --verbose http://yidefaze.org/.well-known/acme-challenge/this-file-does-not-exist.txt
* Trying 184.168.98.160:80...
* Connected to yidefaze.org (184.168.98.160) port 80 (#0)
> GET /.well-known/acme-challenge/this-file-does-not-exist.txt HTTP/1.1
> Host: yidefaze.org
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: close
< Pragma: no-cache
< cache-control: no-cache
< Location: /.well-known/acme-challenge/this-file-does-not-exist.txt
<
* Closing connection 0
3 Likes
That's a good find @amg1127 And, one of the rare times when someone posting on another's thread is actually helpful 
For your domain I issued a test request (see below) and got two 302 errors followed by many 404. But, if I waited a couple minutes I again got a 302 and then 404's and so on.
Your test is conclusively not a Let's Encrypt problem. And, it reminded me that we have seen this before with GoDaddy
It technically isn't a "redirect loop" because if you follow the 302's you will eventually get the correct response. But, Let's Encrypt is protecting itself and sees a problem when it is being redirected to the same place it just requested. It is a silly, wasteful, and slower sequence if not technically a loop. Especially when at least some times multiple 302 are issued before the 404. See below
Also, note no "Server: Apache" header in the 302 and generally a very different set of response headers between the 302 and 404. This same pattern is the same as I see with the original poster's domain.
In short, show this to GoDaddy and have them fix this. That's what worked in the other thread I linked to.
curl -I http://andersongomes.tech/ForumTest123.html
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /ForumTest123.html
curl -I http://andersongomes.tech/ForumTest123.html
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /ForumTest123.html
curl -I http://andersongomes.tech/ForumTest123.html
HTTP/1.1 404 Not Found
Date: Sat, 20 May 2023 02:50:40 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 1699
Content-Type: text/html
curl -I http://andersongomes.tech/ForumTest123.html
HTTP/1.1 404 Not Found
Date: Sat, 20 May 2023 02:50:42 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 1699
Content-Type: text/html
5 Likes
show this to GoDaddy and have them fix this.
I will retry doing so next week. I spent 1 hour on call trying to convince the 2nd-level support that there is an issue on their end and gave up. English is not my first language and, as a result, I've got my brain exhausted. To make things worse, GoDaddy no longer offer a ticket support system and the only way to request support from them is via phone call.
Yeah, I opted to post my report here to help other people find this thread via Google Search.
I am going to post some links that may be helpful to GoDaddy customers:
By following the two links above, I managed to observed some of @MikeMcQ's test requests in server logs and some recent Let'sEncrypt bot's attempts to retrieve domain ownership challenge responses. However, no HTTP 302 Found responses were recorded.
4 Likes
This confirms that some other component is interfering with the request and issuing the 302. Show godaddy this thread or at least the sample curl requests. That should help eliminate some of the language barrier
5 Likes
For note, I am a GoDaddy cPanel shared hosting costumer myself and I have not had any issues with these redirects when using CertSage to acquire my certificates (though that was a couple of weeks ago). It's possible that some default behavior with some product common to the two cases presented in this topic is resulting in these redirects rather than a core functionality change with GoDaddy hosting itself.
4 Likes
Thank you all (especially, @griffin, @MikeMcQ, @amg1127) very much for the continuing efforts to figure out this issue!
Following your suggestions, I happened to get some new findings.
I found the cPanel provides the recent Raw Access Logs in METRICS. So I checked them to see if there was 302. I do found 302 as below (I have hid these IP for potential privacy concerns):
...229 - - [19/May/2023:18:53:48 -0700] "GET /fr-cmt29/?variant=zh HTTP/1.1" 302 - "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)" 271 0/271108
...229 - - [19/May/2023:18:54:30 -0700] "GET /lllib_2002_0120/?variant=zh HTTP/1.1" 302 - "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)" 242 0/242551
...229 - - [19/May/2023:18:54:35 -0700] "GET /lllib_2002_1216/?variant=zh HTTP/1.1" 302 - "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)" 240 0/240008
...229 - - [19/May/2023:18:54:39 -0700] "GET /lllib_2019_0330/?variant=zh HTTP/1.1" 302 - "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)" 277 0/277220
...43 - - [19/May/2023:18:55:07 -0700] "GET /certsage.php HTTP/1.1" 200 1987 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36" 14 0/14600
...43 - - [19/May/2023:18:55:07 -0700] "GET /favicon.ico HTTP/1.1" 302 - "http://yidefaze.org/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36" 258 0/258180
It seems that most of the 302 were related to the plugin I use to convert language between Chinese Simplified and Chinese Traditional. Then I deactivated it. But I still encounter the redirect loop error.
But I happened to find that I can successfully acquire staging certificate via CertSage for yidefaze.org, although I still run into the redirect loop error for www.yidefaze.org. I was unaware of this difference, because I get used to acquiring certificate for both yidefaze.org and www.yidefaze.org at the same time (i.e., one domain name per line).
As I hit the rate limits today, I will tried to see if I can acquire production certificate for yidefaze.org in another day. I hope it will work.
Update: After the rate limits were gone, I have succeed in adding a Let's Encrypt certificate back to yidefaze.org via CertSage, although I still encountered the same redirect loop error three times (in acquiring production certificate for yidefaze.org) before I succeed in the fourth time. In other words, persistence is needed here. 
Update2: Then, I also succeeded in acquiring a Let's Encrypt production certificate for www.yidefaze.org via CertSage after several successive attempts. However, I have not succeeded in acquiring certificate for both yidefaze.org and www.yidefaze.org at the same time (i.e., one domain name per line). Since the rate limits come back, I will give it another try tomorrow to see if I can succeed by persistence.....lol
1 Like
Eventually you will succeed. But, this problem does not just affect you getting a cert.
It affects everyone visiting your site.
In fact, whatever the root cause it looks like it affects HTTPS requests worse than HTTP
For HTTP requests the pattern is as I described ... some 302 followed by some successful requests (was 404 not found but this morning I get 301 redirect to HTTPS). But, waiting a minute or so again sees 302's followed by success.
For HTTPS it looks worse. I get "connection reset by peer" errors instead of 302. You really should show this thread to GoDaddy. People using your website will not get good results
I consistently reproduce below results. After the 404 if I wait a minute or two I get more "reset by peer" errors.
curl -i https://yidefaze.org/ForumTestHTTPSagain2.html
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to yidefaze.org:443
curl -i https://yidefaze.org/ForumTestHTTPSagain2.html
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to yidefaze.org:443
curl -i https://yidefaze.org/ForumTestHTTPSagain2.html
HTTP/2 404
x-powered-by: PHP/7.4.33
x-ua-compatible: IE=edge
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
link: <https://yidefaze.org/wp-json/>; rel="https://api.w.org/"
vary: Accept-Encoding
content-type: text/html; charset=UTF-8
date: Sat, 20 May 2023 14:53:51 GMT
server: Apache
4 Likes
Food for thought:
4 Likes
Thank you, MikeMcQ, for more tests and suggestion! You're very generous!
I really succeed in acquiring and installing certificate (via CertSage) for both yidefaze.org and www.yidefaze.org today after several failed attempts. So it seems that my site has recovered to its former state. Nevertheless, I acknowledge that the 302 redirect problem still affects everyone visiting my site. I suspect this problem has been there for a long time before I encountered this error through CertSage a few days ago.
this morning I get 301 redirect to HTTPS
This was because CertSage has successfully enabled the forced HTTP -> HTTPS redirect as mentioned by griffin in a previous post:
When you use the button in CertSage to install your certificate into cPanel, CertSage enables the builtin HTTP->HTTPS redirect in cPanel, which is implemented at the vHost level, which is much more efficient and less error-prone than using rewrites.
And thank you, griffin, for sharing that helpful link for thought. I have read it through, although I am still unable to troubleshoot the 302 code error in my website. Since too much time has been spent on this issue, I would like to give up for now. At least, I have Let's Encrypt certificate reinstalled for my site....
3 Likes
I have given up trying to resolve my issue.
Again, I failed to convince GoDaddy's customer service that there is a problem on their end.
I will need to move my domain, website and e-mail to another provider to get my issue with Let'sEncrypt certificates resolved. I hope that I am able to find a provider with a customer service that understand RFC2616.
1 Like
I am sorry to hear that. You might try reviewing this list
3 Likes
Again, I'm not convinced that it's GoDaddy. I'm using GoDaddy shared hosting (have for many years) and I've never had this issue. Admittedly, it would be nice if GoDaddy would help resolve the issue. Have you tried asking in GoDaddy's community forum? If you decide to do that, please be sure not to frame the problem as a certificate issue (because it's not a certificate issue). The 302 redirect loop should be the focus.
3 Likes
I think a more serious problem that I (again) reproduced is the "reset by peer". These 3 requests were made within seconds of each other. And, as with the odd 302, if I wait a bit after the 200 OK I will again get "reset by peer" once or twice before another 200 OK.
This almost has to be something in GoDaddy settings. Or, some odd security product. An Apache problem would be more consistent. An earlier thread I linked to earlier was resolved when GoDaddy adjusted something (wish they would have said what)
curl -i https://yidefaze.org
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to yidefaze.org:443
curl -i https://yidefaze.org
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to yidefaze.org:443
curl -i https://yidefaze.org
HTTP/2 200
vary: User-Agent,Accept-Encoding
last-modified: Mon, 22 May 2023 09:44:00 GMT
accept-ranges: bytes
content-length: 59658
cache-control: max-age=0, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Mon, 29 Oct 1923 20:30:00 GMT
content-type: text/html; charset=UTF-8
date: Mon, 22 May 2023 15:00:38 GMT
server: Apache
3 Likes
I think a more serious problem that I (again) reproduced is the "reset by peer". These 3 requests were made within seconds of each other. And, as with the odd 302, if I wait a bit after the 200 OK I will again get "reset by peer" once or twice before another 200 OK.
I am getting similar errors with my hosting service, as well. Some attempts fail during the TLS handshake and some attempts return the expected HTTP 404 Not Found response.
$ curl --verbose --insecure https://andersongomes.tech/.test/this-file-does-not-exist.txt
* Trying 43.255.154.37:443...
* Connected to andersongomes.tech (43.255.154.37) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to andersongomes.tech:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer
$ curl --verbose --insecure https://andersongomes.tech/.test/this-file-does-not-exist.txt
* Trying 43.255.154.37:443...
* Connected to andersongomes.tech (43.255.154.37) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
* subject: CN=andersongomes.tech
* start date: Mar 10 07:17:45 2023 GMT
* expire date: Jun 8 07:17:44 2023 GMT
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /.test/this-file-does-not-exist.txt]
* h2h3 [:scheme: https]
* h2h3 [:authority: andersongomes.tech]
* h2h3 [user-agent: curl/8.0.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x5639c4952470)
> GET /.test/this-file-does-not-exist.txt HTTP/2
> Host: andersongomes.tech
> user-agent: curl/8.0.1
> accept: */*
>
< HTTP/2 404
< accept-ranges: bytes
< vary: Accept-Encoding
< content-length: 1699
< content-type: text/html
< date: Mon, 22 May 2023 20:50:05 GMT
< server: Apache
<
I'm using GoDaddy shared hosting (have for many years) and I've never had this issue.
I have been using GoDaddy for three years and this is the first time I am experiencing this issue. I wish I could be as luckier as you are.
Unfortunately, the issue appears impossible to reproduce from within customer service's workstations because they are likely inside infrastructure boundaries and have direct access to the web server. Sadly, instead of trying to convince me about a possible problem on my client side, they came to this topic and shared with me the same Food for thought article that you shared, without even assessing that I am not running Wordpress in my hosting service.
The WebSniffer service is showing the same results I am getting from my test workstation and, despite of that, GoDaddy's customer service insisted on saying that nothing was wrong with the service without trying to convince me why.
Connections via HTTP protocol return HTTP/1.1 302 Found responses.
Connections via HTTPS protocol fail before the HTTP transaction starts.
Admittedly, it would be nice if GoDaddy would help resolve the issue.
They didn't. They asked me to check for issues with a programmer, instead.
This time, I am going to create some basic knowledge questions about networks and OSI layer and ask webhosting's customer service to answer my questions before I sign up.
2 Likes
Somebody out there must be aware of a recent change in the evidently common stack that implemented this 302 with relative location. Considering that this likely affected many millions of users, I just can't realistically believe we're the only ones noticing and discussing this.
3 Likes
It's not just a recent change though. I posted the below thread from last July earlier in this thread which has very similar symptoms. They got theirs resolved by working with GoDaddy
There can be infrastructure issues that would affect only a subset of customers.
4 Likes
An update with my case: whatever had been misconfigured in GoDaddy's infrastructure was resolved, I am no longer getting HTTP/1.1 302 Found responses on requests to non-existing files, and I successfully got a new Let's Encrypt certificate for my domain.
$ curl --verbose http://andersongomes.tech/.test/this-file-does-not-exist.txt
* Trying 43.255.154.37:80...
* Connected to andersongomes.tech (43.255.154.37) port 80 (#0)
> GET /.test/this-file-does-not-exist.txt HTTP/1.1
> Host: andersongomes.tech
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 28 May 2023 06:06:41 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Content-Length: 1699
< Content-Type: text/html
<
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.