SSL certificate: why your website needs HTTPS

When a visitor opens your site over HTTPS, the browser and server first negotiate an encrypted connection. The certificate proves the server belongs to your domain. Encryption ensures nobody along the way can read or alter passwords, orders or form input.

The name SSL has stuck, but the underlying protocol has been called TLS (Transport Layer Security) for years. Modern servers use TLS 1.2 or 1.3. Older versions (1.0 and 1.1) are considered insecure and should be disabled. Looking only at the padlock in the address bar misses that nuance: a lock icon does not tell you whether your TLS configuration is still current.

HTTPS is no longer optional. Browsers mark HTTP pages as not secure. Unencrypted forms are a privacy risk under the GDPR. Search engines favour HTTPS pages. For a keurmerk or a serious security measurement, everything starts with a valid certificate and an enforced HTTPS connection.

Certificates differ in how strictly the applicant is verified, not in the strength of the encryption. For most websites a free domain-validated certificate is enough. Let's Encrypt issues those certificates at no cost and is included with many hosting plans.

Wildcard certificates cover all subdomains under one name (*.example.com). Multi-domain certificates (SAN) bundle several hostnames. Choose what fits your setup, but always leave automatic renewal on. Most incidents we see in scans are not the wrong certificate type, but a certificate that quietly expired.

Installing a certificate is step one. Making sure visitors always arrive over HTTPS is step two. Set up an automatic redirect from HTTP to HTTPS (preferably a permanent 301). Without that redirect, the unencrypted variant stays reachable even when the certificate itself is fine.

Then add the Strict-Transport-Security (HSTS) header. That header instructs browsers to access your site exclusively over HTTPS from then on, even when someone types the address without https. A common starting value is a max-age of at least one year (31536000 seconds), ideally with includeSubDomains if all your subdomains support HTTPS.

HSTS is one of the security headers the WebYes scan checks within the security pillar. If the header is missing, or the certificate is expired or invalid, you see it in the report. The HTTP-to-HTTPS redirect belongs there too: without it, an unsafe route remains open. Content Security Policy is a related layer; see Content Security Policy for how that header limits what may run in the browser.

Three problems keep showing up in scans. First: a certificate that quietly expired because auto-renewal was never set up, or because DNS or firewall rules blocked renewal. Second: mixed content, an HTTPS page loading images, scripts or stylesheets over HTTP, which still triggers a browser warning. Third: old TLS versions left enabled on the server.

All three are preventable. Enable automatic renewal and check the expiry date periodically. Load all assets over HTTPS (relative or protocol-relative URLs are often the culprit). Have your hosting provider disable TLS 1.0 and 1.1 and support at least TLS 1.2, preferably also 1.3.

Less obvious, but just as painful: a certificate for www.example.com while visitors land on example.com (or the other way around), without both names on the certificate or a clean redirect. Always test both hostnames.

A quick first check happens in the browser. Open your site over HTTPS and click the padlock in the address bar. You will see whether the connection is secure, who issued the certificate, and until when it is valid. If the padlock is missing, or the browser shows a warning, something is wrong with the certificate or the chain.

Then check the redirect. Type the address deliberately with http:// (without the s) and see whether you land on https:// automatically. If the HTTP variant stays reachable without a redirect, the unencrypted route is still open. Also test www and non-www: both hostnames need a valid certificate or a clean redirect between them.

For a practical check on certificate, HTTPS redirect and security headers, use the WebYes scan on the homepage, or request a scan via contact. We do not ship a standalone SSL checker: the scan covers those points within the security pillar, including headers such as HSTS. Content Security Policy is explained under Content Security Policy; the broader header set lives under security headers. For an independent standards check, the Internet.nl test remains a good second step. If you are considering an ongoing keurmerk, see pricing.

The free WebYes scan tests HTTPS within the security pillar: whether HTTP redirects to HTTPS, whether the certificate is valid, and whether security headers (including HSTS) are present. For the WebYes keurmerk the average across all pillars must be at least 80, and each pillar (including security) at least 60. A weak or missing certificate pulls that pillar down immediately.

For a deeper check on modern internet standards (TLS configuration, DNSSEC, and more), the Internet.nl website test is a useful complement. It looks broader at standards than the padlock alone. Read more in our guide to the Internet.nl test when you want to put both measurements side by side.

Practical advice: start with the WebYes scan for a quick diagnosis on certificate, redirect and headers. Fix the open items. Then run an Internet.nl test if you want to know whether your TLS setup also meets the stricter standards check. That way you combine a product scan with an independent reference test. A valid certificate alone is not enough for the security pillar: without HSTS and an HTTPS redirect the score stays under the keurmerk floor of 60 per pillar, even if the padlock looks green.