Blog / security monday
SSL beyond the padlock
Getting a certificate is the easy part: this Security Monday covers redirects, HSTS in plain terms, mixed content and keeping renewals boring.
For June's Security Monday we are looking at SSL, and specifically at everything after the padlock appears. Free certificates from Let's Encrypt made the hard part easy years ago, and every hosting account on our servers gets one. But we still see plenty of sites where the certificate is installed and the job is half done. Here is the other half.
Force the redirect, once, properly
A certificate does nothing for a visitor who arrives over plain HTTP and stays there. Every request to the http:// version of your site should get a permanent redirect to https://, no exceptions, no pages left behind.
Check yours now: type your domain with http:// in front and watch the address bar. If it does not land on https://, fix that today. In cPanel this is a toggle, or a short rule in your .htaccess file.
Two details worth getting right. Use a permanent (301) redirect so search engines consolidate onto the secure version, and redirect in one hop rather than bouncing through www and non-www variants on the way. Chains of redirects are slower for visitors and messier for SEO.
HSTS, in plain terms
Here is the small gap redirects leave. That very first http:// request still travels unencrypted before the redirect happens, and on a hostile network (think airport wifi) that request can be intercepted.
HSTS closes the gap. It is one response header that tells the browser: for the next several months, never contact this site over plain HTTP at all. After the first visit, the visitor's own browser upgrades every request to HTTPS before it leaves the machine. No insecure hop, nothing to intercept.
One honest caution from us. HSTS is a promise with a memory. Once browsers have seen it, they will refuse plain HTTP to your domain until the timer runs out, so if your certificate setup breaks later, visitors get a hard error rather than a quiet fallback. Turn it on after your HTTPS setup has been stable for a while, start with a modest timeout, and lengthen it once you are confident. Set up in that order, it is a strict upgrade.
Hunting mixed content
Mixed content is the padlock's most common ailment: the page loads over HTTPS but some image, stylesheet or script on it is still requested over http://. Browsers respond by downgrading the padlock or quietly blocking the resource, which is why "my site is secure but looks broken" tickets are usually this.
On WordPress the causes are predictable. Old post content with hard-coded http:// image URLs, a theme option where the logo was entered years ago, or the site URL setting itself still reading http. The browser console will name every offending resource: open developer tools on an affected page and read the warnings.
Fixing it is mostly search-and-replace on the database, swapping your old http:// address for the https:// one. Take a backup first, as always. We went into what a restore-ready backup looks like in backups that actually restore, and this is exactly the kind of five-minute job that deserves one.
Renewal hygiene: make expiry boring
Certificates expire on purpose, and Let's Encrypt certificates renew automatically on any properly run host, ours included. So why does anyone still see expiry errors? Because automation fails quietly. A DNS change points the domain somewhere new and validation starts failing, or the domain moves but an old renewal keeps limping along. Nobody notices until browsers start throwing warnings.
The hygiene is simple. Know how your certificate renews, and make sure something will tell you if it stops. Most uptime monitors can watch certificate expiry and warn you weeks out; that single check turns a public outage into a quiet ticket. And whenever you change DNS or move the site, glance at the certificate afterward. It takes ten seconds.
The padlock is the start
Redirects everywhere, HSTS once you are stable, no mixed content, and renewals that are watched rather than assumed. That is HTTPS done properly rather than nominally.
If the padlock on your site is doing anything odd and you host with us, send the details to support and we will find the loose wire.