SSL/TLS certificates explained

When a browser opens an https:// address, the server must first present a TLS certificate (SSL is the older protocol's name; the term stuck). A certificate is a signed statement binding a domain name to a public key, and it does two jobs at once: it proves you're talking to the genuine server for that name — not something impersonating it — and it provides the key material that encrypts the connection. No valid certificate, no trusted HTTPS.

The chain of trust

Nobody can verify millions of sites' certificates individually, so trust is delegated. Your certificate (the leaf) is signed by a certificate authority (CA) — usually through an intermediate certificate, which is itself signed by a root certificate that ships preinstalled in operating systems and browsers. A client verifies by walking the chain: leaf → intermediate → trusted root. If every signature checks out and the name matches, the certificate is accepted.

One practical trap: the server must present the intermediates along with its own certificate. A server with an incomplete chain may look fine in browsers (which cache intermediates and can fetch missing ones) while strict clients — mobile apps, API libraries, older systems — reject it. "Works in Chrome, fails in the app" is the classic symptom.

Validity windows and renewal

Every certificate carries a validity window — valid-from and valid-until dates — and outside it the certificate is simply invalid, regardless of anything else. Browser policy caps public certificates at roughly 13 months, and the industry has moved hard toward much shorter lifetimes: 90-day certificates issued and renewed automatically via the ACME protocol (Let's Encrypt and similar) are now the default for much of the web, typically renewing about 30 days before expiry.

Short lifetimes are a feature: a leaked key is exposed for weeks instead of years, and renewal becomes routine machinery instead of an annual ritual someone has to remember. The flip side is that the machinery can fail silently — and when it does, expiry arrives in weeks, not years. That failure mode is covered in certificate expiry risks.

What browsers do when it breaks

An expired certificate, a name mismatch, or an untrusted or incomplete chain all end the same way: the browser interrupts the visit with a full-page warning — "Your connection is not private" — and shows none of the site's content. Proceeding is buried behind an "Advanced" click, and on sites using HSTS the browser refuses to offer the option at all. For practical purposes, a broken certificate takes the site down. Non-browser clients are stricter still: API integrations and mobile apps just fail the TLS handshake with an error — no warning page, no override.

Certificates in UpAll

For every HTTP monitor with an https:// target, UpAll reads the served certificate about once an hour. A certificate entering its final 30 days opens an Info incident; an expired or unreadable one opens a Degraded incident — both resolve automatically once a valid certificate is served. Expiry dates appear on the monitor page and on the status wall's attention strip. Details: SSL certificate monitoring and certificate incidents.