What Is an SSL/HTTPS Certificate — Explained for Non-Technical Founders

Monday morning, and your online store gets the call: customers are seeing a red page telling them «their connection is not private», and they are leaving. The code is intact, the server is up, hosting is paid. The culprit is a file nobody was watching: the SSL certificate, expired overnight. It is one of the most common outages that is not a technical outage — and one of the most expensive in lost leads. Here is what a certificate actually does, how to read the browser's warnings, what expiry and renewal mean in 2026, what your money buys with a paid certificate versus Let's Encrypt, and which questions to ask whoever administers your site.

What the certificate does — three concrete functions

When a visitor opens https://yoursite.com, the browser and your server run a quick three-step exchange: the server presents its certificate, the browser checks whether it was signed by an authority it trusts (a list built into Chrome, Safari, and Firefox — not into your site), and the two sides agree on an encryption key for the session. Only then does content start flowing. The certificate has three precise jobs:

1. It encrypts the traffic. Without it, data between visitor and server travels «in the clear». The password from the login form, the email address, the card details — all readable by anyone on the path: the visitor's public WiFi, their internet provider, a misconfigured piece of network equipment. With HTTPS, an eavesdropper sees the domain and the volume of data, not the content.
2. It proves the server's identity. The certificate cryptographically binds the domain yoursite.com to the server that serves it. Without this check, an attacker can answer in your place at the DNS level and collect the passwords themselves — the so-called man-in-the-middle attack.
3. It enables the trust markers. The padlock in the address bar, the absence of warnings, the security badges payment processors require — all depend on a valid certificate. Stripe, PayPal, and every payment processor refuse to run on pages without valid HTTPS.

A terminology note, so meetings don't lose you: SSL and TLS refer to the same thing. SSL is the historic protocol (its versions were broken and retired); TLS is the current one — but the industry kept the old name out of habit. «SSL certificate» today means «TLS certificate». If a vendor tries to sell you «new SSL, not old TLS», that is a red flag, not an argument.

The analogy: a wax seal and a sealed envelope

Think of a business letter with two protections: a seal that proves it really came from you (identity, verified by the certificate authority) and an envelope that only the recipient can open (the cryptography). Whoever intercepts the envelope in transit sees the paper but cannot read the contents; and if someone tries to send forged letters in your name, the seal doesn't match and the recipient rejects them. The certificate is the seal-plus-envelope pair for every connection between a browser and your server.

What the browser tells you — and what each warning means

The essential difference many site owners miss: «Not secure» is an embarrassing label, but the page loads. The red page is a wall — the user has to manually click «Advanced → Proceed», which nobody who doesn't already know you will do. An expired certificate effectively turns the site into unavailable for new traffic.

Expiry: the shrinking calendar and what you actually lose

This is the topic that became critical in 2026. For years, certificates were issued for 1–2 years, so renewal was a rare event. The CA/Browser Forum — the body that sets the rules for all certificate authorities — voted in 2025 on an aggressive shortening schedule (ballot SC-081): from March 15, 2026 the maximum validity of a public TLS certificate is 200 days, and the final step lands at 47 days by March 2029. Translation for a site owner: certificates issued from now on expire two to three times a year, and by 2029 roughly eight times a year. Manual renewal is no longer a realistic option even for a single site.

What you concretely lose when the certificate expires:

• New traffic. The red page stops most visitors coming from search results and ads — you pay for the click, the user sees a security warning, they leave.
• The contact form. On a flagged page, form submission rates go to zero — nobody types their details into a page marked unsafe.
• Integrations. Payment processors, webhooks, and mobile apps that talk to your server refuse connections with an invalid certificate. The store can be «up» while payment is dead.
• SEO. Google confirmed back in 2014 that HTTPS is a ranking signal; an expired certificate is worse — it can drop pages from the index or mark them unsafe in results, and recovery after renewal takes weeks.

The solution is not «remembering». It is automation: Let's Encrypt renews itself every 60 days via ACME (the protocol that verifies your domain and installs the new certificate with no human intervention), and paid certificates must be tied to an automated renewal process or an alert at 30 and 7 days before expiry, with a named owner. A correctly configured server will renew your certificates for years without you knowing it exists — exactly as it should be.

Let's Encrypt vs. paid — what the money buys

The frequent question: «is the free certificate weaker?» No. Cryptographically, a Let's Encrypt certificate is identical to a $200/year one: same encryption, same padlock, same acceptance in every browser. The differences are elsewhere:

The practical recommendation we give our own clients: brochure site, blog, internal application, even a small online store — Let's Encrypt with automatic renewal, no discussion. A paid certificate is justified when a compliance requirement demands organization validation (financial institutions, public administration), when a corporate partner requires EV for integration, or when you want the financial warranty for peace of mind. What you should NEVER buy in 2026: paid DV certificates — you are paying for exactly what Let's Encrypt gives away free, with rarer renewal and a manual process on top.

Mixed content — the padlock that lies

The subtlest trap: the site has a valid certificate, the browser shows https, but the padlock carries a warning triangle — or worse, the page sends data unencrypted without announcing it. The cause: mixed content — the main page loads over HTTPS, but parts of it come over HTTP: an old image with http:// hard-coded, a tracking script, an iframe, a font. The browser may block active content (scripts) or still load passive content (images) — in the second case the visitor sees the page, but part of the traffic runs unencrypted and the padlock is compromised.

Why it happens: the site migrates from HTTP to HTTPS and only the visible addresses get fixed, not the ones buried in old content — images added in the editor three years ago, embeds, products imported with absolute URLs. The fix is mechanical: a scan (any browser console lists insecure resources under «Mixed Content»), a global http:// → https:// replacement across the database and content, plus a Content-Security-Policy: upgrade-insecure-requests header as a safety net. It is a fix of hours, not days — but it must be finished, because a padlock with a warning loses exactly the trust the certificate paid for.

What proper management costs

The real 2026 picture, with the SC-081 schedule in force — estimates consistent with our technical article series:

The first line is the most common request that reaches us: «our site has been on HTTP for years, we want the padlock». It is a one-day job that solves the problem permanently, because Let's Encrypt costs nothing and renews itself. What we do NOT recommend: annual paid certificates installed manually, with no process — you pay every year for a task ACME does free, automatically, at shorter intervals and with fewer chances of a forgotten expiry.

Four questions that reveal a well-run setup

Even if you are not technical, you can audit in two minutes whoever administers your site or server. The correct answer is in parentheses:

1. How does the certificate on our site get renewed? («Automatically, via ACME, every 60 days» or «automatically, with a 30-day alert if it fails».)
2. What happens if automatic renewal fails Saturday night? («Monitoring alerts within minutes, not at expiry» — and they can show you on the spot where the alert lands.)
3. Does the site load any resource over HTTP? («No — we scan periodically and the upgrade header is active.»)
4. How many days are left on the current certificate? (The answer must come in under a minute, from a dashboard or a command — if you hear «I need to check», nobody is watching.)

For the fourth question you can check yourself, no IT team needed: click the padlock in any browser → «Connection is secure» → «Certificate is valid». The expiry date is written right there. If fewer than 30 days remain and nobody mentions renewal, you have learned what you needed to know — a month before the red page, not after.

Keep reading

• What Is CI/CD — Explained for Non-Technical Founders
• What Is a REST API — Explained for Non-Technical Founders
• Services: Infrastructure & DevOps