Why HTTPS Is Non-Negotiable

Browsers now mark HTTP sites as "Not Secure". Google ranks HTTPS sites higher. APIs and modern web features (geolocation, service workers, push notifications) require HTTPS. There is no good reason to serve a public site over plain HTTP in 2026.

The certificate is what makes HTTPS possible. It binds your domain name to a public key, signed by a trusted Certificate Authority (CA). Browsers verify the signature, confirm the domain matches, and establish an encrypted session.

The Free Options You Should Default To

  • Let's Encrypt — the standard. Free, automated, supported by every major hosting platform. Certificates valid for 90 days, renewed automatically. Run by ISRG, a respected nonprofit.
  • ZeroSSL — alternative to Let's Encrypt with a more user-friendly dashboard. Free up to 3 active certs, paid plans for more.
  • Cloudflare Universal SSL — free certificate that covers your domain when you use Cloudflare as a CDN. Issued by Google Trust Services or Let's Encrypt.

For 99% of sites, one of these is the right answer. They issue domain-validated (DV) certificates, the same type that paid CAs sell at the entry tier.

The Three Validation Levels

  • DV (Domain Validated): CA confirms you control the domain by checking a DNS record or HTTP file. Issued in minutes. Browsers show a padlock — no other visible difference. Free or $5–20/year.
  • OV (Organization Validated): CA additionally verifies your business is legally registered. Takes 1–3 days. Browsers show a padlock — no visible difference to users. $50–200/year.
  • EV (Extended Validation): Even more verification — physical address check, phone callback. Used to give browsers a green address bar with company name; that visual treatment was removed in 2019. Now indistinguishable to users from DV. $100–500/year.

The honest take: OV and EV give you NOTHING that users can see. The trust signal browsers used to provide for EV is gone. The only remaining justification is internal compliance ("our legal team requires OV certs") — and even that is a process artifact, not a security improvement.

Wildcard vs Single-Domain

  • Single-domain covers exactly one hostname: example.com OR www.example.com (modern certs include both as a courtesy).
  • Wildcard covers *.example.com — any single-level subdomain (api.example.com, app.example.com, blog.example.com). Does NOT cover deeper subdomains (api.v2.example.com).
  • Multi-domain (SAN) covers a list of explicit hostnames you specify. Useful when you need different second-level domains under one cert.

Let's Encrypt issues wildcard certs for free, but the issuance flow requires DNS-01 validation (you place a TXT record). Most automation tools (certbot, acme.sh) handle this if your DNS is on a supported provider.

When You Need a Wildcard

  • You're issuing subdomains dynamically (per-customer subdomains: customer1.yourapp.com, customer2.yourapp.com).
  • You have many existing subdomains and don't want to manage individual certs.
  • You can solve the DNS-01 challenge automatically (Cloudflare, Route 53, etc.).

Otherwise, single-domain certs are simpler and have fewer security trade-offs (a wildcard cert compromise affects all subdomains; a single-domain cert compromise is contained).

When Paid Certificates Actually Matter

The cases are narrow:

  • You need a guarantee or warranty. Some commercial CAs include $1M-$2M warranties for issuance errors. Most businesses never use this; some compliance frameworks require it.
  • Your environment can't run automated renewal. Air-gapped networks, legacy systems on old TLS stacks. Paid certs valid 1+ years are easier to manage manually.
  • You need a specific intermediate CA chain. Some embedded systems, IoT devices, and legacy clients only trust certain root CAs. Free CAs may not be in their root store.
  • You're issuing certs for SMTP/IMAP servers on platforms where Let's Encrypt automation is awkward. Even here, modern mail servers handle it fine.

The Practical Decision Tree

  1. Are you serving a website? Use Let's Encrypt or Cloudflare Universal SSL. Done.
  2. Do you have many subdomains and dynamic provisioning? Use Let's Encrypt with DNS-01 wildcards.
  3. Are you compliance-bound to OV/EV? Buy from DigiCert, Sectigo, or Entrust. Don't believe the security upgrade narrative; it's a procurement requirement.
  4. Are you running embedded/legacy systems? Validate which root CAs are in their trust store, then buy from one that's included.

Common Mistakes

  • Letting auto-renewal lapse. Let's Encrypt 90-day certs require working automation. Set up monitoring for upcoming expiry — the day a cert expires, your site goes dark in browsers.
  • Mixed content. A page served over HTTPS that loads scripts/images from HTTP becomes "not fully secure". Modern browsers block the HTTP requests; old code may break. Audit every URL with the search "site:yourdomain.com" + Chrome's mixed-content warning.
  • Forgetting to redirect HTTP to HTTPS. Without a 301 redirect from http:// to https://, users on direct HTTP links may never end up on the secure version. Configure at the web server (or use HSTS preload).
  • HSTS without testing. HSTS tells browsers "always use HTTPS for this domain for the next year". Set it incorrectly and you can lock users out of the site for that year, even if you switch to HTTP. Start with a short max-age (300 seconds), verify, then ramp.

The Bottom Line

For 99% of sites: use Let's Encrypt or your CDN's free SSL, set up auto-renewal, configure HTTPS-only redirects, done. Buying a certificate is the right answer in narrow compliance and embedded scenarios — and even then, the security delta is process, not product.