Installing SSL on Hosting and Enforcing HTTPS Without Redirect Loops

Have you seen the ERR_TOO_MANY_REDIRECTS error?

You open the browser, type in your site's address, and instead of the homepage, you encounter the ERR_TOO_MANY_REDIRECTS error. Or in WordPress, you see the "too many redirects" message. The problem started when you decided to move your site to HTTPS and added a redirect rule in .htaccess. Now the site is down and users are seeing error messages.

I've seen this scenario many times. The solution isn't removing the extra rule; it's understanding where to apply the redirect and where not to. In this article, we'll take a close look at installing SSL on Linux hosting, automatic certificate renewal, and the rule that enforces HTTPS without creating a loop.

Where do you get an SSL certificate? Automatic issuance with Let's Encrypt

For installing SSL on hosting, you have two main paths: purchasing a certificate from a commercial authority or using Let's Encrypt, which is free and renews every 90 days. On Linux hosting with cPanel or DirectAdmin control panels, the AutoSSL tool is usually already active and issues and installs the certificate automatically.

If your hosting doesn't have AutoSSL, ask your provider to enable it. This tool uses the ACME protocol and issues certificates for the main domain and subdomains. On ServerNet's Linux hosting, AutoSSL is enabled by default and requires no manual intervention.

Manual certificate issuance with certbot

On dedicated servers or VPS without a control panel, certbot is the standard tool. Installing and issuing a certificate for the domain example.com with the Apache web server is done as follows:

sudo apt update
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

certbot finds the Apache configuration files, issues the certificate, and automatically applies it to the settings. For Nginx, use python3-certbot-nginx instead of python3-certbot-apache.

Automatic certificate renewal; where sites go offline

Let's Encrypt certificates are only valid for 90 days. If not renewed, browsers show security warnings and discourage users from entering your site. This is where people make a mistake: they assume the renewal cron job is already set up. But on many servers, this is done manually.

To ensure automatic renewal, first test that renewal actually works:

sudo certbot renew --dry-run

This command simulates the renewal process and displays any errors right there. Then check the cron job:

sudo crontab -l | grep certbot

If there's no output, add the cron job. The following command runs every day at 3 AM and renews the certificate if it has less than 30 days until expiration:

0 3 * * * /usr/bin/certbot renew --quiet

After renewal, the web server service needs to be reloaded. certbot usually does this automatically, but if you haven't used --deploy-hook and the service isn't reloading, add this line to cron:

0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload apache2"

HTTPS redirect without loops; the rule you need to write

Now that the certificate is installed, you need to redirect all HTTP traffic to HTTPS. The redirect rule in .htaccess must be precise. A wrong rule creates a redirect loop. The correct rule is:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The condition %{HTTPS} off means the redirect is only executed when the request comes from HTTP. Without this condition, every request — even HTTPS — gets redirected to HTTPS again, creating a loop. This is exactly the error we mentioned at the beginning of the article.

Redirect at the web server level; a more reliable alternative

On shared hosting where you only have access to .htaccess, the rule above is sufficient. But on a dedicated server, perform the redirect in the Virtual Host. For Apache:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

This method is faster because Apache executes the rule before processing .htaccess. In Nginx, similarly in the port 80 server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

WordPress and SSL; WP-CONFIG settings and redirect loops

If you have a WordPress site, there's another layer that creates redirect loops. WordPress stores the site address in the wp_options table. If this address is still http://, WordPress itself performs a redirect to HTTP, and if your .htaccess rule redirects to HTTPS, two conflicting redirects are created and a loop forms.

The solution is to define the site address in wp-config.php. Add these two lines before the /* That's all, stop editing! */ line:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

After this change, log out of the WordPress admin panel and log back in. If you see a white screen, read the guide on fixing the white screen in WordPress.

Mixed Content; something the redirect doesn't solve

The HTTPS redirect only converts browser requests. But if a script or image on the page loads from an http:// address, the browser blocks it. This error appears in the browser console as Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource.

To find these resources, use online mixed content scanning tools, or in Google Chrome, press F12 and open the Console tab. Then, in the WordPress database, run the following query to find all HTTP addresses:

SELECT * FROM wp_posts WHERE post_content LIKE '%http://example.com%';

A global replacement of http://example.com with https://example.com in the wp_posts table usually solves the problem. Before running it, make sure to back up the database.

HSTS; the next security layer with a specific cost

After ensuring the redirect is correct, you can enable the HSTS header so the browser takes the user directly to HTTPS and doesn't even send an HTTP request. In .htaccess:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

To be honest about the cost of this: if your SSL certificate expires and isn't renewed, users won't be able to access your site for a full year, even by typing the HTTP address. The browser blocks the request before sending it because of HSTS. This is where people make a mistake: they enable HSTS without ensuring automatic renewal, and after the certificate expires, the site becomes completely inaccessible to all users who have previously visited.

My recommendation: first make sure the renewal cron job is working, wait a month, and then enable HSTS with max-age=86400 (one day). If everything works correctly, increase the value to one year.

Final verification and troubleshooting

After applying the changes, check that the redirect works correctly with this command:

curl -I http://example.com

The output should include 301 Moved Permanently and the header Location: https://example.com/. If you see code 302, it means the redirect is temporary and isn't suitable for SEO. If you see code 200 on HTTP, it means the redirect rule hasn't been applied.

To check DNS and ensure the A and AAAA records are correct, use the DNS and network checker tool. If you've moved your site to a new domain, also read the guide on changing your site's domain without losing SEO.

Frequently Asked Questions

Why does my site show the ERR_TOO_MANY_REDIRECTS error after installing SSL?

This error means a redirect loop has been created. It's usually because your .htaccess rule doesn't have the %{HTTPS} off condition and redirects all requests to HTTPS again. Copy the correct rule from the "HTTPS redirect without loops" section and replace it.

How long is the free Let's Encrypt SSL certificate valid and how is it renewed?

Let's Encrypt certificates are valid for 90 days. Renewal is done automatically via a cron job that runs the certbot renew command. To ensure it works, run the command sudo certbot renew --dry-run.

Do I need to change the site address in WordPress after installing SSL?

Yes. If the site address in WordPress settings is still http://, WordPress creates a redirect to HTTP that conflicts with the HTTPS redirect rule. Change the address to HTTPS in the general settings or in the wp-config.php file using the WP_HOME and WP_SITEURL constants.

How do I know if all my site's content is being served over HTTPS?

Open the browser console and check the Network tab. Any request starting with http:// is Mixed Content and needs to be fixed. In WordPress, you can use an SQL query on the wp_posts table to find and replace all HTTP addresses.