SSL First

Every configuration on this site assumes HTTPS. No mixed HTTP/HTTPS server blocks, no dual-listening for cleartext and encrypted traffic on the same domain, no "optional SSL" footnotes. A single port 80 catch-all redirects everything to HTTPS, and HSTS tells browsers to never even attempt an unencrypted connection to this domain again. This page explains why.

It's not 2015 anymore

Let's Encrypt launched in 2016 and made SSL certificates free, automated, and trivial to deploy. In the years since, the web has shifted from treating HTTPS as something you add to e-commerce checkout pages to treating it as the baseline for every connection. The numbers bear this out: over 90% of pages loaded in Chrome now use HTTPS. The holdouts are increasingly older sites, abandoned infrastructure, and shared hosting platforms that haven't automated certificate renewal.

Major browsers now actively steer users away from unencrypted connections:

  • Chrome enabled HTTPS-First mode for Enhanced Safe Browsing users in April 2026 — roughly one billion people. Rather than a subtle "Not Secure" badge in the address bar, Chrome now shows a full-page warning before allowing navigation to any HTTP site. The user has to explicitly click through to proceed. In October 2026, this becomes the default for all Chrome users globally. HTTP won't just be discouraged — it'll be blocked by default.
  • Brave has shipped HTTPS by Default since version 1.50 — it upgrades every navigation to HTTPS and falls back to HTTP only if the site doesn't support it. Strict mode adds a full-page warning interstitial before any HTTP fallback.
  • Firefox and Safari both support HTTPS-Only mode with similar interstitial warnings before loading HTTP pages. Firefox's implementation is opt-in; Safari introduced HTTPS-by-default in iOS 18.2 with a warning for sites that don't support it.
  • Edge ships Automatic HTTPS mode that silently upgrades HTTP navigations to HTTPS with no alerts — the upgrade happens transparently.

Every major browser now either blocks HTTP by default, warns before loading it, or silently upgrades it. A site served over plain HTTP isn't just insecure — it's increasingly invisible. Browsers are treating it as an error condition, not a valid configuration.

If you're serving plain HTTP in 2026, browsers aren't just flagging your site as insecure — they're actively blocking navigation to it. The trust signal isn't just gone. The page won't load until your visitor explicitly clicks through a warning. Every guide on this site assumes HTTPS because the alternative isn't a configuration choice anymore. It's an error page.

SSL is free, automated, and takes twenty minutes

The last barrier to universal HTTPS was cost and complexity. Certbot eliminated both for anyone running their own server. A single cron job checks your certificates every morning and renews them automatically when they're within 30 days of expiry. The Let's Encrypt guide covers the full setup — from first issuance to the renewal cron job — without Certbot touching your hand-tuned Nginx configuration.

If you're on shared or reseller hosting rather than a VPS, the same principle applies. cPanel includes Auto SSL, which provisions Let's Encrypt certificates automatically for every domain on the account. DreamHost, SiteGround, and most major shared hosts have built-in Let's Encrypt integration — often a single checkbox. DirectAdmin, Plesk, and ISPConfig all support it. The free, automated SSL that was once a VPS-only workflow is now standard on any hosting platform worth paying for.

There is no ongoing cost. There is no manual renewal step. There is no reason to run plaintext in production. If you're hosting a blog, a portfolio, a business site, or anything that represents you or your work, the question isn't "do I need SSL for this?" It's "why wouldn't I?"

What an SSL-first configuration looks like

A single port 80 catch-all server block handles every HTTP request for every domain:

server {
    listen 80;
    listen [::]:80;
    server_name _;

    location /.well-known/acme-challenge/ {
        root /usr/share/nginx/html;
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

That's the entire HTTP configuration. No per-domain port 80 blocks. No mixed-content edge cases. Every request — whether it's http://example.com, http://www.example.com, or a bot hitting your IP directly — gets a 301 to HTTPS. The ACME challenge path is the only exception, and it's served directly without a redirect so Let's Encrypt can validate domain ownership.

On the HTTPS side, every server block includes HSTS:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

HSTS tells browsers "never connect to this domain over HTTP again for the next two years." Even if a visitor types http://example.com manually, the browser intercepts the request before it leaves the machine and upgrades it to HTTPS. No redirect, no server round-trip, no window for a man-in-the-middle to intercept the cleartext request.

There's one gotcha with HSTS: Nginx's add_header directive in a parent block is replaced — not merged — by any add_header in a child location block. If you have a location that sets its own caching headers, repeat the HSTS line there. The Securing Nginx and PHP guide covers this in detail alongside the modular snippet structure that keeps HSTS consistent across every response path.

Mixed content can't exist if there's no HTTP to mix with

Mixed content warnings happen when an HTTPS page loads an HTTP resource — an image with an http:// URL, a stylesheet pulled over cleartext, a script that never got updated. If your entire site is HTTPS-only and every internal link, image reference, and asset path uses relative URLs or explicit https://, mixed content never appears. There's no insecure path to serve content from.

The WordPress and Bludit installation guides on this site set the CMS URL to https:// during installation. WP-CLI handles search-replace for legacy URLs. Nginx handles the transport. The CMS never generates an http:// link because it doesn't know http:// exists.

Objections, and why they don't hold up

"My site is static — there's nothing to secure." HTTPS isn't just about encryption. It's about integrity. Without it, a compromised router between your server and your visitor can inject ads, rewrite content, or deliver malware — and neither you nor your visitor will know. The static sites guide covers this: HSTS, aggressive caching, and the few lines of configuration that make a static site as secure as any CMS.

"SSL adds latency." TLS 1.3 completes the handshake in one round-trip. HTTP/2 multiplexes connections over a single encrypted channel and is faster than HTTP/1.1 over cleartext for sites with more than a handful of assets. The latency argument was valid in 2010. It isn't now.

"Certificates are a hassle." Certbot runs from cron and renews automatically. The configuration takes twenty minutes once and never needs to be touched again. If you're still manually renewing certificates or paying for them, you're doing it the hard way by choice.

Further reading