Redirect errors on websites after letsencrypt runs

Help
22

It is only happened since the certiorari renewal, that is why I am asking for help. Please read all I have posted and get your story straight. I am asking for help to get answered, not get flamed for seeking help.

Regards,

David Clark

Davrom Consulting Pty Ltd

Mobile: 0418763124

E-mail: david@davrom.com

23

When you run certbot with the -d option at the first registration, it does implement the .conf file changes required, run it yourself and see.

Regards,

David Clark

Davrom Consulting Pty Ltd

Mobile: 0418763124

E-mail: david@davrom.com

24

Certbot. Certbot indeed. "Certbot" is NOT the same as "Let's Encrypt". As mentioned earlier by Mike.

Also, it has more to do with the plugin used by Certbot than the -d option.

2 Likes
25

Is it? Because when I query it I only get an empty placeholder page. But, these two are interesting and I'll refer back when I post about warranty shortly

An HTTP request. Does not redirect and shows empty index page

curl -i http://bilane.advancedprotection.com.au

HTTP/1.1 200 OK
Date: Sat, 09 Aug 2025 11:10:58 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5
Content-Length: 161
Content-Type: text/html;charset=ISO-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>
<h1>Index of /</h1>
<ul></ul>
</body></html>

An HTTPS request returns a smiley face page. Make special note of the PHP version

curl -i https://bilane.advancedprotection.com.au

HTTP/1.1 200 OK
Date: Sat, 09 Aug 2025 11:11:20 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5
X-Powered-By: PHP/5.4.16
Content-Length: 62
Content-Type: text/html; charset=UTF-8

<HTML>
<BODY>
<CENTER>
<H3>:-)</H3>
</CENTER>
</BODY>
</HTML>
3 Likes
26

Now, on to warranty. There are different problems for HTTP and HTTPS

An HTTP request does NOT redirect. The most recent VirtualHost example you showed had the normal Certbot-style redirect. So the VirtualHost processing this request does not have that.

curl -i http://warranty.advancedprotection.com.au

HTTP/1.1 200 OK
Date: Sat, 09 Aug 2025 11:06:49 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.45
Content-Length: 215
Content-Type: text/html;charset=ISO-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>
<h1>Index of /</h1>
<ul><li><a href="index.html_bak"> index.html_bak</a></li>
</ul>
</body></html>

The HTTPS request ends up in a redirect LOOP. This is almost certainly your Cake setup doing that. It is definitely not Certbot as it does not place redirects in the VirtualHost for port 443 (HTTPS).

Note also the different PHP version in X-Powered-By compared to bilane. Is that expected?

1) Initial curl to home page redirects to /users/login (fair enough)
curl -i https://warranty.advancedprotection.com.au

HTTP/1.1 302 Found
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.45
X-Powered-By: PHP/5.4.45
Set-Cookie: CAKEPHP=bfh0t8fgenrb8qo0a86srd8d96; path=/; secure
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Location: https://warranty.advancedprotection.com.au/users/login

2) Following that redirect gets redirected by adding on /controllers:Users
curl -i https://warranty.advancedprotection.com.au/users/login

HTTP/1.1 302 Found
Date: Sat, 09 Aug 2025 11:07:26 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.45
X-Powered-By: PHP/5.4.45
Set-Cookie: CAKEPHP=72tc5m7q4nv72rqc5ng22l6t04; path=/; secure
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Location: https://warranty.advancedprotection.com.au/users/login/controllers:Users

3) Following that redirect gets redirected back to just /users/login
This is a LOOP. 
curl -i https://warranty.advancedprotection.com.au/users/login/controllers:Users

HTTP/1.1 302 Found
Date: Sat, 09 Aug 2025 11:07:40 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.45
X-Powered-By: PHP/5.4.45
Set-Cookie: CAKEPHP=ra22s388k70p8phpn0f4gtvcl5; path=/; secure
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Location: https://warranty.advancedprotection.com.au/users/login
4 Likes
27

Well the problem is fixed after being down for 10 days. The culprit was nothing I expected and I thoroughly thank everyone who came along with me on my personal nightmare this past week.
I work with a lot of LAMP in my Linux life with NextCloud and Roundcube traditionally and then sites like these that have their own PHP based apps.

The problem completely went away when I restored the night before the issue started backup of the MySQL database = the whole thing came to life. The database seemed okay as I could run the basic mysql commands on the database and looked okay under phpMyAdmin (something I don't really touch).
This was the only 'change' made to the entire structure and was absolutely the last thing we all looked at in trying to get this to work.
The PHP Cake experts will be looking over things as this is their baby, not mine.
One little database .sql file restore fixed everything. None of the PHP setup had changed so this further made me look at the web resolution process as being the cause. I work with PHP myself to get access to my bash environment scripts so I am a lightweight when it comes to anything extensively PHP.
I have see MySQL running on Linux servers hosted with Azure where I had to change a URI/token in the database itself but that isn't the issue with this hosted VM with the VM provider.
Please make this one closed and is nothing I expected.

28

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.