Certbot install created 301 redirect loop both http and https broken

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: ukura.com

I ran this command: curl -Ii ukura.com and www.ukura.com

It produced this output:
HTTP/1.1 301 Moved Permanently
Date: Tue, 01 Oct 2024 20:01:02 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://ukura.com/
Content-Type: text/html; charset=iso-8859-1

My web server is (include version): Apache/2.4.29

The operating system my web server runs on is (include version): ubuntu 18.4

My hosting provider, if applicable, is: digital ocean

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): no

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

Hi @hulapinto, and welcome to the LE community forum :slight_smile:

Let's have a look at the output of:
sudo apachectl -t -D DUMP_VHOSTS

Also, show:
sudo ufw status

2 Likes

I don't see a redirect loop. What I see is that port 443 is not open. I'm getting a timeout after the HTTP to HTTPS redirect.

1 Like
VirtualHost configuration:
*:443                  ukura.com (/etc/apache2/sites-enabled/ukura.com-le-ssl.conf:2)
*:80                   is a NameVirtualHost
         default server 127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost 127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost ukura.com (/etc/apache2/sites-enabled/ukura.com.conf:1)
                 alias www.ukura.com
--
ufw
Status: inactive

Does DO have a firewall?
Why does port 80 reach your server but port 443 does not?

2 Likes

It does, but you have to install it on each droplet. I did not

So, what is blocking port 443?

OR...
Let's ensure that is working, with:
ss -plnt | grep 443

And let's see the file:
/etc/apache2/sites-enabled/ukura.com-le-ssl.conf

3 Likes

No you don't. You cannot install the DigitalOcean Cloud Firewall on a droplet. It runs between your visitors and your droplets. That doesn't mean that you are using it, but it is worth checking to ensure that you are not blocking port 443 with it.

4 Likes

Thanks. I'll check it out, I did not enable it when I set up the server

1 Like

It will probably not be involved then.

Some of your console output seems to have missed the </> Preformatted text delimiters. I find it easiest to paste multi-line console output between two lines of three backticks like so:

```
Multi-line
Console
Output
```

That will result in:

Multi-line
Console 
Output 
3 Likes

thanks i'll redo

1 Like

LISTEN 0 128 *:443 : users:(("apache2",pid=25310,fd=6),("apache2",pid=24905,fd=6),("apache2",pid=24885,fd=6),("apache2",pid=24884,fd=6),("apache2",pid=24883,fd=6),("apache2",pid=24882,fd=6),("apache2",pid=24881,fd=6),("apache2",pid=15734,fd=6))

<IfModule mod_ssl.c>
<VirtualHost *:443>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@ukura.com
	#UserDir public_html
	DirectoryIndex index.php index.html
        DocumentRoot /home/mookie/ftp/files/ukura.com/public_html
	ServerName ukura.com
	ServerAlias www.ukura.com
	<directory /home/mookie/ftp/files/ukura.com/public_html>
	allow from all
	</directory>	
	#<IfModule mod_userdir.c>
        #UserDir disabled root
        #<Directory /home/mookie/ftp/files/ukura.com/public_html>
        #    AllowOverride FileInfo AuthConfig Limit Indexes
        #    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
        #    <Limit GET POST OPTIONS>
        #        Require all granted
        #    </Limit>
        #    <LimitExcept GET POST OPTIONS>
        #        Require all denied
        #    </LimitExcept>
        #</Directory>
        #</IfModule>
        #</VirtualHost>
	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf


Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/ukura.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ukura.com/privkey.pem
</VirtualHost>
</IfModule>
1 Like

That all looks correct.
What shows?
certbot certificates
ls -l /etc/letsencrypt/live/ukura.com/
ls -l /etc/letsencrypt/archive/ukura.com/

3 Likes

Presently I see Port 443 is filtered

$ nmap -Pn -p80,443 ukura.com
Starting Nmap 7.80 ( https://nmap.org ) at 2024-10-02 21:53 UTC
Nmap scan report for ukura.com (142.93.52.134)
Host is up (0.084s latency).

PORT    STATE    SERVICE
80/tcp  open     http
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 2.02 seconds

And using Let's Debug yields these results https://letsdebug.net/ukura.com/2242528

ANotWorking
Error
ukura.com has an A (IPv4) record (142.93.52.134) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
A timeout was experienced while communicating with ukura.com/142.93.52.134: Get "https://www.ukura.com/.well-known/acme-challenge/letsdebug-test": context deadline exceeded

Trace:
@0ms: Making a request to http://ukura.com/.well-known/acme-challenge/letsdebug-test (using initial IP 142.93.52.134)
@0ms: Dialing 142.93.52.134
@212ms: Server response: HTTP 301 Moved Permanently
@212ms: Received redirect to https://www.ukura.com/.well-known/acme-challenge/letsdebug-test
@284ms: Dialing 142.93.52.134
@10000ms: Experienced error: context deadline exceeded
IssueFromLetsEncrypt
Error
A test authorization for ukura.com to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.
142.93.52.134: Fetching https://www.ukura.com/.well-known/acme-challenge/x_FPRPISUqkth10Yw7iWxlzG5eEz5NJ95_u6I6HLeDQ: Timeout during connect (likely firewall problem)

Which show a redirect to from HTTP to HTTPS and since Port 443 is not accessible is causing the HTTP-01 challenge to fail.

This too shows the same redirect.

$ curl -Ii http://ukura.com/.well-known/acme-challenge/sometestfile
HTTP/1.1 301 Moved Permanently
Date: Wed, 02 Oct 2024 21:55:44 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://www.ukura.com/.well-known/acme-challenge/sometestfile
Content-Type: text/html; charset=iso-8859-1
2 Likes

Here is the presently latest version Certbot 2.11.0 Release
Certbot Instructions | Certbot

3 Likes

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Attempting to parse the version 2.11.0 renewal configuration file found at /etc/letsencrypt/renewal/ukura.com.conf with version 0.27.0 of Certbot. This might not work.


Found the following certs:
Certificate Name: ukura.com
Domains: ukura.com www.ukura.com
Expiry Date: 2024-12-29 16:47:16+00:00 (VALID: 87 days)
Certificate Path: /etc/letsencrypt/live/ukura.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/ukura.com/privkey.pem


-rw-r--r-- 1 root root 692 Sep 30 17:45 README
lrwxrwxrwx 1 root root 33 Sep 30 17:45 cert.pem -> ../../archive/ukura.com/cert1.pem
lrwxrwxrwx 1 root root 34 Sep 30 17:45 chain.pem -> ../../archive/ukura.com/chain1.pem
lrwxrwxrwx 1 root root 38 Sep 30 17:45 fullchain.pem -> ../../archive/ukura.com/fullchain1.pem
lrwxrwxrwx 1 root root 36 Sep 30 17:45 privkey.pem -> ../../archive/ukura.com/privkey1.pem

It seems that you installed certbot 2.11.0, but did not uninstall certbot version 0.27.0.

You can use sudo apt remove certbot to remove that obsolete version.

5 Likes

Hey everyone that replied, thank you for your time and effort. I removed and re-setup things, but the only thing that worked was destroying the droplet and starting over. Maybe there was something weird about the original droplet.

2 Likes

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