Two quick scenes. One: a boutique store owner calls at 9:12 a.m.—“The site says Not Secure, and my checkout is empty.” They’d moved DNS over the weekend; auto‑renew didn’t follow. Revenue: falling. Two: a SaaS founder admits they’ve postponed SSL housekeeping for months because “no one complained.” That’s the thing—when SSL is working, it’s invisible. When it isn’t, it’s all anyone sees.
If you run anything on the web—shop, blog, API, billing portal, whatever (call it tools, platforms, Software)—you live inside a simple promise: people’s data travels without snoops or silent edits. SSL/TLS is how we keep that promise. The browsers no longer flash a big green padlock; they just scream when things go wrong. Our job is to give them nothing to scream about.
SSL then vs. TLS now (words change, purpose doesn’t)
Most of us still say “SSL,” but the protocol in use is TLS (Transport Layer Security). Jargon aside, the point hasn’t changed since the dial‑up days: confidentiality (no one can read it), integrity (no one can alter it), and authenticity (you are really talking to the site you intended).
What’s new-ish in 2025? TLS 1.3 is the default on decent hosts, HTTP/2 is standard, and HTTP/3 (QUIC) is rolling along, and certificates renew more frequently (90 days is common with ACME/Let’s Encrypt). Translation: faster handshakes, fewer configuration choices to mess up, and more need for automation so you don’t wake up to expired certs.
The three flavors: DV, OV, EV (and what actually matters)
- DV (Domain Validation): Proves control of a domain. Fast, automated, perfect for most sites and APIs. No business details shown.
- OV (Organization Validation): Adds a check on the registered org. Can help with procurement or regulated industries, but doesn’t change how search engines rank you.
- EV (Extended Validation): Deeper vetting, historically showed a company name in the address bar. Modern browsers barely surface that UI. If your compliance team wants it, fine; don’t expect a conversion miracle.
Pragmatic rule: If you’re a typical online business, DV + good configuration beats OV/EV + sloppy configuration every day of the week.
The modern SSL checklist (Merion’s no‑stress baseline)
- Redirects: Force HTTPS with 301 from every HTTP endpoint. One hop only; clean chains keep performance crisp and SEO tidy.
- HSTS: Once happy with HTTPS everywhere, set Strict-Transport-Security with a conservative max-age (e.g., 3–6 months) and includeSubDomains if they’re ready. Consider preload only when every subdomain is truly HTTPS‑only and you’ve tested thoroughly.
- TLS versions/ciphers: Enable TLS 1.2 and 1.3; retire older versions. Your host/CDN likely offers a “modern” preset—use it.
- Cookies: Mark auth/session cookies Secure, HttpOnly, and appropriate SameSite (usually Lax for app sessions; Strict where possible). Encrypting transit is half the story; donuts (cookies) need guards too.
- Mixed content: No images, scripts, or iframes over HTTP on HTTPS pages. One stray HTTP image can still trip warnings (and block loads). Use your browser console to spot culprits on key templates.
- Automation (ACME): Set certificate auto‑renew and test it. If you move DNS, update the ACME challenge path. Use a shared mailbox for expiry alerts—humans rotate; alerts shouldn’t disappear.
- CDN edge + origin: If you use a CDN/WAF, run full encryption edge‑to‑origin. “Flexible” modes that decrypt at the edge and talk HTTP to origin are a security smell waiting to become a breach post‑mortem.
- Monitoring: Ping for expiry, TLS version drift, and certificate mismatch (especially on APIs and alt hostnames like assets. or img.). A basic uptime monitor with a TLS check is shockingly cheap.
- Performance: Turn on HTTP/2 and, if available, HTTP/3. TLS + modern protocols usually improves perceived speed. The old myth that HTTPS is slower belongs in a museum.
Single, SAN, or wildcard? (choose once, sleep better)
- Single‑domain: www.example.com (and often includes the apex). Simple, low blast radius, perfect if you have few subdomains.
- SAN (multi-domain): One certificate covers multiple fully-qualified domains (e.g., blog.example.com, help.example.net). Good for consolidated management when brands are related.
- Wildcard: *.example.com covers any first‑level subdomain. Great for teams that spin up subdomains often (marketing, regions, tenants). Keep a tighter grip on the private key and access controls—its power is also its risk.
Merion tip: If you rarely add subdomains, avoid wildcard. If you’re a subdomain factory, wildcard with ACME automation is your friend—just guard the keys.
Real‑world traps we keep seeing
1) DNS changes break ACME You migrate DNS to a new provider and ACME challenges fail. The cert doesn’t renew, the site throws warnings, and sales dip. Fix: update challenge records and test renewals right after any DNS/host/CDN change.
2) “We’re secure at the edge” CDN shows a lock, but the CDN↔origin leg is plain HTTP. An internal actor or compromised network hop can still read/alter traffic. Fix: full TLS to the origin with a valid cert (self‑signed is fine if you validate at the edge).
3) Mixed content ghosts Theme or CMS updates re‑introduce an old HTTP asset. It loads on staging, explodes on production because the CDN enforces HTTPS. Fix: automated scans on deploy; CSP reports help too.
4) Cookie leakage Session cookies set without Secure or with SameSite=None but missing Secure. Modern browsers block/complain; users get random logouts. Fix: standardize cookie defaults in your framework/middleware.
How SSL plays with SEO, CRO, and compliance (yes, it’s all connected)
- SEO: Search engines expect HTTPS by default. It’s table stakes for crawling/indexing quality, not a silver bullet for ranking. But the side effects—clean redirects, faster protocols, fewer warnings—improve your Core Web Vitals story.
- CRO (conversions): Browsers stamp “Not Secure” on forms served over HTTP, and shoppers bail. Even subtle “parts of this page are not secure” warnings erode trust. Quiet pages convert.
- Compliance/payments: Many payment providers require specific TLS baselines. Some certifications or enterprise buyers will ask about HSTS and protocol support. Having a one‑pager ready (“our TLS policy”) smooths those questionnaires.
APIs and mobile apps: SSL beyond the browser
If you expose an API, treat TLS as part of the contract. Pin the CA or public key in mobile apps cautiously (rotate pins sanely). Prefer strict TLS to origin even behind private load balancers. Consider mTLS for partner‑only endpoints. Don’t forget subresources—file upload hosts, image transformers, and websockets need the same attention.
Your 30‑minute monthly ritual (Merion’s kitchen‑timer version)
- Expiry sweep: Check certs expiring in ≤30 days (edge and origin).
- Protocol check: Ensure TLS 1.2/1.3 on; older off. Verify HTTP/2 enabled; toggle HTTP/3 if stable for you.
- Redirect sanity: HTTP→HTTPS 301, one hop; no stray 302s.
- Mixed content scan: Load top 5 templates, watch the console; fix any HTTP calls.
- Cookie spot‑check: Confirm Secure/HttpOnly/SameSite on session cookies.
- ACME test: Manually trigger a dry‑run renew on one non‑critical host.
- Change log: Record any infra/app changes that could affect TLS (DNS, CDN mode, host moves).
Please put it on a shared calendar. The habit is the security.
Tiny story: the five‑minute save
A founder swore everything was fine—until a quiet Monday when checkout error rates doubled. The culprit wasn’t a hack; it was a single product image still pulled over HTTP. Console warning → CDN block → broken cart. Five minutes to fix, two days of head‑scratching revenue graphs. Moral: the details are small until they aren’t.
Quick FAQ / Tips
Do I need OV/EV for trust? Usually not. DV with solid practices (HSTS, clean redirects, cookie hygiene) wins. If procurement or a contract requires OV/EV, get it—but don’t expect UX magic.
Will HTTPS slow my site? No—in practice, TLS 1.3 + HTTP/2/3 improve performance via multiplexing and fewer round-trips. Optimize images and caching; TLS won’t be your bottleneck.
Is a wildcard certificate safe? Yes, if you treat the private key like crown jewels and restrict who can request certs. Otherwise, use SAN or single‑domain to limit blast radius.
Can I use “Flexible SSL” to simplify setup? It simplifies today and complicates tomorrow. Use full end‑to‑end TLS; otherwise, you create blind spots and potential data exposure.
A closing nudge
Security that stays out of the way is the best kind. Set a calm baseline, automate renewals, and bake TLS checks into your deploys. Treat SSL like the plumbing behind your storefront—rarely seen, utterly essential. And yes, give it the same respect you give your mission‑critical Software: documented, monitored, and a little bit boring… which is exactly how you want your security to feel.