Guides · ← All guides
TLS/SSL Basics: What Your Certificate Says About Your Site
Last updated: October 13, 2026 · 8 min read
The padlock in the browser bar is the most visible security signal on the web, and one of the most misunderstood. Site owners tend to treat TLS as a checkbox: certificate installed, padlock showing, done. But security assessments keep flagging TLS configurations, because the padlock only tells you encryption exists. It says nothing about whether it's configured well. Here's what actually matters, and how to check it yourself in about two minutes.
What TLS does (and doesn't do)
TLS encrypts traffic between your visitors and your server, and the certificate proves your server is who it claims to be. What it does not do: prove your site is trustworthy (anyone can get a certificate, including phishing sites; the padlock never meant "safe site"), protect data once it reaches your server, or fix vulnerabilities in your application. TLS is the armored truck. It protects data in transit, nothing more. A perfectly configured certificate on top of an exposed database is a locked front door on a house with no back wall.
The certificate itself: where things actually break
The common certificate failures are embarrassingly mundane. Not exotic cryptography — paperwork.
Expired certificates. The single most common TLS finding, and it happens to everyone. Renewal automation breaks silently: a DNS record changed and the challenge can't complete, an API token got revoked, the cron job lived on a server that was decommissioned. Nobody notices until visitors see a full-page warning. The fix isn't just "renew it": it's monitoring expiry from the outside, independent of whatever tool does the renewing. If your renewal tool is the thing that's broken, asking it whether it's working is not a monitoring strategy.
Hostname mismatches. The certificate covers example.com but not www.example.com, or marketing launched shop.example.com without telling anyone who manages certificates. Visitors on the uncovered name get a frightening browser warning (NET::ERR_CERT_COMMON_NAME_INVALID), and a meaningful share of them never come back. Wildcard certificates or multi-SAN certificates solve this; the real fix is a process where new hostnames trigger a certificate check.
Broken chains. This is the sneaky one. A certificate chain has links: your certificate, one or more intermediates, and a root the client trusts. Leave out an intermediate and the chain breaks, but it works in your browser, because your browser cached that intermediate from some earlier visit. Then it fails inside your customer's API integration, their mobile app, or their ten-year-old point-of-sale terminal. The assessment catches this because it verifies the chain the way a stranger's machine would. The cautionary tale here is real: when Let's Encrypt's old root certificate, DST Root CA X3, expired on September 30, 2021, sites were fine on modern devices but older phones, old iOS versions, and systems running OpenSSL 1.0.x started throwing certificate errors: a chain-of-trust problem at internet scale, caused by a root expiry nobody's site code had anything to do with. Chains matter precisely because they fail far from your desk.
Check it yourself: the two-minute TLS audit
You don't need a scanner for the basics. Two commands tell you most of what an assessment's TLS phase reports.
First, the certificate dates and names:
$ echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \ | openssl x509 -noout -dates -subject -issuer notBefore=Aug 4 12:00:00 2026 GMT notAfter=Nov 2 12:00:00 2026 GMT subject=CN = yourdomain.com issuer=C = US, O = Let's Encrypt, CN = R3
Read that output like an assessor: is notAfter uncomfortably close? Does the subject cover the names you actually serve? Is the issuer who you expect? Second, the handshake: what your server actually negotiates:
$ curl -vI https://yourdomain.com 2>&1 | grep -E "SSL|TLS|subject|issuer|expire" * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * subject: CN=yourdomain.com * expire date: Nov 2 12:00:00 2026 GMT
If that first line says TLS 1.0 or 1.1, you have a finding. Which brings us to protocols.
Protocol versions and ciphers: the history you're inheriting
Beyond the certificate, the assessment checks how encryption is negotiated, and the answer carries twenty years of history. TLS 1.0 and 1.1 have known, named weaknesses: BEAST (CVE-2011-3389), which exploited predictable initialization vectors, and POODLE (CVE-2014-3566), the padding-oracle attack that killed SSLv3 and embarrassed TLS 1.0 alongside it. The industry response wasn't a suggestion. PCI DSS set a hard deadline (June 30, 2018), after which SSL and early TLS could no longer count as strong cryptography for card-handling systems. The IETF finished the job in March 2021 with RFC 8996, which formally deprecated TLS 1.0 and 1.1 outright.
So if your server still negotiates them in 2026, ask what you're buying with that compatibility. The clients that need TLS 1.0 are Internet Explorer on Windows XP and embedded devices with unmaintained firmware. Not your customers. Disable the old protocols, prefer strong ciphers, and let the ancient clients go. Every weak cipher you accept for compatibility is a potential downgrade path for an attacker, and the fix is a few lines in your web server or CDN config.
Then add the header that makes the configuration stick: Strict-Transport-Security. HSTS tells browsers "only ever talk to me over HTTPS, for the next N seconds", which kills protocol-downgrade attacks outright. Set it with a long max-age and includeSubDomains, and consider the HSTS preload list (hstspreload.org): once you're on it, browsers ship knowing your site is HTTPS-only before the first visit. One caution: preload is nearly irreversible and includeSubDomains covers every subdomain, so make sure nothing internal still needs plain HTTP before you commit.
Certificate types (DV, OV, EV): what actually matters
Certificates come in validation levels: Domain Validated (DV) proves control of the domain, Organization Validated (OV) adds basic identity checks, Extended Validation (EV) involves deeper vetting. Here's the honest version: for most sites, DV is fine. Browsers long ago stopped displaying the EV company name prominently, so the practical difference a visitor sees is small. What matters far more than the validation level is that the certificate is valid, covers the right hostnames, renews automatically, and is monitored externally. Don't pay for EV expecting a security upgrade; spend the difference on HSTS and expiry monitoring instead.
And you usually don't need to pay at all. Let's Encrypt issues free DV certificates with 90-day lifetimes designed for automated renewal, and most hosts and CDNs wire it up with one click. The 90-day lifetime is a feature, not a limitation. It forces automation, and automation is what prevents the expired-certificate finding.
Mixed content: the quiet padlock-killer
A page served over HTTPS that loads images, scripts, or stylesheets over HTTP has mixed content. Browsers block the insecure subresources or downgrade the security indicator, and your page breaks in ways that look like someone else's bug. After any migration to HTTPS, audit every page for hardcoded http:// references: open your browser's developer console and look for lines like:
Mixed Content: The page at 'https://yourdomain.com/' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.net/widget.js'. This request has been blocked; the content must be served over HTTPS.
Template files, CMS plugins, and third-party embeds are the usual hiding places. Fix the references to HTTPS (or protocol-relative URLs), and the warnings disappear.
What to do this week
A concrete checklist, in the order an assessor would care:
- Run the two openssl/curl commands above against your domain. Note the expiry date, the TLS version negotiated, and whether the names match.
- Confirm renewal is automated and monitored from outside: a calendar reminder 30 days before expiry is the minimum; an external monitor is better.
- Verify the certificate covers every hostname you serve: with and without www, plus the subdomains that matter.
- Disable TLS 1.0/1.1 and weak ciphers in your server or CDN config; enable HSTS with a long max-age.
- Open your browser console on your key pages and hunt mixed-content warnings.
None of this requires new software. Just configuration and monitoring. And it's exactly what a TLS assessment checks in under a minute.
Frequently asked questions
Do I need to pay for an SSL certificate?
Usually not. Let's Encrypt issues free domain-validated certificates with 90-day lifetimes and automated renewal, and most hosts and CDNs integrate it with one click. What matters more than price is coverage of all your hostnames, automated renewal, and external expiry monitoring.
Why do visitors see "your connection is not private" on my site?
The usual causes are an expired certificate, a hostname mismatch (the certificate covers example.com but not www.example.com), or a broken chain of trust from a missing intermediate certificate. Check expiry first, then hostname coverage, then test the chain with SSL Labs' server test or openssl.
Which TLS versions should my server support?
TLS 1.2 as the minimum, TLS 1.3 preferred. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in March 2021, and PCI DSS required migration off them by June 30, 2018 for card-handling systems. Supporting them today fails compliance audits without meaningfully helping real users.