Why HTTPS Redirects Break (And How DNS Level Fixes It)

OK, you’ve set up your redirect. HTTP works perfectly. Type http://olddomain.com and users land exactly where they should. But HTTPS throws a certificate error. The browser shows “Your connection is not private,” and users close the tab before your redirect even executes. Here’s why it happens and how to fix it.

The SSL Handshake Timing Problem

The failure happens because of when the browser validates certificates during an HTTPS request.

Here’s the actual sequence when someone types https://olddomain.com:

1. DNS lookup: browser finds the server IP address
2. TCP connection: browser establishes connection to server
3. TLS handshake begins: browser and server negotiate encryption
4. Certificate validation: browser checks if certificate is valid for olddomain.com

If the certificate check fails at step 4, the browser shows a security warning and stops. Your redirect code sits in step 5 (the HTTP layer), which never gets reached. The redirect is configured correctly. It just never gets the chance to execute.

This design is intentional. Browsers validate certificates before trusting any communication with a server. It prevents attackers from impersonating domains, even temporarily.

The 3 Reasons HTTPS Redirects Fail

Reason 1: no certificate on source domain

Many domain registrars offer “domain forwarding” features. These typically work fine for HTTP but fail for HTTPS. The registrar forwards HTTP traffic but doesn’t provision SSL certificates for your old domain.

Result: http://old.com redirects successfully. https://old.com shows a certificate error.

Most users type domains without specifying http:// or https://. Modern browsers default to HTTPS. Your redirect works for a small percentage of traffic while failing for most visitors.

Reason 2: certificate name mismatch

You have a valid SSL certificate for newdomain.com. Users request https://olddomain.com. The server presents the certificate for newdomain.com, but the browser is requesting olddomain.com.

The browser rejects this as a potential security threat. Certificate names must match the requested domain. This protects users from impersonation attacks. If a certificate for bankofamerica.com could be used on fake-bank.com, phishing would be trivial.

Your redirect code would fix the mismatch, but it never runs because the certificate validation fails first.

Reason 3: redirect happens too late in request flow

Server based redirect methods all have the same problem: they require a successful HTTPS connection before they can execute.

Server-based redirect methods (.htaccess, JavaScript, meta refresh tags) all require a successful HTTPS connection before they can execute. The redirect code never runs because the TLS handshake fails first when the certificate is invalid. These methods work perfectly once you have a valid certificate. The challenge is getting that certificate on your source domain in the first place.

Why DNS-Configured Redirect Services Solve This

The architectural difference is when certificates get provisioned.

Traditional server based approach:

1. User requests https://old.com
2. Server receives request
3. Server must present valid certificate for old.com
4. If certificate invalid → browser shows error, user leaves
5. Redirect never executes

DNS based approach:

1. Setup phase (before any traffic): certificate automatically provisioned for old.com via Let’s Encrypt
2. Certificate exists and is valid
3. User requests https://old.com
4. TLS handshake succeeds (certificate already exists)
5. Redirect executes
6. User reaches destination

The key difference: certificates are provisioned during setup, not during traffic. When users arrive, the certificate already exists and is valid for the domain they requested.

Let’s Encrypt provides free certificates with 90 day validity and automatic renewal. The infrastructure handles certificate provisioning before users hit the domain, eliminating the timing problem that breaks server based redirects.

For organizations redirecting multiple subdomains (blog.old.com, shop.old.com, help.old.com), DNS-based services can provision wildcard certificates covering *.old.com. This eliminates the need to provision individual certificates for each subdomain: a single wildcard certificate handles all current and future subdomains under that domain.

Troubleshooting HTTPS Redirect Failures

If your HTTPS redirect isn’t working, diagnose the problem before trying solutions:

Test HTTP first

Visit http://olddomain.com (explicitly type http://). If this works but HTTPS doesn’t, you have a certificate problem, not a redirect problem. Your redirect configuration is fine. You need to address certificates.

Check the certificate

Use SSL Labs Server Test (ssllabs.com/ssltest/) to check what certificate is being served for your domain. Look for:

• “Certificate name mismatch”: certificate is for wrong domain
• “Certificate not trusted”: certificate chain incomplete
• No certificate found: server has no HTTPS configured

Verify DNS propagation

DNS changes can take up to 24 to 48 hours to propagate globally, depending on TTL settings. If you just updated your DNS records, some users may still be hitting the old server. Use whatsmydns.net to check propagation status across different locations.

Clear browser cache

Browsers cache certificates and HSTS policies. Test in an incognito/private window to rule out caching issues.

Check certificate expiry

Let’s Encrypt certificates are valid for 90 days. Manually managed certificates often expire. An expired certificate triggers the same browser warnings as a missing certificate.

Frequently Asked Questions

Ready to redirect?

To set up HTTPS redirects without manual certificate management, redirect.pizza provides DNS level redirect management with automatic SSL certificate provisioning via Let’s Encrypt. Get started for free.

For domain redirect fundamentals, see our Technical Guide to URL Redirects in 2026.