The padlock isn't the whole story: what SSL actually protects
When a visitor lands on your website and sees a small padlock in the address bar, with https:// instead of http://, they know — often without consciously thinking about it — that the connection is encrypted. Technically, this means the data exchanged between their browser and your server (a filled-out contact form, login credentials, information entered at checkout) travels encrypted, unreadable to anyone who might intercept the traffic along the way. That's the core purpose of the SSL/TLS protocol and the certificate behind it: protecting the confidentiality of the exchange. The absence of this encryption also has a very visible effect: modern browsers like Chrome, Firefox, and Safari display an explicit 'Not Secure' warning for any site running plain HTTP, which understandably worries visitors and hurts the business's credibility, especially for an online store or a quote request form. But here's the part that's often misunderstood: seeing the green padlock and https:// in the address bar doesn't mean everything is correctly configured. Many businesses stop right there, assuming the matter is settled once and for all when the certificate is installed, when in fact a solid SSL/TLS setup has several layers — and any one of them can quietly degrade over time without any visible warning.
Certificate expiry: an avoidable outage that happens far too often
An SSL certificate isn't valid indefinitely: it has an expiry date, typically ranging from three months to a year depending on the certificate authority used. Most modern hosting providers automate renewal, especially with free certificates like Let's Encrypt, but that automation can fail silently — a server configuration change, a hosting migration, a manual renewal step that gets forgotten — and no one notices until the certificate actually expires. On that day, every visitor to the site sees an alarming red warning along the lines of 'Your connection is not private,' and the vast majority leave the page immediately without even trying to continue, out of reasonable caution. For a business, this is effectively a full site outage in the eyes of the public, with a direct loss of sales, quote requests, and credibility — often discovered not internally, but because a client calls to report that the site is showing a strange error message. It's a particularly frustrating outage because it's almost always avoidable: it just takes monitoring the certificate's expiry date and periodically verifying that automatic renewal is actually working, rather than simply assuming it takes care of itself.
HTTPS without a forced redirect: an unsecured back door
Another common pitfall: the site responds correctly over HTTPS, but is also still reachable over plain HTTP, with no automatic redirect from one to the other. In that case, a visitor arriving via an old link, a bookmark saved long ago, a link shared on social media, or simply by typing the address without the s in https, ends up on the unencrypted version of the site without even realizing it. Their exchanges with the site are then unprotected, exactly as if the SSL certificate didn't exist at all. Best practice is to systematically force every HTTP request to redirect to the HTTPS version, so there's no unsecured path into the site left at all. A related issue is mixed content: a page loaded over HTTPS that still pulls in some resources — images, scripts, stylesheets — via plain HTTP links, often left over from an older version of the site that was never fully updated. This mix partially breaks the protection HTTPS is supposed to provide and can trigger additional browser warnings. Both situations are invisible to a visitor who isn't closely watching the address bar, which makes them particularly deceptive: the site looks secure, but isn't always actually secure.
Missing security headers: HSTS, CSP, and the invisible protections
The SSL certificate is only part of the equation. Once an encrypted connection is established, several HTTP security headers reinforce — or fail to reinforce — the site's protection. HSTS (HTTP Strict Transport Security) tells the browser to always connect over HTTPS for that domain, even if a link mistakenly points to the HTTP version, eliminating the risk described above. CSP (Content Security Policy) restricts which sources are allowed to execute code on the page, sharply reducing the impact of a potential malicious script injection. Other headers like X-Frame-Options or X-Content-Type-Options close off classic entry points used in certain attacks. The problem is that these headers are almost never enabled by default on standard hosting or CMS setups, and their absence is completely invisible to a visitor, or even to the site owner — there's no broken padlock, no alert message. Yet these gaps are exactly what security scanning tools pick up on, and increasingly what corporate clients check during a vendor security review before signing with a new supplier or partner. They also play a role, even if secondary, in how Google evaluates a site's overall trustworthiness, with HTTPS and its associated best practices factoring into search ranking.
How to check all of this in a few seconds
SSL/TLS configuration isn't something to set once at launch and forget: it deserves periodic review, especially after switching hosting providers, migrating the site, or updating the CMS. Checking it properly normally takes time and technical know-how — verifying the certificate's validity and expiry date, testing whether HTTP redirects to HTTPS, confirming security headers are in place — but EBH Security built a free tool to simplify this step: sslcheck.ebh.ma, part of the EBH Defender suite. In a few seconds, it analyzes your site's SSL certificate and security headers and returns the results in plain language, flagging what needs fixing. For a Moroccan SME without a dedicated technical team, it's a simple way to make sure what visitors and search engines actually see on your site matches what you think you've set up.