Deploying HTTPS Correctly: Common Pitfalls and Fixes

If your site still shows a “Not Secure” warning after you’ve installed an SSL/TLS certificate, you’re probably missing a critical step in your HTTPS deployment. In the next few minutes you’ll learn the exact reasons browsers flag your site and, more importantly, get a step‑by‑step checklist to fix every issue without pulling your hair out.

Why HTTPS Is Not a One‑Click Switch

Flipping the “Enable HTTPS” toggle in a control panel and seeing a padlock does not mean you’re done. HTTPS is a layered protocol stack, and each layer has its own gotchas. Think of it like building a house: you can put a roof on a leaky foundation, but the house still won’t stand.

The Certificate Isn’t the Whole Story

Most developers focus on getting a certificate issued and forget about the rest of the TLS handshake. A certificate proves “who you are” to the browser, but the handshake also negotiates encryption algorithms, validates the certificate chain, and checks revocation status. If any of those steps are mis‑configured, browsers will either warn users or silently downgrade the connection.

Common Pitfall #1: Self‑Signed or Expired Certificates

What Happens

A self‑signed certificate triggers the “Your connection is not private” warning in every browser. An expired cert does the same thing, but the message is often just “certificate has expired,” making it harder to spot. Both break user trust and can hurt SEO.

How to Fix It

Use a free, automated service like Let’s Encrypt. Their client tools handle renewal automatically, so you don’t have to remember a 90‑day renewal cycle.
Set up a monitoring job that checks the expiry date of your certs and alerts you a week before they lapse. A simple cron script that runs
```
openssl x509 -noout -dates -in /path/to/cert.pem
```
is enough.
If you must use a self‑signed cert for internal testing, make sure it is never served to the public internet. Use a separate domain or a VPN‑only subdomain.

Common Pitfall #2: Incomplete Certificate Chain

What Happens

When a server sends only its leaf certificate without the intermediate certificates, some browsers will still work (they can fetch the missing pieces) but others will show a “certificate not trusted” error. This is especially common with newer CAs that require a chain of two or three intermediates.

How to Fix It

Combine your leaf certificate with the intermediate bundle provided by the CA into a single file.

Apache – use SSLCertificateFile for the combined file and SSLCertificateKeyFile for the private key.
Nginx – point ssl_certificate to the concatenated file, while ssl_certificate_key points to the key.

Common Pitfall #3: Weak Cipher Suites

What Happens

Legacy ciphers like RC4 or 3DES are still accepted by older browsers and some corporate firewalls. If you leave those enabled, an attacker can force a downgrade and sniff the traffic. Even if you think “no one uses those ciphers anymore,” the risk is real for sites with a global audience.

How to Fix It

Use the Mozilla SSL Configuration Generator as a starting point. Choose the “intermediate” profile for a good balance of compatibility and security.
Disable SSLv2 and SSLv3 outright—they are broken beyond repair.
Prefer forward‑secrecy ciphers (ECDHE) so that even if a private key is compromised later, past sessions stay safe.
Test your server with sslscan or the Qualys SSL Labs test. Aim for an A or A+ rating.

Common Pitfall #4: Ignoring HTTP Strict Transport Security (HSTS)

What Happens

Without HSTS, a user who types “example.com” into the address bar may still be served over plain HTTP before the browser learns to upgrade to HTTPS. This opens a window for a man‑in‑the‑middle attack.

How to Fix It

Add the header

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

to your HTTPS responses. The max-age value is in seconds (one year in this example). If you’re confident your entire site is HTTPS‑only, submit the domain to the HSTS preload list so browsers start with HTTPS from day one.

Common Pitfall #5: Mixed Content

What Happens

A page loaded over HTTPS that pulls scripts, images, or styles over HTTP triggers “mixed content” warnings. Modern browsers will block active mixed content (like scripts) and may still display passive content (like images) with a warning badge. This looks unprofessional and can break functionality.

How to Fix It

Scan your codebase for hard‑coded http:// URLs. Tools like grep -R "http://" can help.
Use protocol‑relative URLs (//example.com/script.js) or, better yet, always use https://.
For third‑party assets, make sure the provider offers HTTPS. If not, consider self‑hosting the asset or finding an alternative.

Common Pitfall #6: Not Enforcing HTTPS on the Server

What Happens

Even with a perfect TLS config, if your server still accepts plain HTTP connections, users can be lured to the insecure version. Some sites set up a redirect from HTTP to HTTPS, but forget to handle edge cases like subdomains or non‑standard ports.

How to Fix It

Configure a blanket redirect at the web server level:

Apache

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

Nginx
```
return 301 https://$host$request_uri;
```

Make sure the redirect is a 301 (permanent) so search engines update their index.

A Personal Tale: The Time I Forgot to Restart

I once rolled out a fresh TLS config on a client’s production server, double‑checked the cert chain, hardened the ciphers, and even added HSTS. Everything looked perfect in the Qualys report. Then a user called in complaining that the site still showed a “not secure” warning. After a quick look, I realized I had edited the wrong virtual host file. The old host was still serving the stale cert, and I hadn’t restarted the service. A quick systemctl reload nginx solved it, but the lesson stuck: automation and verification go hand‑in‑hand. Always run a final sanity check after a reload.

Checklist for a Bullet‑Proof HTTPS Deployment

[ ] Certificate issued by a trusted CA, auto‑renewed, and not expired.
[ ] Full certificate chain served (leaf + intermediates).
[ ] Only strong TLS versions (TLS 1.2+) and weak ciphers disabled.
[ ] HSTS header set with a long max‑age and preload flag if possible.
[ ] No mixed content on any page (use automated scanners).
[ ] HTTP traffic redirected to HTTPS with a 301 status.
[ ] Monitoring in place for cert expiry and TLS health.

Deploying HTTPS correctly is a marathon, not a sprint. The effort pays off in user trust, better SEO, and a reduced attack surface. Audit each layer, automate what you can, and you’ll sleep better at night knowing your site is truly secure.