Fix SSL Installation Failed on Hostinger WordPress

You hit “Install SSL” inside Hostinger’s hPanel, watch the spinner crawl for two minutes, and end up staring at a red “SSL Installation Failed” badge. Hostinger gives you free Let’s Encrypt certificates out of the box, but their automated HTTP-01 validation script breaks the second your DNS, CDN, or server rewrites step out of line.

I hit this exact wall last week while migrating a client site. Let’s Encrypt isn’t failing because their servers are down—it’s failing because something on your end is blocking their automated challenge bot. Here’s how to track down the blockage, fix it, and get your certificate issued.

Why Hostinger SSL Installation Fails

Hostinger handles certificates through Let’s Encrypt using the standard ACME protocol. When you trigger the installer, Hostinger asks Let’s Encrypt to issue a certificate for both your apex domain and your www subdomain.

To prove you actually own the server, Let’s Encrypt uses an HTTP-01 challenge. It drops a temporary token into this exact path on your site:

http://yourdomain.com/.well-known/acme-challenge/

It then makes an unencrypted HTTP request over port 80 to pull that file. If anything intercepts, rewrites, or denies that request, the install fails immediately. In my experience, it almost always comes down to four culprits:

• Stale DNS propagation: Your A record isn’t pointing to your current Hostinger IP yet.
• Restrictive CAA records: You have an old DNS record explicitly forbidding Let’s Encrypt from issuing certs.
• Aggressive .htaccess redirects: A plugin or custom redirect is forcing HTTPS or rewriting requests before the cert actually exists.
• Cloudflare proxying: Cloudflare’s orange-cloud proxy is masking your origin server during the handshake.

Step 1: Verify Your A Records and Clean Up CAA Blocks

Don’t trust what your registrar dashboard says—check what public resolvers actually see right now. Query Google’s public DNS (8.8.8.8) using dig in your terminal:

dig yourdomain.com +trace +nodnssec
dig @8.8.8.8 yourdomain.com A +short
dig @8.8.8.8 www.yourdomain.com A +short

Pop open your Hostinger dashboard and head to Hosting -> Plan Details. Grab your server’s IP address and compare it to the IP from your dig output. If they don’t match, Let’s Encrypt is sending verification requests to the wrong server, and it will fail every time.

If you recently had to point Namecheap domain to Hostinger nameservers, local DNS caches can take hours to clear. Drop your TTL down to 300 seconds on your registrar while debugging so changes apply faster.

Next, check if you have an old CAA record locking you out:

dig yourdomain.com CAA +short

If you see a line like "0 issue "sectigo.com"" without an entry for Let’s Encrypt, the CA will refuse to issue your certificate. You’ll need to add a record permitting Let’s Encrypt, or clear out the CAA records entirely so any CA can issue:

; Hostinger or Registrar DNS Zone entry
yourdomain.com. 300 IN CAA 0 issue "letsencrypt.org"

Step 2: Inspect and Fix .htaccess Rewrite Rules

If your A record points to the right server and you still get an error, your .htaccess file is probably hijacking the challenge request. Security plugins love forcing early HTTPS redirects, which breaks HTTP-01 verification before the certificate even exists.

Jump into Hostinger’s File Manager or connect via SFTP, then open public_html/.htaccess. Look for rewrite rules that force HTTPS:

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

When the validation bot hits port 80, this rule instantly bounces it to https://yourdomain.com/.... Because you don’t have a valid certificate installed yet, the SSL handshake fails on the spot, and Let’s Encrypt gives up.

Fix this by telling Apache to ignore the .well-known directory when running redirects:

RewriteEngine On # Exclude Let's Encrypt ACME verification directory from redirects
RewriteCond %{REQUEST_URI} ^/.well-known/acme-challenge/ [NC]
RewriteRule ^ - [L] # Standard HTTP to HTTPS enforcement
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If your .htaccess is cluttered with rules from half a dozen security and caching plugins, rename it to .htaccess.bak and drop in the clean default WordPress rules until the certificate installs:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

If you’re locking down test environments and running into rewrite headaches, check how we password protect WordPress staging in htaccess without breaking REST API.

Step 3: Manually Test the ACME Challenge Directory

Don’t burn through Let’s Encrypt’s hourly rate limits guessing whether your server works. You can simulate the validation check yourself in thirty seconds.

Create the challenge directory structure in your public_html folder and drop a dummy file in it:

cd ~/public_html
mkdir -p .well-known/acme-challenge
echo "isitdev-test-token-active" > .well-known/acme-challenge/test.txt
chmod -R 755 .well-known

Now pull that file over plain HTTP using curl from your local machine:

curl -i http://yourdomain.com/.well-known/acme-challenge/test.txt

You need to see an explicit HTTP/1.1 200 OK response with your test string:

HTTP/1.1 200 OK
Date: Tue, 04 Mar 2025 10:14:02 GMT
Server: LiteSpeed
Content-Type: text/plain
Content-Length: 24 isitdev-test-token-active

If you see a 403 Forbidden, your folder permissions are too strict—run chmod 755 on the folders and chmod 644 on the file. If you see a 301 Moved Permanently, your .htaccess is still redirecting port 80 traffic; go back to Step 2 and fix the exclusion rule.

Step 4: Resolve Cloudflare and CDN Proxy Conflicts

If your DNS runs through Cloudflare, the orange-cloud proxy routes traffic through Cloudflare’s edge before hitting Hostinger. During an SSL installation, this proxy can confuse Let’s Encrypt because it terminates the handshake at the edge rather than passing the challenge directly to your LiteSpeed origin.

Here’s how to bypass the edge proxy while installing:

1. Open your Cloudflare dashboard.
2. Go to DNS -> Records.
3. Find the A records for both your root (@) and www.
4. Switch the Proxy status from Proxied (Orange Cloud) to DNS Only (Grey Cloud).
5. Wait about two to three minutes for Cloudflare’s edge caches to flush.

If you’re running a multi-tier CDN setup, see our guide on how to connect Namecheap DNS to StackPath CDN with Hostinger origin for clean origin routing.

Once your DNS is grey-clouded, run the curl test from Step 3 again to confirm your requests land directly on Hostinger.

Step 5: Force Reinstallation in hPanel

Now that your DNS points straight to Hostinger, CAA blocks are gone, and your test token returns an HTTP 200, trigger the installer again:

1. Log in to hPanel.
2. Go to Websites -> Dashboard for the domain you’re fixing.
3. Click Security -> SSL in the left sidebar.
4. Find the entry marked Failed, click the three vertical dots, and hit Uninstall.
5. Click the blue Install SSL button.
6. Pick your domain, select the free Let’s Encrypt option, and hit Install.

With the challenge directory accessible, verification should wrap up in under a minute. The status badge will flip to a solid green Active.

Step 6: Update WordPress Database URLs and Force HTTPS

Getting the certificate installed is only half the battle. Your WordPress database probably still references http:// URLs everywhere, which triggers “Mixed Content” or “Not Secure” browser warnings because styles, scripts, and media are loading insecurely.

First, lock your site URLs to HTTPS in wp-config.php so you don’t get locked out of wp-admin:

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

Next, SSH into your Hostinger account and run a search-replace through WP-CLI to update old database references:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --all-tables

For more edge cases with serialized arrays and safe string replacements, read our walkthrough on how to safely update WordPress URLs with WP-CLI search-replace.

Once your database is clean, go back to Security -> SSL in hPanel and toggle Force HTTPS on. Hostinger will now handle the redirect at the web-server level.

Frequently Asked Questions

Can I use a subdomain with Hostinger’s free SSL?

Yes. Subdomains get their own standalone Let’s Encrypt certificates in hPanel. Just make sure the subdomain has its own A record pointed at your Hostinger IP before you run the installer. If you’re managing DNS on Namecheap, check our tutorial to point subdomain to Hostinger using Namecheap DNS.

Why does Let’s Encrypt block my attempts for an hour?

Let’s Encrypt enforces strict rate limits. If your domain fails 5 challenge attempts per account within an hour, their API temporarily blocks further attempts. If you hit this limit, stop clicking “Install”—run the Step 3 curl test locally and wait out the 60-minute window.

Do I need to repeat this process when the certificate expires?

No. Hostinger runs an automated cron job that renews Let’s Encrypt certs about 30 days before their 90-day expiration date. As long as your domain stays pointed at Hostinger and you haven’t blocked the .well-known directory, renewals run quietly in the background.

Can I upload my own custom certificate instead?

Yes. In hPanel under Security -> SSL, click the Custom SSL tab. Paste your private key (.key), your certificate (.crt), and the CA bundle (.ca-bundle). This bypasses the Let’s Encrypt challenge entirely.

Next Steps

Once your SSL badge is green and your site loads clean over HTTPS, make sure you don’t accidentally leak unencrypted staging URLs. Check out our guide on how to set up WordPress staging on Hostinger and push changes without breaking your live SSL configuration.

Official resources

• WordPress developer documentation