SSL/TLS Certificates Explained: What They Are and Why They Matter

Why SSL/TLS Still Trips People Up

You would think that by now, SSL/TLS would be a solved problem. Every browser shows a padlock. Let's Encrypt made certificates free. Hosting providers offer one-click HTTPS. And yet, we still encounter misconfigured certificates on production websites every single week. Expired certs, broken chains, mixed content warnings, missing HSTS headers. These are not edge cases. They are routine failures that erode trust and hurt search rankings.

This guide breaks down how TLS actually works, what the different certificate types mean in practice, how to automate certificate management, and which misconfigurations we see most often when auditing websites for businesses across Lugano and Switzerland.

A Quick History: SSL, TLS, and Why the Names Persist

SSL (Secure Sockets Layer) was developed by Netscape in the mid-1990s. SSL 2.0 shipped in 1995, SSL 3.0 in 1996. Both had serious cryptographic flaws. TLS (Transport Layer Security) 1.0 replaced SSL 3.0 in 1999, and the protocol has evolved through TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018).

Today, only TLS 1.2 and TLS 1.3 are considered secure. All major browsers have dropped support for TLS 1.0 and 1.1. Despite this, people still say "SSL certificate" because the term stuck. When we say SSL certificate in this article, we mean a certificate used with the TLS protocol.

How the TLS Handshake Works

Every time your browser connects to an HTTPS website, a TLS handshake happens before any data is exchanged. Understanding this process helps you diagnose problems when things go wrong.

TLS 1.2 Handshake (Simplified)

1. Client Hello - The browser sends the server a list of cipher suites it supports, its TLS version, and a random number.
2. Server Hello - The server picks a cipher suite from the client's list, sends its own random number, and its certificate.
3. Certificate Verification - The browser checks the certificate against its trusted Certificate Authority (CA) store. It verifies the chain of trust, the expiration date, and the domain name.
4. Key Exchange - Using the agreed cipher suite, both sides generate a shared secret (pre-master secret). With RSA key exchange, the client encrypts it with the server's public key. With Diffie-Hellman (DHE/ECDHE), both sides contribute to generating the shared secret.
5. Session Keys - Both sides derive symmetric session keys from the shared secret and the random numbers.
6. Finished - Both sides send a "Finished" message encrypted with the new session keys, confirming the handshake succeeded.

This process takes two round trips (2-RTT) in TLS 1.2.

TLS 1.3 Handshake: Faster and Simpler

TLS 1.3 cuts this to a single round trip (1-RTT). It removes outdated cipher suites, mandates forward secrecy (only ECDHE key exchange), and combines steps. The result: faster connection setup and stronger security by default.

TLS 1.3 also supports 0-RTT resumption for returning visitors, though this feature has replay attack risks and should be configured carefully.

Feature	TLS 1.2	TLS 1.3
Handshake round trips	2-RTT	1-RTT (0-RTT resumption)
Forward secrecy	Optional (depends on cipher)	Mandatory
RSA key exchange	Supported	Removed
Cipher suites	37+	5
Known vulnerabilities	BEAST, POODLE (mitigated)	None currently

Certificate Types: DV, OV, and EV

Not all certificates are created equal. The three main types differ in validation level, cost, and what they communicate to users.

Domain Validated (DV) Certificates

DV certificates prove that you control the domain. The CA verifies this through one of three methods: placing a specific file on your web server, adding a DNS TXT record, or responding to an email at an admin address on the domain. The process is fully automated and takes minutes.

Cost: Free (Let's Encrypt, ZeroSSL) to ~$10/year

Best for: Blogs, personal sites, small business websites, most web applications

Limitation: Anyone can get one, including phishing sites. A DV certificate says "the connection is encrypted," not "the site is legitimate."

Organization Validated (OV) Certificates

OV certificates require the CA to verify that the organization behind the domain actually exists. This involves checking business registration documents, phone verification, and sometimes physical address confirmation. The process takes 1-3 business days.

Cost: $50-$200/year

Best for: Business websites where organizational identity matters

Limitation: Browsers don't visually distinguish OV from DV certificates. Users would need to inspect the certificate details to see the difference.

Extended Validation (EV) Certificates

EV certificates require the most rigorous validation. The CA verifies legal existence, operational existence, physical address, and that the applicant has authority to request the certificate. This process can take 1-2 weeks.

Cost: $100-$500+/year

Historical context: EV certificates used to display the company name in a green address bar. All major browsers removed this visual distinction between 2019 and 2020. Chrome, Firefox, Safari, and Edge now show the same padlock for all valid certificates.

Current value: Debatable. Some regulated industries still require them, and some argue that the rigorous vetting process filters out bad actors. But the practical user-facing benefit has largely disappeared.

Let's Encrypt and the ACME Protocol

Let's Encrypt launched in 2016 and fundamentally changed the certificate landscape. It provides free DV certificates using the ACME (Automatic Certificate Management Environment) protocol, which automates the entire issuance and renewal process.

How ACME Works

The ACME protocol defines a standard way for a client (like Certbot) to prove domain control to a CA (like Let's Encrypt) and receive a certificate.

1. The client generates an account key pair and registers with the CA.
2. The client requests a certificate for a domain, and the CA responds with a set of challenges.
3. The client completes a challenge (HTTP-01: place a file at /.well-known/acme-challenge/, or DNS-01: create a DNS TXT record).
4. The CA verifies the challenge and issues the certificate.
5. The client installs the certificate and schedules renewal (Let's Encrypt certs are valid for 90 days).

Automation Tools

• Certbot - The original ACME client. Works with Apache and Nginx. Run certbot --nginx and it handles everything.
• acme.sh - A shell-script-based ACME client. Lightweight, no dependencies beyond shell and curl.
• Caddy - A web server with built-in automatic HTTPS. It obtains and renews certificates without any configuration.
• Traefik - A reverse proxy that handles Let's Encrypt certificates automatically for containerized applications.

The 90-Day Validity Window

Let's Encrypt certificates expire after 90 days, which is intentional. Shorter validity periods reduce the damage window if a private key is compromised and encourage automation. If you set up auto-renewal correctly, you never think about it again. If you don't, you will wake up to an expired certificate and a site that browsers are blocking.

We have seen businesses in Lugano lose entire days of web traffic because a Let's Encrypt renewal cron job silently failed. Automation only works if you monitor it.

Common Misconfigurations We See in Audits

When we perform website security assessments for clients, certificate problems are among the most frequent findings. Here are the ones we encounter repeatedly.

1. Mixed Content

This happens when a page is served over HTTPS but loads some resources (images, scripts, stylesheets, fonts) over HTTP. Browsers will block mixed active content (scripts, iframes) and may warn about mixed passive content (images).

How to find it: Open your browser's developer console and look for mixed content warnings. Or use a tool like mixed-content-scan to crawl your entire site.

How to fix it: Update all resource URLs to use HTTPS or protocol-relative URLs. Better yet, use relative paths where possible. Set a Content-Security-Policy header with upgrade-insecure-requests as a safety net.

2. Expired Certificates

A certificate with an expired validity period causes browsers to show a full-page warning. Most users will not click through it. Your site is effectively offline.

Prevention: Automate renewal and monitor certificate expiry dates. Set up alerts at 30, 14, and 7 days before expiry. Services like SSL Labs can be used for periodic checks.

3. Incomplete Certificate Chain

Your certificate is signed by an intermediate CA, which is signed by a root CA. Browsers have root CAs in their trust store but not always the intermediates. Your server needs to send the full chain: your certificate plus all intermediate certificates.

If the intermediate is missing, some browsers (especially on mobile or older systems) will fail to validate the certificate even though it is perfectly valid. Desktop Chrome and Firefox often work fine because they can fetch missing intermediates, which makes this bug hard to catch during development.

How to test: Run your domain through SSL Labs. It will flag chain issues. Also test on multiple devices, especially Android phones and older browsers.

4. Wrong Domain / SAN Mismatch

The certificate's Common Name or Subject Alternative Names (SAN) must match the domain the user is visiting. A certificate for example.com will not work for www.example.com unless www.example.com is listed as a SAN.

Wildcard certificates (*.example.com) cover first-level subdomains but not the bare domain itself, and not second-level subdomains like sub.api.example.com.

5. Using TLS 1.0 or 1.1

Some servers still have TLS 1.0 or 1.1 enabled for "compatibility." This compatibility serves almost no one at this point and exposes you to known vulnerabilities. Disable them.

6. Weak Cipher Suites

Supporting ciphers like RC4, 3DES, or export-grade ciphers is a security risk. Modern configurations should support only AEAD ciphers (AES-GCM, ChaCha20-Poly1305) with forward secrecy.

Mozilla's SSL Configuration Generator provides copy-paste configurations for Nginx, Apache, and other servers.

HSTS: HTTP Strict Transport Security

Even with HTTPS configured perfectly, a user who types example.com in their browser will initially make an HTTP request. The server redirects to HTTPS, but that first request is unencrypted and vulnerable to a man-in-the-middle attack (SSL stripping).

HSTS solves this. When you send the header:

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

The browser remembers that your site should only be accessed over HTTPS. For the duration of max-age (one year in this example), the browser will automatically convert any HTTP requests to HTTPS before sending them.

HSTS Preloading

The preload directive lets you submit your domain to the HSTS preload list, which is hardcoded into browsers. This means even the very first visit to your site will use HTTPS. It is a strong protection, but also hard to undo. Make sure your HTTPS setup is solid before enabling preload.

For a deeper look at HSTS and other security headers, see our complete security headers guide.

SSL/TLS and SEO

Google confirmed HTTPS as a ranking signal back in 2014. While it was initially described as a "lightweight" signal, it has become a baseline expectation. Sites without HTTPS are flagged with "Not Secure" warnings in Chrome, which directly affects user behaviour.

Here is what we have observed working with clients on website security in Lugano and across Switzerland:

• Trust signals matter. A "Not Secure" warning in the address bar increases bounce rates. Users, especially those about to enter personal data or make a purchase, will leave.
• HTTPS is required for HTTP/2 and HTTP/3. These protocols offer significant performance improvements (multiplexing, header compression, 0-RTT connection resumption). Without HTTPS, browsers fall back to HTTP/1.1.
• Some browser APIs require a secure context. Geolocation, service workers, push notifications, and the Clipboard API all require HTTPS.
• Referrer data is lost. When traffic goes from an HTTPS site to an HTTP site, the referrer header is stripped. Your analytics will show this traffic as "direct" instead of properly attributed.

Certificate Transparency

Certificate Transparency (CT) is a public logging system where CAs must record every certificate they issue. This makes it possible to detect misissued or fraudulently obtained certificates.

Why It Matters

Before CT, a compromised or rogue CA could issue a certificate for your domain, and you would never know until it was used in an attack. CT logs let domain owners monitor for unauthorized certificates.

How to Monitor

• crt.sh - A free search engine for CT logs. Enter your domain to see every certificate ever issued for it.
• Facebook Certificate Transparency Monitoring - Sends you notifications when a new certificate is issued for your domain.
• Certspotter - A monitoring tool that alerts you to new certificates in CT logs.

If you see a certificate you did not request, someone either compromised your domain verification or a CA made an error. Either way, you need to act fast: revoke the certificate and investigate.

Practical Recommendations

Based on hundreds of security assessments, here is what we recommend for any business running a website:

1. Use TLS 1.2 as the minimum. Disable TLS 1.0 and 1.1. If possible, prefer TLS 1.3.
2. Automate certificate management. Use Let's Encrypt with Certbot, or use a provider that handles certificates automatically (Cloudflare, Vercel, Netlify).
3. Monitor certificate expiry. Even with automation, things fail. Set up monitoring.
4. Enable HSTS. Start with a short max-age (e.g., 300 seconds), test thoroughly, then increase to one year.
5. Check your certificate chain. Use SSL Labs to verify the full chain is served correctly.
6. Eliminate mixed content. Audit every page, not just the homepage.
7. Monitor CT logs. Know when certificates are issued for your domains.
8. Use strong cipher suites. Follow Mozilla's Modern or Intermediate configuration.

When to Consider Paid Certificates

Let's Encrypt is sufficient for the vast majority of websites. However, there are cases where a paid certificate makes sense:

• Wildcard certificates with HTTP validation - Let's Encrypt supports wildcards but only via DNS-01 challenges, which require DNS API access. If your DNS provider doesn't support API-based updates, a paid wildcard certificate may be simpler.
• Regulatory requirements - Some industries or compliance frameworks require OV or EV certificates.
• Extended warranty - Paid certificates often include a warranty (e.g., $250,000-$1,750,000) that covers damages if the CA issues a fraudulent certificate. In practice, these warranties are rarely if ever claimed, but some enterprise procurement processes require them.
• Support - With Let's Encrypt, you are on your own (plus community forums). Paid CAs offer direct support.

Wrapping Up

SSL/TLS certificates are a foundational layer of web security. Getting them right is not difficult, but it does require attention to details that are easy to overlook: certificate chains, renewal automation, mixed content, HSTS headers, and cipher suite configuration.

If you are unsure about your current setup, run your domain through SSL Labs and see what comes back. If the grade is anything below an A, there is work to do.

Need help securing your website or want a professional security assessment? Get in touch with our team in Lugano. We help businesses across Switzerland with website security, from certificate configuration to full security audits.