What is a TLS certificate?

A TLS certificate is a digital document that authenticates a website's identity and enables encrypted communication between a browser and a web server. Issued by a Certificate Authority (CA), it binds a domain name to a cryptographic key pair, ensuring visitors are connecting to the legitimate server.

What is certificate transparency?

Certificate transparency (CT) is a public logging framework that requires Certificate Authorities to record every certificate they issue in append-only logs. Security teams can monitor these logs to detect certificates issued for their domains without authorisation -- a signal of potential CA compromise or domain hijacking.

How often should I renew TLS certificates?

Most certificates are valid for one year (398 days maximum since 2020). Let's Encrypt certificates are valid for 90 days. Automated renewal through ACME protocols is strongly recommended to prevent expiry-related outages, which are one of the most common preventable incidents.

TLS Certificate Security: Expiry and Misconfiguration

Q: What happens when a TLS certificate expires?

When a TLS certificate expires, browsers display prominent security warnings that block most visitors from accessing the site. Search engines may also deprioritise or deindex pages served with expired certificates. The encryption still works, but the trust chain is broken.

Q: What are the most common TLS misconfigurations?

The most common TLS misconfigurations are expired certificates, self-signed certificates on public services, weak cipher suites (RC4, 3DES, CBC-mode ciphers), support for deprecated protocols (TLS 1.0, TLS 1.1, SSLv3), incomplete certificate chains, and mismatched domain names in the certificate.

Q: What is the difference between TLS, SSL, and HTTPS?

SSL (Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). SSL is deprecated and should not be used. TLS is the current encryption protocol. HTTPS is HTTP served over a TLS-encrypted connection. When people say 'SSL certificate', they almost always mean a TLS certificate.

What is TLS and why do certificates matter?

Every HTTPS connection begins with a TLS handshake. The server presents its certificate, the browser verifies it against a list of trusted Certificate Authorities (CAs), and both parties negotiate encryption parameters. If any step fails — the certificate is expired, the CA is not trusted, or the domain name does not match — the browser displays a security warning.

TLS certificates serve two functions simultaneously:

Authentication — the certificate proves the server is who it claims to be, preventing man-in-the-middle attacks where an attacker impersonates a legitimate site
Encryption — the certificate provides the public key used to establish an encrypted channel, protecting data in transit from eavesdropping

The certificate ecosystem depends on trust. Browsers trust a set of root Certificate Authorities. Those CAs issue certificates to domain owners after verifying domain control. If a CA issues a certificate incorrectly, or if a certificate expires, the trust chain breaks.

What happens when a TLS certificate expires?

Certificate expiry is one of the most common preventable incidents in web operations. According to a Keyfactor 2024 survey, 77% of organisations experienced at least one certificate-related outage in the preceding 24 months. The impact extends beyond a browser warning:

Visitor loss. Most users will not click past a browser security warning. Conversion rates drop to near zero on pages served with expired certificates.
SEO impact. Search engines may deprioritise or temporarily deindex pages that return certificate errors. Recovery after renewal is not always immediate.
API failures. Machine-to-machine communication using TLS — APIs, webhooks, integrations — fails hard when certificates expire. Unlike browsers, most API clients do not offer a “proceed anyway” option.
Trust erosion. Visitors who encounter a certificate warning associate the brand with poor security practices, regardless of the actual cause.

The root cause is almost always the same: certificates expire because no one is monitoring their expiry dates. Organisations with certificates spread across multiple providers, CDNs, load balancers, and cloud services are especially vulnerable because no single system tracks all certificates.

What are the most common TLS misconfigurations?

Each misconfiguration creates a different class of risk:

Deprecated protocol versions. TLS 1.0 and 1.1 have known vulnerabilities (BEAST, POODLE, Lucky13) and are deprecated by RFC 8996. Browsers have removed support. Servers that still offer these protocols are either serving legacy clients or misconfigured.

Weak cipher suites. Cipher suites determine the encryption algorithm, key exchange method, and hash function used for each connection. Weak ciphers include RC4 (biased keystream), 3DES (64-bit block size, vulnerable to Sweet32), and CBC-mode ciphers without AEAD (vulnerable to padding oracle attacks). Modern configurations should use only AEAD ciphers: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305.

Incomplete certificate chains. A TLS certificate is part of a chain: server certificate, intermediate certificate(s), and root certificate. If the server does not send the intermediate certificates, some clients cannot verify the chain and reject the connection. This manifests as intermittent failures — working in Chrome but failing in mobile apps or older browsers.

Self-signed certificates. Certificates not issued by a trusted CA trigger browser warnings on public-facing services. Self-signed certificates are acceptable for internal tools behind a VPN but never appropriate for public endpoints.

Domain name mismatch. A certificate for www.example.com does not cover example.com or app.example.com unless it includes those names as Subject Alternative Names (SANs). Visitors to an uncovered subdomain see a warning even if a valid certificate exists for other subdomains.

How SurfaceLoop handles this

SurfaceLoop monitors TLS certificates across all your domains and subdomains. It checks certificate validity, expiry dates, cipher suite strength, protocol versions, chain completeness, and domain coverage. Upcoming expiries trigger alerts before they become outages, and misconfigurations are flagged with specific remediation guidance.

See TLS & Certificates feature →

How does certificate transparency help security teams?

Certificate transparency was developed by Google to address a fundamental weakness in the CA system: domain owners had no way to know when a certificate was issued for their domain. Before CT, a compromised or negligent CA could issue a certificate for yourbank.com and the bank would never know until the certificate was used in an attack.

CT logs are public and searchable. Security teams can:

Detect rogue certificates. If a certificate appears in CT logs for a domain you control but you did not request it, investigate immediately — it may indicate a compromise of your DNS, domain registrar, or email validation process.
Discover subdomains. Every certificate lists the domain names it covers. Querying CT logs (via crt.sh, Certstream, or CT log APIs) reveals subdomains that have had certificates issued, including internal services, staging environments, and forgotten assets.
Audit CA behaviour. CT logs provide a complete audit trail of which CAs issued certificates for your domains, when, and with what parameters.

CT monitoring is a defensive necessity. According to the SANS 2024 Cloud Security Survey, organisations that actively monitored certificate transparency logs detected credential-based attacks 40% faster than those that did not, because CT anomalies served as early warning indicators.

How do you monitor TLS certificates across your organisation?

Certificate monitoring should cover three dimensions:

Expiry tracking. Know when every certificate expires and alert at 30, 14, and 7 days before expiry. Automated renewal via ACME (the protocol used by Let’s Encrypt and other CAs) eliminates most expiry risk, but certificates on legacy systems, appliances, and third-party platforms often cannot use ACME.

Configuration scanning. Regularly test TLS configuration using external scanning — not just certificate validity, but protocol versions, cipher suites, chain completeness, and HSTS headers. Configuration can drift after server updates, CDN changes, or load balancer migrations.

CT log monitoring. Subscribe to CT log feeds for your domains. Investigate any certificate you did not request. Tools like Facebook’s CT monitoring, CertSpotter, and EASM platforms provide automated CT surveillance.

The goal is zero-surprise certificate management: every certificate is tracked, every expiry is anticipated, and every misconfiguration is caught before it affects users or security.

What is the difference between TLS, SSL, and HTTPS?

The terminology is widely confused:

Term	What It Is	Current Status
SSL 2.0	Original encryption protocol (1995)	Deprecated, insecure
SSL 3.0	Updated SSL (1996)	Deprecated, vulnerable to POODLE
TLS 1.0	First TLS version (1999)	Deprecated by RFC 8996
TLS 1.1	Minor update (2006)	Deprecated by RFC 8996
TLS 1.2	Widely deployed (2008)	Current, supported
TLS 1.3	Latest version (2018)	Current, recommended
HTTPS	HTTP over TLS	Standard for all web traffic

When configuring a server, enable only TLS 1.2 and TLS 1.3. Disable everything older. When purchasing a certificate, you are buying a TLS certificate regardless of what the vendor calls it. When a browser shows a padlock icon, it indicates an HTTPS connection secured by TLS.