Ten years ago HTTPS meant buying certificates and wrestling with server configs. Today certificates are free and renew themselves, and any CDN gives you TLS by default. Yet scans still find the same handful of configuration mistakes on real sites. Here is what a healthy setup looks like.

Protocols: TLS 1.2 and 1.3 only

TLS 1.0 and 1.1 are formally deprecated and every modern browser has dropped them. Leaving them enabled adds no compatibility worth having and keeps known-weak cryptography reachable. Mozilla's server-side TLS guidance calls the intermediate configuration (1.2 + 1.3) the right choice for general websites.

One certificate, valid everywhere

The certificate must cover both yourdomain.com and www.yourdomain.com, be renewed automatically, and present a complete chain. An expired certificate takes your site down as effectively as a server crash, and with HSTS enabled visitors cannot even click through.

Force the redirect

Plain http:// requests should answer with a permanent redirect to HTTPS, on every path, not just the homepage. Sites often redirect the homepage but leave deep links reachable over HTTP. Once the redirect is solid, add HSTS so browsers stop making insecure first requests at all.

No mixed content

A secure page that loads even one script or image over plain HTTP undermines the whole thing: browsers block some of it, warn about the rest, and the padlock degrades. Mixed content usually creeps in through hardcoded http:// URLs in old content and themes. Search your database and templates, or let your CDN rewrite it.

Test it

curl -sI http://yourdomain.com          # expect 301 to https
curl -sI https://yourdomain.com          # expect 200 and your security headers

A free AuditMerlin scan performs the TLS handshake, checks protocol versions and certificate validity, verifies the redirect, and maps each finding to the Mozilla guideline behind it.