What Is an SSL/TLS Certificate? What Does It Protect?
An SSL/TLS certificate does two things: it proves the identity of a server, and it enables encrypted communication between that server and everyone connecting to it. You see the result as https:// in your address bar. Here's what's inside the certificate, how it works, and why managing its lifecycle matters.
Key takeaways
- SSL is the older protocol — it was replaced by TLS, but "SSL" remains the common shorthand for both.
- A certificate contains a public key, domain identity, validity dates, and a CA's digital signature — not your data.
- Certificates expire by design. The CA/B Forum is reducing maximum lifetimes to 47 days by 2029.
- Chain validation, revocation, and TLS version support are silent failure modes that expiry monitoring alone won't catch.
In this article
SSL vs TLS — what's the difference?
SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the mid-1990s. SSL 2.0 and SSL 3.0 both had critical vulnerabilities and are now completely deprecated — browser support was removed years ago.
TLS (Transport Layer Security) is the modern successor. TLS 1.2 (2008) is the current minimum standard; TLS 1.3 (2018) is the preferred version, with a simplified handshake and stronger defaults. TLS 1.0 and 1.1 are deprecated and should be disabled on all servers.
The certificates used with both protocols are technically the same — which is why "SSL certificate" remains the industry shorthand, even though the server is negotiating TLS. When someone talks about their "SSL cert," they mean an X.509 certificate used in a TLS handshake.
What a certificate contains
A certificate is a structured data file — an X.509 standard document — containing several fields that browsers and clients use to validate the server's identity:
Subject
The domain name(s) the certificate is valid for. Modern certificates use Subject Alternative Names (SANs) to list multiple hostnames — e.g. aideworks.com and www.aideworks.com.
Public key
Used during the TLS handshake to establish a symmetric session key. The corresponding private key is kept secret on the server — it should never be transmitted.
Validity period
notBefore and notAfter timestamps defining the window during which the certificate is valid. Outside this window, the certificate is rejected.
Issuer
The Certificate Authority that verified the domain and signed the certificate. Browsers trust certificates whose signing chain leads to a root CA in their trust store.
Certificate chain
Intermediate certificates linking the end-entity cert to a trusted root CA. Missing intermediates cause chain validation failures — invisible in some browsers, hard failures in others.
Serial number
A unique identifier for this certificate, used in revocation records (CRLs and OCSP).
Signature
A cryptographic signature from the issuing CA, proving the certificate contents haven't been tampered with.
Extensions
Additional fields including Key Usage, Basic Constraints, OCSP responder URL (AIA extension), and optionally Must-Staple.
How the TLS handshake works
Every HTTPS connection begins with a TLS handshake — a negotiation that establishes which encryption algorithms to use, authenticates the server, and generates the session key. In TLS 1.3 the whole handshake completes in one round trip.
Client Hello
The browser sends its TLS version, supported cipher suites (algorithms for encryption and authentication), and a random number.
Server Hello
The server selects a cipher suite and TLS version, sends its certificate, and a server random number.
Certificate verification
The browser validates the certificate chain against its list of trusted root CAs, checks that the certificate hasn't expired, and verifies it hasn't been revoked (via OCSP).
Key exchange
Using the server's public key (or ECDHE for forward secrecy), both sides agree on a symmetric session key without ever transmitting it directly.
Finished
Both sides confirm the handshake is complete. All subsequent communication is symmetrically encrypted using the agreed session key.
The result: all HTTP traffic between the browser and server is encrypted with a unique symmetric key that exists only for that session. Even if the traffic is intercepted, it cannot be decrypted without the session key — which is never transmitted.
Certificate types: DV, OV, EV, Wildcard
Certificate types differ in how much the CA verifies about the certificate applicant — not in the strength of the encryption they enable:
CA checks only that the applicant controls the domain — via a DNS record, email, or HTTP challenge. Fully automated, issued in minutes. Your certificate is almost certainly DV.
CA also verifies the organisation's legal existence. Requires paperwork and manual review. Shows the organisation name in certificate details when clicked.
Strictest vetting. Historically triggered a green address bar in browsers; modern browsers no longer display this distinction, making EV largely legacy.
A single certificate covering a domain and all its direct subdomains: *.example.com. Convenient but cannot cover sub-subdomains without an additional wildcard.
Expiry, rotation, and the 47-day change
All certificates have a fixed validity window. When a certificate passes its notAfter date, browsers reject it immediately — hard failure, no user override on most platforms.
Maximum certificate lifetimes have been shrinking for years. The CA/B Forum voted in 2025 to reduce them from 398 days to 47 days maximum by March 2029. The reduction is staged:
- March 2026: 200 days
- September 2026: 100 days
- March 2029: 47 days
For agencies managing SSL across dozens or hundreds of client domains, this dramatically increases certificate rotation frequency. Manual renewals at this cadence are not sustainable — which is why automation (ACME protocol, Let's Encrypt, Certbot) and active monitoring become essential operational infrastructure rather than optional tooling.
Even with auto-renewal in place, certificates fail to renew silently: ACME challenges fail, DNS propagation lags, web server reload hooks break, CDN configurations point to expired caches. Monitoring remains the safety net beneath automation.
Silent failure modes
Certificate expiry is the most visible failure — browsers show a hard error blocking access. But several other failure modes are equally severe and far less visible:
- Incomplete certificate chain — if intermediate certificates are missing from the server configuration, newer browsers accept the connection (retrieving the intermediate via AIA), but older browsers and API clients fail silently or with a cryptic error.
- Certificate revocation — a compromised or misissumed certificate should be revoked, but without OCSP stapling, some browsers silently allow revoked certificates to be used (soft-fail OCSP). Read more in What is OCSP Stapling?
- TLS version mismatches — a server still supporting TLS 1.0 or 1.1 will fail compliance scans, trigger browser warnings on some clients, and expose connections to known downgrade attacks.
- Weak cipher suites — legacy ciphers (RC4, 3DES, NULL suites, anonymous DH) are detectable by security scanners and indicate misconfiguration. Read more in TLS Version & Cipher Suite Hardening.
- Host/certificate mismatch — if a certificate's Subject and SANs don't match the hostname being requested, the connection is rejected. Common after domain migrations or misconfigured CDN configurations.
What Aideworks monitors
Aideworks monitors the complete SSL health of every certificate it finds on your monitored domains — not just the expiry date:
- Expiry with configurable advance warning — start alerting at 60, 30, 14, and 7 days before expiry, configurable per domain or globally.
- Certificate chain validation — checks that the full chain from end-entity to trusted root is present and valid.
- OCSP revocation status — queries the CA's OCSP responder to check whether the certificate has been revoked.
- OCSP stapling — verifies that the server is providing a valid stapled OCSP response in the handshake.
- TLS version support — detects TLS 1.0/1.1 still being offered and whether TLS 1.3 is available.
- Cipher suite quality — flags weak or deprecated cipher suites in use during negotiation.
- Subject/hostname match — confirms the certificate is valid for the exact domain being monitored.
Checks run on standard HTTPS (port 443) as well as mail ports (465 SMTPS, 993 IMAPS) — so client email infrastructure is monitored alongside websites.
Monitor every SSL certificate with Aideworks
Add a domain and Aideworks immediately checks its certificate health — expiry, chain, TLS version, cipher suites, and revocation status — and alerts you before anything breaks.
Start monitoring free →