---
title: Deploying HTTPS Correctly: Common Pitfalls and Fixes
siteUrl: https://logzly.com/securesiteinsights
author: securesiteinsights (SecureSite Insights)
date: 2026-06-13T00:42:41.372547
tags: [securesite, https, websecurity]
url: https://logzly.com/securesiteinsights/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](/securesiteinsights/web-application-hardening-checklist-10-essential-steps-every-developer-should-follow)**, 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

1. 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.  
2. 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  

   ```bash
   openssl x509 -noout -dates -in /path/to/cert.pem
   ```  

   is enough.  
3. 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

1. Use the **Mozilla SSL Configuration Generator** as a starting point. Choose the “intermediate” profile for a good balance of compatibility and security.  
2. **Disable SSLv2 and SSLv3** outright—they are broken beyond repair.  
3. Prefer **forward‑secrecy ciphers** (ECDHE) so that even if a private key is compromised later, past sessions stay safe.  
4. 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

1. Scan your codebase for hard‑coded `http://` URLs. Tools like `grep -R "http://"` can help.  
2. Use **protocol‑relative URLs** (`//example.com/script.js`) or, better yet, always use `https://`.  
3. For **[third‑party assets](/securesiteinsights/securing-third-party-scripts-without-slowing-down-your-site)**, 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**  

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

- **Nginx**  

  ```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](/securesiteinsights/protecting-user-privacy-best-practices-for-modern-websites)**, 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.