The encryption that protects data as it travels between the user and your server, shown as the padlock in the address bar.
Why it exists
Encrypting a connection with a machine you have never met raises two problems at once: agreeing on a secret key over a network anyone can listen to, and being certain the machine really is tiffinbox.com and not an impostor sitting in the middle. SSL/TLS exists to solve both, using a certificate from a trusted authority to prove identity and a handshake to establish keys, after which everything intercepted is just noise. The padlock is the visible sign it worked, and an expired certificate is a common, avoidable way to take a whole site down behind an alarming browser warning.
How it actually works
When a browser connects over HTTPS, it and the server perform a quick handshake: they verify the server really is tiffinbox.com using a certificate issued by a trusted authority, then agree on keys to scramble everything sent between them.
From then on, anyone intercepting the traffic sees only noise. The certificate also proves identity, so users are not fooled by an impostor site.
Subtopics
A senior PM walks you through it
A junior PM, stuck
The whole tiffinbox.com site is behind a scary full-page browser warning this morning, ops says the certificate expired, and in the incident channel people are asking whether we were hacked. I could not tell them what actually expired or how it slipped past everyone. I do not want to escalate this as a breach if it is something boring.
A certificate is the site's ID card, and every field on it is plain readable text, including the one that expired. This is a boring cause with a loud symptom, and you can confirm that yourself in a couple of minutes. Here is the tiffinbox.com certificate opened field by field, next to the exact line the browser is showing, so you can point at what lapsed and close the was-it-a-hack question fast.
The tiffinbox.com certificate, field by field, and what the browser now shows
Escalating a certificate expiry as a security breach. The site is down because a date passed, not because anyone got in, and mislabeling it as an attack burns the incident channel and everyone's morning on the wrong problem.
Assuming one valid certificate covers every hostname. A card is only good for the names in its SAN list, so launching store. on a certificate that lists only the root domain throws the same alarming warning.
Relying on a person to remember the renewal. Expiry is a fixed date known months in advance, so the real fix is auto-renewal with an alert on Not After, not a calendar reminder someone can miss.
Answering a partner's "is it secure" by pointing only at the padlock. The padlock means the connection is encrypted and the server's identity was checked; it says nothing about how you protect data once it is stored at rest.
Post in the channel: "Not a breach. The tiffinbox.com certificate's Not After date passed at midnight, so every browser is now blocking the site with a date-invalid warning. The servers are healthy. We renew the certificate to clear it and add auto-renewal plus a Not After alert so it cannot lapse silently again." You read a certificate's subject, issuer, SAN, and validity window, and matched the expiry to the browser's own error code. That is the skill.
Where a PM meets this
An expired certificate takes a site down with an alarming warning; it is a classic "whole site is broken" incident with a boring cause.
"Is it secure?" from a partner usually means "do you use HTTPS and encrypt data," which you should be able to answer.
Hear it in a meeting
"The cert expired at midnight, that's why everyone's seeing the security warning."