An SSL Certificate Is Not Enough: What Your Website Really Needs

Ask any business owner whether their website is secure, and the most common answer is: "Yes, we have an SSL certificate. There is a padlock in the browser." This answer reveals a widespread misunderstanding of what SSL/TLS actually does and, more importantly, what it does not do.

An SSL certificate is one piece of a security puzzle. An important piece, certainly. But if your only security measure is the SSL certificate, your website is not secure. It is like locking the front door of your house while leaving every window open. The lock is doing its job. The house is still vulnerable.

This article clarifies exactly what SSL/TLS protects, what it leaves exposed, and what additional security layers your business website needs.

What SSL/TLS Actually Protects

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) provide one thing: encryption of data in transit between the visitor's browser and your web server. When someone visits your HTTPS website, the data they send (form submissions, login credentials, payment information) and the data they receive (page content, images, files) is encrypted during transmission. Anyone intercepting the traffic (on a public WiFi network, at an internet service provider, or anywhere along the network path) sees encrypted gibberish instead of readable data.

This is what the padlock icon means. The connection between the browser and the server is encrypted. The data is protected while it is moving.

Specifically, SSL/TLS Protects Against:

• Eavesdropping: Someone on the same network cannot read the data being exchanged between the browser and the server.
• Man-in-the-middle attacks (in transit): An attacker cannot insert themselves between the browser and the server to read or modify data as it passes through. The certificate authenticates the server's identity, so the browser knows it is talking to the real server and not an impersonator.
• Data tampering in transit: The encrypted connection includes integrity checks. If data is modified during transmission, the browser detects it and rejects the connection.

These are real and valuable protections. HTTPS should be enabled on every website, period. But they are protections for a specific threat: interception of data as it moves from point A to point B. They say nothing about the security of point A or point B themselves.

What SSL/TLS Does Not Protect

Here is where the false sense of security becomes dangerous. SSL/TLS does not protect:

Your Web Application

If your website has a SQL injection vulnerability in a contact form, SSL does not help. The attacker's malicious input is encrypted in transit just like legitimate input. It arrives at your server, gets decrypted, and the SQL injection executes. The encryption protected the attack payload during transmission.

The same applies to XSS, CSRF, file upload vulnerabilities, authentication bypass, and every other application-layer vulnerability. SSL encrypts the channel. It does not inspect or validate the data flowing through it.

Your Server Configuration

If your server has open ports, default credentials, exposed admin panels, or misconfigured permissions, SSL does not help. These are server-side issues that exist independently of whether the connection is encrypted.

Your CMS and Its Plugins

If you are running an outdated WordPress with vulnerable plugins, SSL does not help. The attacker exploits the plugin vulnerability through an HTTPS connection. The encryption is irrelevant to the exploit.

Data at Rest

SSL protects data in transit. It says nothing about data at rest. If your database stores customer information unencrypted, and an attacker gains access to the database (through a SQL injection, a compromised admin account, or a server breach), they read the data in plain text. SSL was never involved because the data was not in transit at that point.

Phishing

This is particularly dangerous. Attackers can (and do) get SSL certificates for phishing sites. The padlock appears in the browser for phishing domains just as it does for legitimate ones. A user who has learned "padlock = safe" will trust a phishing site that has HTTPS. The padlock means the connection is encrypted. It does not mean the website is trustworthy.

Let's Encrypt issues free SSL certificates to anyone who controls a domain. No identity verification is required for Domain Validation (DV) certificates. An attacker who creates yourbank-login-secure.com can get a valid SSL certificate for it in minutes.

Mixed Content: When HTTPS Is Not Really HTTPS

Mixed content occurs when an HTTPS page loads some resources (images, scripts, stylesheets, fonts, iframes) over HTTP. This partially undermines the HTTPS protection because:

• Mixed active content (scripts, iframes): Modern browsers block this by default. If your HTTPS page tries to load a JavaScript file over HTTP, the browser blocks the script. Your site may break without obvious explanation.
• Mixed passive content (images, videos): Browsers may still load these but display a warning. The padlock icon may disappear or show a warning indicator. More importantly, an attacker on the network can replace the HTTP-loaded image with a malicious one.

Mixed content is a common issue on websites that were upgraded from HTTP to HTTPS without thoroughly updating all internal links and resource references. Every http:// link to an image, script, or stylesheet on your own site needs to be changed to https:// (or protocol-relative //). Third-party resources loaded over HTTP need to be updated to their HTTPS equivalents or removed.

Use browser developer tools (F12 > Console) to find mixed content warnings, or run a tool like Why No Padlock to scan your site for mixed content issues.

HSTS: Making HTTPS Mandatory

Even with a valid SSL certificate and no mixed content, there is a gap: the first time a user visits your site, they might use HTTP. Their browser sends a regular HTTP request. Your server redirects to HTTPS. But that initial HTTP request is unencrypted and can be intercepted.

HSTS (HTTP Strict Transport Security) closes this gap by telling the browser: "From now on, always use HTTPS for this domain. Never send an HTTP request." After the first HTTPS visit, the browser remembers this instruction for the duration specified in the max-age parameter.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS Preloading

HSTS still has a weakness: the very first visit can be over HTTP (before the browser has seen the HSTS header). HSTS preloading eliminates this by adding your domain to a list hardcoded into browsers. Browsers check this list before making any request, so even the first visit is HTTPS.

To be added to the preload list, your site must serve a valid HSTS header with max-age of at least one year, include includeSubDomains, and include preload. You then submit your domain at hstspreload.org. This is a serious commitment: removing your domain from the preload list takes months, and during that time, your entire domain and all subdomains must support HTTPS.

For a detailed implementation guide, see our article on HTTP security headers your website needs.

Common SSL/TLS Misconfigurations

Having an SSL certificate is not the same as having it properly configured. Common misconfigurations we find during security assessments of Swiss business websites:

Expired Certificates

SSL certificates have an expiration date (typically 90 days for Let's Encrypt, 1 year for paid certificates). When a certificate expires, browsers display a full-page warning that scares away every visitor. Automated renewal should be configured, but it fails more often than you would expect (renewal scripts break, hosting providers change configurations, DNS issues prevent validation).

Incomplete Certificate Chain

Your server needs to send not just its own certificate but also the intermediate certificates that chain back to a trusted root certificate authority. If intermediate certificates are missing, some browsers (especially on mobile devices) will show a warning because they cannot verify the chain. This is a server configuration issue that is invisible to the site owner testing on their desktop browser (which may cache the intermediate certificate from a previous visit).

TLS 1.0 and 1.1 Still Enabled

TLS 1.0 (1999) and TLS 1.1 (2006) have known vulnerabilities and are deprecated by all major browsers. If your server still supports these versions, it is vulnerable to downgrade attacks where an attacker forces the connection to use the older, weaker protocol. Your server should only support TLS 1.2 and TLS 1.3.

Weak Cipher Suites

The cipher suite determines the specific encryption algorithms used for the connection. Some cipher suites are weak or broken (RC4, DES, 3DES, export ciphers). If your server offers weak cipher suites, an attacker can force the connection to use them. Modern server configurations should only offer strong cipher suites (AES-GCM, ChaCha20-Poly1305).

Missing OCSP Stapling

OCSP (Online Certificate Status Protocol) lets browsers check if a certificate has been revoked. Without OCSP stapling, the browser has to contact the certificate authority's OCSP server directly, which is slow, unreliable, and a privacy concern (the CA learns which sites the user visits). OCSP stapling has your server include the OCSP response with the TLS handshake, solving all three problems.

How to Test Your SSL Configuration

Two free tools provide a thorough assessment:

• SSL Labs Server Test (ssllabs.com/ssltest/): Tests your server's SSL/TLS configuration and gives a grade from A+ to F. Checks certificate validity, protocol support, cipher suites, and known vulnerabilities.
• Security Headers (securityheaders.com): Checks for HSTS and other security headers. While not SSL-specific, it covers the transport security layer that complements your SSL certificate.

The Full Security Stack for a Business Website

SSL/TLS is one layer. Here is what the complete security stack looks like:

Layer	What It Protects	Technologies
Transport encryption	Data in transit	SSL/TLS certificate, HSTS, proper TLS configuration
Network protection	Server from network attacks	Firewall, DDoS protection, IP filtering
Application firewall	Web application from attacks	WAF (Web Application Firewall), rate limiting
Security headers	Browser behavior	CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
Input validation	Application from injection attacks	Server-side validation, parameterized queries, output encoding
Access control	Admin areas	Strong authentication, MFA, IP restriction, non-default URLs
Software updates	Against known vulnerabilities	Regular patching of CMS, plugins, PHP/Node.js, server software
Backup and recovery	Against data loss	Automated backups, tested restores, off-site storage
Monitoring	Early detection of problems	File integrity monitoring, uptime monitoring, log analysis, Google Search Console

Each layer addresses a different category of threats. No single layer is sufficient on its own. An SSL certificate covers the first row. The other eight rows are what most business websites are missing.

What Your Web Agency Should Provide

When you commission a website, these should be included by default:

• Valid SSL/TLS certificate with automatic renewal
• HSTS header configured
• TLS 1.2 and 1.3 only (no older protocols)
• No mixed content
• Security headers (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
• Server-side input validation on all forms
• Admin panel protection (non-default URL, IP restriction, MFA)
• Automatic security updates for CMS core
• Regular backup schedule

If your agency does not provide these, they are delivering an incomplete product. You would not accept a car without seatbelts because "the engine works fine." The same principle applies to websites.

SSL for Different Use Cases

Domain Validation (DV) Certificates

DV certificates verify that you control the domain. They provide encryption but no identity verification. Let's Encrypt provides free DV certificates. They are appropriate for most business websites, blogs, and informational sites.

Organization Validation (OV) Certificates

OV certificates verify the organization behind the domain. The certificate authority checks that the organization exists and controls the domain. These provide slightly more trust but are not visually different from DV certificates in modern browsers.

Extended Validation (EV) Certificates

EV certificates require extensive verification of the organization's legal identity and physical existence. They used to display the company name in the browser's address bar (the "green bar"), but most modern browsers no longer show this distinction. The additional cost of EV certificates provides minimal practical benefit for most businesses.

Wildcard Certificates

A wildcard certificate (*.yourcompany.ch) covers all subdomains of your domain. This is convenient if you have multiple subdomains (blog.yourcompany.ch, shop.yourcompany.ch, portal.yourcompany.ch). Be aware that if the certificate's private key is compromised, all subdomains are affected.

The Cost of Proper SSL vs. the Cost of Doing It Wrong

Approach	Cost	Risk
No SSL at all	Free	All data transmitted in plain text. Google ranking penalty. Browser warnings scare away visitors. Not compliant with nLPD/GDPR for sites handling personal data.
SSL only (no other security)	CHF 0-100/year	Data in transit is protected. Everything else is vulnerable. False sense of security.
SSL + security headers + WAF + updates + monitoring	CHF 2,000-10,000/year	Comprehensive protection. Dramatically reduced attack surface. Early detection of issues.

The difference between option 2 and option 3 is the difference between locking the front door and actually securing the building. The cost difference is modest. The risk difference is enormous.

What You Should Do Now

1. Test your SSL configuration. Run ssllabs.com/ssltest/ on your domain. If your grade is below A, you have configuration issues that need fixing.
2. Check for mixed content. Visit your site and open the browser console (F12). Look for mixed content warnings.
3. Verify HSTS is enabled. Check your response headers (using browser developer tools or securityheaders.com). If HSTS is missing, add it.
4. Assess the rest of your security stack. SSL is just the beginning. What about security headers? Input validation? Access control? Software updates? Monitoring?
5. Get a professional assessment. A website security audit evaluates all layers, not just the SSL certificate. Contact our team in Lugano for a thorough assessment of your website's security posture.

The padlock icon means your connection is encrypted. It does not mean your website is secure. Understanding the difference is the first step toward actual security.