Setting up an edge CDN usually ends in one of two ways: an infinite ERR_TOO_MANY_REDIRECTS loop, or a fake “flexible” SSL setup where the edge-to-origin leg travels unencrypted over port 80 across the open internet. Here’s how to wire up true end-to-end SSL across Namecheap DNS, StackPath CDN, and Hostinger so every single hop runs strictly over TLS.
Most quick tutorials tell you to flip on edge SSL and leave Hostinger on plain HTTP. Don’t do that. It leaks backend traffic across public transit and breaks reverse proxies the second WordPress or LiteSpeed tries to enforce HTTPS.
The Architecture: Why End-to-End SSL Breaks
True end-to-end encryption means handling two independent TLS sessions without letting them fight each other. The first session runs between your visitor’s browser and the StackPath edge PoP. The second runs between StackPath and your Hostinger origin server.
When this breaks, it’s almost always an asymmetric mismatch. If StackPath terminates edge HTTPS on 443 but pulls from Hostinger on port 80, your backend thinks the visitor came in insecurely. Hostinger issues a 301 redirect back to HTTPS, StackPath hands that 301 back to the browser, and the browser loops until it gives up.
Here is what the flow actually needs to look like:
- Client to Edge: The browser resolves Namecheap DNS, lands on a StackPath Anycast IP, and negotiates an edge cert for your domain.
- Edge to Origin: StackPath opens a fresh TLS socket to Hostinger’s origin IP over port 443, validating the origin cert.
- Host Protocol Inspection: Hostinger reads the forwarded headers, recognizes the client already negotiated HTTPS, and serves clean 200 responses without redirecting.
Step 1: Issue the Origin SSL in Hostinger hPanel
You have to get a working certificate onto Hostinger before you route public DNS over to StackPath. If you point DNS to StackPath first, Let’s Encrypt’s HTTP-01 challenge won’t reach Hostinger directly, and certificate issuance will fail.
Log in to hPanel, select your site, and go to Security > SSL. Hit Install SSL to roll a Let’s Encrypt cert covering both your apex domain and the www host.
If your DNS records are already pointing elsewhere, check out our guide on how to fix SSL installation failed on Hostinger WordPress. The quick fix: set a temporary A record in Namecheap pointing your root domain straight to Hostinger’s server IP, give it two minutes, click Install SSL, and wait for the green checkmark.
Once it’s active, grab your server IP from Hosting > Plan Details. You’ll need this direct IP for StackPath.
Step 2: Configure the StackPath CDN Edge Site
Hop into your StackPath dashboard. We want to build a CDN site that speaks directly to Hostinger’s IP rather than querying your public domain name.
Click Create Site, choose CDN, and enter your domain name (like example.com). In the Origin Details screen, punch in these settings:
- Origin Type: IP Address
- Host / IP: Your Hostinger origin server IP
- HTTP Port: 80
- HTTPS Port: 443
Once StackPath creates the site, head to CDN > Edge Rules or Origin Settings to configure how it fetches assets. Change the Origin Protocol dropdown to HTTPS Only (or Match Client). If you want the complete breakdown of origin options, check our guide on how to connect Namecheap DNS to StackPath CDN with Hostinger origin.
Now open the Certificates tab in your StackPath site. Under Edge SSL, click Generate Free Certificate. StackPath will provision a cert through DigiCert or Let’s Encrypt that covers your apex and wildcards.
If your DNS isn’t live on StackPath yet, it’ll give you a CNAME validation string to drop into your records. Otherwise, it completes via HTTP challenge once records point to their edge.
Step 3: Point Namecheap DNS to StackPath Edge
With Hostinger ready and StackPath provisioned, you can shift production traffic to the CDN. Log in to Namecheap, open your Domain List, hit Manage, and switch to Advanced DNS.
StackPath hands you an edge delivery hostname formatted like xxxxxx.stackpathcdn.com. DNS RFCs don’t allow standard CNAMEs on an apex domain (@), but Namecheap supports ALIAS records on the root to handle this cleanly.
Add these two records in your Namecheap Advanced DNS panel:
- Type: ALIAS Record | Host:
@| Value:your-site-id.stackpathcdn.com| TTL: Automatic - Type: CNAME Record | Host:
www| Value:your-site-id.stackpathcdn.com| TTL: Automatic
For more details on setting this up without breaking root records, see how to point an apex domain to a CNAME in Namecheap DNS with ALIAS records.
One gotcha: check if you have existing CAA records in Namecheap. If you’ve restricted issuance to specific CAs, StackPath won’t be able to generate edge certs. Run through our guide to configure CAA records in Namecheap DNS so DigiCert and Let’s Encrypt can both issue without errors.
Step 4: Fix Reverse Proxy Headers in Hostinger
If you test your site right now, you might immediately bump into ERR_TOO_MANY_REDIRECTS. StackPath acts as a reverse proxy; even when your visitor reaches StackPath over HTTPS, Hostinger’s web server may not realize the original connection was encrypted unless you evaluate proxy headers.
We need Apache/LiteSpeed on Hostinger to check the X-Forwarded-Proto header that StackPath injects. Open up your public_html/.htaccess file (via SSH or hPanel File Manager) and place this right at the top:
RewriteEngine On # Detect StackPath HTTPS termination and pass to internal PHP environment
RewriteCond %{HTTP:X-Forwarded-Proto} =https [NC]
RewriteRule ^ - [E=HTTPS:on] # Force HTTPS if a plain HTTP request bypassed the edge rule
RewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
If you’re running WordPress, open wp-config.php and add this snippet right above the /* That's all, stop editing! Happy publishing. */ line:
/** * Handle reverse proxy SSL termination from StackPath CDN */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on';
}This ensures WordPress recognizes the upstream SSL session, shutting down its internal HTTPS redirect loops.
Verify Both SSL Handshakes with cURL
Never rely on a cached browser window to verify TLS hops. I always test both layers individually straight from the command line with curl.
First, verify the edge handshake through StackPath:
curl -Iv https://example.comLook through the verbose handshake details. You should see an HTTP 200 OK (or your normal app redirect) and an active TLS 1.2 or TLS 1.3 negotiation:
* ALPN: offers h2,http/1.1
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=example.com
* start date: May 10 00:00:00 2024 GMT
* expire date: Aug 08 23:59:59 2024 GMT
* issuer: C=US; O=Let's Encrypt; CN=R3
< HTTP/2 200
< server: StackPath
< x-hw: 1715340120.d02.phx1.t,1715340120.c01.phx1.pNow bypass StackPath entirely and hit the Hostinger origin directly over HTTPS. You can force cURL to resolve your domain straight to your Hostinger origin IP using --resolve:
curl -Iv --resolve example.com:443:195.179.200.123 https://example.comSwap in your real Hostinger IP for 195.179.200.123. If the handshake succeeds and validates the cert without throwing SSL: certificate subject name does not match target host name, your origin SSL is running properly.
Harden the Setup: Enforce HSTS and Origin Validation
With both connections working, lock down the edge so visitors can’t downgrade to insecure HTTP.
Enable HTTP Strict Transport Security (HSTS) headers by following the specs from the MDN Web Docs on HSTS. This tells browsers never to attempt plain HTTP requests to your site:
Add this line to your Hostinger .htaccess:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN"
Inside the StackPath dashboard under Edge SSL, set Minimum TLS Version to TLS 1.2. This drops outdated TLS 1.0 and 1.1 handshakes at the edge PoP.
Per the Let’s Encrypt Documentation, certificates renew every 60 to 90 days. Since StackPath forwards requests over port 443 with the correct Host header intact, Hostinger’s background ACME agent will renew your origin cert on schedule without breaking your proxy setup.
Frequently Asked Questions
Will Hostinger SSL auto-renew while hidden behind StackPath?
Yes, as long as you don’t block Let’s Encrypt’s validation requests or redirect the challenge directory. Let’s Encrypt sends HTTP-01 challenges to /.well-known/acme-challenge/. Because StackPath forwards clean requests to your origin, automated renewals complete without issues.
Can I use a self-signed certificate on Hostinger?
You can, but it weakens your setup. By default, StackPath validates the origin certificate against standard public trust stores. If you use a self-signed cert on Hostinger, you must toggle “Allow Invalid Origin Certificates” in StackPath, exposing the edge-to-origin link to MITM attacks. Stick with Hostinger’s free Let’s Encrypt cert instead.
Why does StackPath return a 520 or 502 Bad Gateway error?
A 502 or 520 typically means StackPath tried to hit Hostinger on port 443, but Hostinger dropped the connection or failed the TLS handshake. Double-check that your origin IP in StackPath is correct, and run the curl --resolve command above to ensure Hostinger answers directly on 443.
Do I need an SSL certificate on Namecheap?
No. Namecheap is only handling your DNS records here. Traffic never terminates at Namecheap’s nameservers, so buying an SSL cert there does nothing for this architecture. The encryption only happens at StackPath’s edge nodes and Hostinger’s origin server.
Next Steps for Your Edge Setup
Now that traffic is securely encrypted from end to end, you can tune caching rules without worrying about origin leaks. Take a look at our guide on how to bypass StackPath CDN cache for logged-in WordPress users so admins and authors don’t run into stale cached pages.
