Redirect errors on websites after letsencrypt runs

Help
1

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. https://crt.sh/?q=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: somedomain.com

I ran this command: 40 23 * * * /usr/bin/certbot renew

It produced this output: detected that the server is redirecting the request for this address in a way that will never complete

My web server is (include version): httpd-2.4.6-97.el7.centos.x86_64

The operating system my web server runs on is (include version): CentOS 7 VM hosted VPS

My hosting provider, if applicable, is: Digital Pacific

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): never

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.11.0

The following has been in place since 2023:

## http conf file created 2023
#
## warranty.somedomain.com
#
<VirtualHost *:80>
    ServerAdmin webmaster@somedomain.com
    DocumentRoot /u/www/warranty.somedomain.com
    ServerAlias warranty.somedomain.com
    ServerName warranty.somedomain.com
#    Redirect / https://warranty.somedomain.com
    ErrorLog /var/log/httpd/somedomain-error.log
    CustomLog /var/log/httpd/somedomain-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =warranty.somedomain.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>


## https generated by letsencrypt in 2023
<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin webmaster@somedomain.com
    DocumentRoot /u/www/warranty.somedomain.com
    ServerAlias warranty.somedomain.com
    ServerName warranty.somedomain.com
#    Redirect / https://warranty.somedomain.com
    ErrorLog /var/log/httpd/somedomain-error.log
    CustomLog /var/log/httpd/somedomain-access.log combined
SSLCertificateFile /etc/letsencrypt/live/warranty.somedomain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/warranty.somedomain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/warranty.somedomain.com/chain.pem
</VirtualHost>
</IfModule>

and runs a PHP Cake based web setup that has not changed in over 100 days.
No other changes have been made under /u/www website directories.

**certbot certificates** command line output:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: beta.somedomain.com
    Serial Number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key Type: RSA
    Domains: beta.somedomain.com
    Expiry Date: 2025-10-28 12:47:03+00:00 (VALID: 86 days)
    Certificate Path: /etc/letsencrypt/live/beta.somedomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/beta.somedomain.com/privkey.pem
  Certificate Name: dev.somedomain.com
    Serial Number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key Type: RSA
    Domains: dev.somedomain.com
    Expiry Date: 2025-10-29 12:43:45+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/dev.somedomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/dev.somedomain.com/privkey.pem
  Certificate Name: somedomain.com
    Serial Number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key Type: RSA
    Domains: somedomain.com 
    Expiry Date: 2025-09-21 12:43:53+00:00 (VALID: 49 days)
    Certificate Path: /etc/letsencrypt/live/somedomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/somedomain.com/privkey.pem
  Certificate Name: presentation.somedomain.com
    Serial Number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key Type: RSA
    Domains: presentation.somedomain.com
    Expiry Date: 2025-10-30 12:48:28+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/presentation.somedomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/presentation.somedomain.com/privkey.pem
  Certificate Name: warranty.somedomain.com
    Serial Number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key Type: RSA
    Domains: warranty.somedomain.com
    Expiry Date: 2025-10-30 14:10:20+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/warranty.somedomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/warranty.somedomain.com/privkey.pem

dev and presentation work as expected, warranty and beta give redirection issues with the exact same syntax from 2023.

.htaccess file under all sites:

php_value memory_limit 3200M
<IfModule mod_rewrite.c>
   RewriteEngine on
   RewriteRule    (.*) app/webroot/$1 [L]
   Options -Multiviews

After /usr/bin/certbot renew ran via cron overnight on Thursday evening, all website traffic for warranty and beta result in web browers reporting errors like "detected that the server is redirecting the request for this address in a way that will never complete"

I have tried all matter of suppression of redirects in the .conf files but all result in either not working at all or giving the same redirect issues. /var/log/httpd error files just show the same php warning messages but in the warranty and beta these messages repeat over and over so is just reporting as if multiple access to the site are being made..... like a loop from a redirect repeating.

I saw some info on-line about Cloudflare or something and will be checking if this is the fix with the VM provider on Monday.

2

I have used a bogus domain name as I can't have my customer's web site exposed to the public. How can I suppress this from public view?

3

Hello @davrom,

example.com is the proper domain name to use if you redacted the actual domain name.

As https://example.com/ shows the intended usages

Example Domain
This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.

Also see:

2 Likes
4

Thank you. My first post on here :slight_smile:
Cannot see the edit button to change stuff so do I have to re-post to get help?

5

That's very strange as the certbot renew command does not modify your Apache config.

Do you have some other kind of certbot command running in a cronjob. Or were there any other updates that may have changed your Cloudflare setup or .htaccess files?

There really isn't much for us to do without the actual domain name. But, if Certbot renew was the only Certbot command then looking at these other components is most fruitful. Besides, the Apache VirtualHost you show seems fine. Certbot won't change your .htaccess and it cannot change your Cloudflare setup.

You could check that something else has not changed your intended Apache config. Run this to check

sudo httpd -t -D DUMP_VHOSTS

I am pretty sure httpd is used on Centos but try apachectl if that does not work. You should see a single listing for each port:domain name combination.

3 Likes
7

Thank you, yes all looks okay and as stated nothing has changed since 2023:

VirtualHost configuration:
*:443 is a NameVirtualHost
default server example.com (/etc/httpd/conf.d/lo_vh_example-le-ssl.conf:2)
port 443 namevhost example.com (/etc/httpd/conf.d/lo_vh_example-le-ssl.conf:2)
port 443 namevhost beta.example.com (/etc/httpd/conf.d/lo_vh_betaadv-le-ssl.conf:2)
alias beta.example.com
port 443 namevhost dev.example.com (/etc/httpd/conf.d/lo_vh_devadv-le-ssl.conf:2)
alias dev.example.com
port 443 namevhost warranty.example.com (/etc/httpd/conf.d/lo_vh_warranty-le-ssl.conf:2)
alias warranty.example.com
port 443 namevhost presentation.example.com (/etc/httpd/conf.d/lo_vh_presentation-le-ssl.conf:2)

The VM hosting company does state that they use Cloudflare so I have elevated this issue to them as there is indication there needs to be some change made in Cloudflare to stop this perpetual redirect happening. The customer nor I have access to this part so chasing their support on this one.

Thanks again for the reply - I don't have much hair and have lost more since going around in circles with the setup for days now. This is all external to the hosted VM and is somehow triggered with the 'certbot renew' command which has been running for years as-is as well.

1 Like
8

If these domains are proxied at Cloudflare such that they use their CDN then it is hard to imagine how a change of cert could change anything.

How did you resolve the problem of redirect loops? Or is it still ongoing?

If you are using the CF CDN and have it as Flex mode that can easily cause redirect loops. But, running certbot renew wouldn't change that setting or affect its behavior in any way. Certbot could be affected by such a misconfiguration and fail as a result but it wouldn't be a cause of such a problem.

With the Cloudflare CDN (or really any CDN), what happens is a browser first connects to the CDN edge server. And, perhaps get redirected from HTTP to HTTPS if CF so configured. But, when the CDN passes the request to the Origin Server (your server) the Flex mode always uses HTTP.

Your Origin is configured to redirect HTTP to HTTPS so this cycle endlessly repeats. Because the browser sees the redirect to HTTPS, sends the HTTPS request to the CDN Edge who passes it to your Origin as HTTP and so on and on.

3 Likes
9

Thank you but why would this happen now after being exactly the same setup since 2023 and multiple certbot renewals since (being now 2025). I did see someone else stating you need to make a change in the Cloudfare setup but the customer nor myself have this access or capability.... have never needed it.
Something external to the box has changed and I will try and go and find what they posted about it.
I have been using letsencrypt since it was a 'thing' and never had this kind of issue.

10

Clearly something has changed. The key is finding out what. You haven't provided many details to work with.

If Cloudflare CDN is involved maybe someone recently changed the setting to Flex? You also mentioned PHP app but I didn't see any evidence of that in the VirtualHost. Maybe that app is involved in the redirects. These are just guesses based on little info.

2 Likes
11

The server's /etc/httpd area and /u/www (where the PHP websites exists) have not changed. 2023 for the httpd setup and 100+ days the /u/www directories. I indicated this was the case in my initial cry for help.
No developers have been on the server for years now. The MySQL databases have no setup with http to https redirects and as I am the only person that gets down to the Linux level, certbot renewed certificates on August 1st and the site has had the issues since August 1st - I know certificates don't affect the redirects as they are just generated key/pem files, but something going through the hosting setup external to the Linux server has caused this.
Doesn't help that this is a hosted VM on the Internet and the hoster does use Cloudflare.

12

I can see this post from 2023 on the community:

and it 'feels' like the same thing. The whole Cloudflare setup is under the control of the provider so I am hammering them to help and fix this issue if they can..... otherwise will have to move to a different VM provider like Kamatera or someone and migrate the site to a CentOS 7 VM elsewhere to see if this fixes it.

13

Yes, that was caused by the Flex setting in Cloudflare CDN. I mentioned and described this earlier.

2 Likes
14

Thanks Mike. I am following up with the VM host company on this as I am sure it is exactly this issue.

15

Okay this remains something with letsencrypt.

I duplicated one of the sites configured on a new VM hosted with a completely new VPS hosting site. I modified the DNS A record to have a new node under the same domain name and pointed it a the new IP address. All worked perfectly.
Both this new hosting company and the current hosting company claim they have nothing to do with Cloudflare and the original hosting company put onus back on me as these are self-hosted.

So with the new VM hosted elsewhere I copied over the old 2023 based website and then ran certbot to create a new http to https instance in Apache on this new server.
Worked perfectly and could get to the website with https protection.
Went back to the original hosting company and said I had this working elsewhere so must be their setup......

However, I then added a second new website/domain to the new VM hosted server. Could get access just fine for http and then ran certbot to add this new domain to this server for https (so a second domain and second website on this same server) - and down it came in a screaming heap with it giving the same redirect errors for both of the new domains on the new server.... so this has to be letsecrypt doing this. This is ye olde CentOS7 running on these older setups owing to PHPCake 5.4 dependencies. No code has changed, the websites have not been touched in well over 100 days, no updates to the server, it is only the letsencrypt change that triggered this and now I have duplicated the issue on a new setup with new domains.

To this end I will be paying the original hosting company to get in and use the paid-for cert setup as this one is completely bizarre.

The only change in ages was the overnight 'certbot renew' process that ran.

Now I have to review how to get this working on the new setup given it is now in the same predicament.

I still use letsencrypt here in my own setup and for at least 6 of my primary customers who run serious business 'stuff' without a hitch.

The original VM hosting company did install everything correctly for their setup but still the redirects persist. I can't see how the old PHPCake .htaccess files which haven't changed in ages are to blame but is the only thing left.
Site has been down now for over a week and seriously not happy.

16

First, let's be clear that Let's Encrypt isn't involved in redirects. Now, Certbot may be modifying your config but that is a very different thing. Certbot is one of many ACME Clients and is managed by the EFF. Let's Encrypt is the ACME Server which issues certs. Certs are not active code they are files read by your Apache server for the HTTPS connections.

Personally, without details like the failing domain name and ability to see logs with actual data I can't think of anything more to say than I have. Perhaps other volunteers will have ideas.

I don't know why your site would remain down due to a faulty redirect. Can't you find the component that is doing the redirect and manually change it?

It is either in the VirtualHost, a .htaccess file somewhere in the folder tree, or possibly in this PHP app you mention. Sometimes front-end firewalls, CDNs, caches and the like do redirects as well.

I am pretty sure if we could "poke" at the actual domain we would recognize something in the response headers or other patterns to help isolate.

5 Likes
17

Here are a couple of online tools to assist with checking redirection

  1. https://www.redirect-checker.org/
  2. Rex Swain's HTTP Viewer

And thinking about it try Let's Debug for a check.

1 Like
18

Thanks Mike.
Yes I love that letsencrypt just puts in the direct entries in the Apache .conf file and then sets up the equivalent -le-ssl.conf file. From then on nothing gets changed and works perfectly.
Just bizarre as I have never seen this and with my new VM test I added a second site with only an index.php in it. Once I ran certbot over this not even that https site comes up.

The sites in question base on being the current the new hosting company I tried today are:

warranty.advancedprotection.com.au
and
warranty2.advancedprotection.com.au

Now since posting all this, flushing cookies etc, my bilane.advancedprotection.com.au is working correctly so now confused how the warrarnty2 does not work properly when it did all yesterday with its PHPCake content [that needed to be configured more] but was at least reaching the server DocumentRoot for this domain.

RewriteEngine on
RewriteCond %{SERVER_NAME} =warranty2.advancedprotection.com.au
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

is in the .conf for warranty2 and forces it to https but then spins.

Again no changes on the warranty server as I am the only one who would/could change 'stuff' and for a vital site like this, I don't touch anything once it is all working.
The hosting company is also investigating the warranty site and when they applied their own paid for SSL, the website started the redirect the same as it does for letsencrypt so is why I started to look 'outside' the setup. I can see they have touched some of the .htaccess setup under the warranty site as well but the error persists.

Just a mystery and so far has not happened to any of the other letsencrypt sites I have in place (including mine but then I am using nginx reverse proxy here).

Sorry to be a pain with all of this and will doe more check as per Bruce5051's site recommendations.
More weekend work for me it seems.

19

sorry meant to qualify - warranty2 was working perfectly all day yesterday till I added the biline domain to it today. Seems to be confused with multiple domains somehow? Maybe they are crossing over each other somehow?

20

Thanks Bruce.
I can see they are pulling out the PHPCake links like users etc path names, but the actual browsers just end up with redirect errors like:

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.

Scrubbing cookies does nothing so?

21

That's not Let's Encrypt doing that. Please get you terminology straight.

2 Likes