TLS certificates are the most widely deployed type of digital certificate. They secure every HTTPS connection on the internet, authenticating servers, enabling encryption, and protecting data in transit between browsers and websites.
When you see a padlock in your browser's address bar, you are looking at a TLS certificate in action. Transport Layer Security (TLS) is the protocol that encrypts communication between your browser and a web server, and TLS certificates are the digital certificates that make it possible.
You may still hear people refer to "SSL certificates." Secure Sockets Layer (SSL) was the original protocol developed by Netscape in the mid-1990s. SSL 3.0, released in 1996, was the last version before the protocol was renamed and redesigned as TLS 1.0 in 1999. Today, all versions of SSL are deprecated and considered insecure. TLS 1.2 (2008) and TLS 1.3 (2018) are the versions in active use. The term "SSL certificate" persists in marketing and conversation, but the technology behind it is TLS. Throughout this guide, we use "TLS certificate" to be precise.
TLS certificates serve two critical functions: they authenticate the server (proving you are connecting to the real website and not an impersonator) and they enable encryption (ensuring data exchanged between your browser and the server cannot be read or tampered with by anyone on the network).
Every HTTPS connection begins with a TLS handshake, a rapid exchange that happens in milliseconds before any application data is transmitted. Here is a simplified view of the TLS 1.3 handshake:
The browser sends a "Client Hello" message to the server, indicating the TLS versions and cipher suites it supports, along with a randomly generated value. In TLS 1.3, the client also sends its key share in this first message, reducing the handshake to a single round trip.
The server responds with its chosen cipher suite, its own random value, its key share, and, critically, its TLS certificate. The certificate contains the server's public key and is signed by a trusted Certificate Authority.
The browser verifies the certificate: Is the CA trusted? Has the certificate expired? Has it been revoked? Does the domain name in the certificate match the URL? If any check fails, the browser shows a security warning and the connection is aborted.
Using the key shares exchanged in the hello messages, both sides derive the same session keys through a Diffie-Hellman exchange. These symmetric keys encrypt all subsequent communication. The private keys are never transmitted; only the key shares needed to derive the session keys.
The entire handshake completes in one round trip with TLS 1.3 (down from two in TLS 1.2). Once the handshake is finished, all data flows encrypted. If anyone intercepts the traffic, they see only ciphertext.
Not all TLS certificates are created equal. The Certificate Authority that issues the certificate performs a different level of verification depending on the type requested. There are three standard validation levels:
The simplest and fastest type. The CA only verifies that the requester controls the domain, typically through a DNS record, an HTTP challenge, or an email to a predefined address. DV certificates can be issued in minutes and are often free (e.g., Let's Encrypt). They provide encryption but do not verify the organization behind the domain. DV is appropriate for blogs, personal sites, and internal services where organizational identity is not a concern.
In addition to domain control, the CA verifies the legal existence and identity of the organization requesting the certificate. This involves checking business registration documents, verifying the organization's physical address, and confirming the requester's authority to act on behalf of the organization. OV certificates take one to three days to issue and include the organization's name in the certificate details. They are appropriate for business websites and e-commerce platforms where customers may want to verify who operates the site.
The most rigorous level. EV certificates require extensive verification of the organization's legal, physical, and operational existence, including confirmation of the specific individuals authorizing the request. The process can take up to a week. EV certificates used to trigger a green address bar in browsers, but most browsers have removed this visual indicator. Despite this, EV certificates remain relevant for financial institutions, government portals, and organizations where the highest level of verified identity is required by policy or regulation.
All three validation levels provide the same level of encryption. The difference lies in how much identity verification the CA performs. Choosing the right level depends on your use case, regulatory requirements, and how important organizational identity is to your users.
Organizations often need a single certificate to cover multiple domains or subdomains. Two mechanisms address this need:
A wildcard certificate secures a domain and all its subdomains at one level. For example, a certificate for *.example.com covers www.example.com, api.example.com, and mail.example.com. It does not cover multi-level subdomains like staging.api.example.com. Wildcards simplify management but require careful handling: if the private key is compromised, all subdomains are affected.
Subject Alternative Name (SAN) certificates can include multiple distinct domain names in a single certificate. For example, one certificate could cover example.com, example.org, and shop.example.net. SAN certificates are common in cloud environments and CDN deployments where a single server hosts many different domains.
Use wildcard certificates when you have many subdomains under a single domain and want simplified management. Use SAN certificates when you need to secure unrelated domains or a mix of domains and subdomains. Some certificates combine both, using wildcard entries within a SAN list.
Both wildcard and SAN certificates increase the blast radius of a private key compromise. If the key is leaked, every domain on the certificate is at risk. Organizations should weigh convenience against risk, use strong key protection, and consider shorter-lived certificates to limit exposure.
A TLS certificate is not a static object. It goes through a well-defined lifecycle, and each stage requires attention to avoid security gaps or outages.
A key pair is generated, a Certificate Signing Request (CSR) is created, and the CA validates the requester's identity. Once validated, the CA issues and signs the certificate. For DV certificates with ACME automation, this entire process can happen in seconds without human intervention.
The certificate is installed on the web server, load balancer, CDN, or reverse proxy. Configuration errors at this stage, such as missing intermediate certificates, incorrect key file paths, or misconfigured cipher suites, are a leading cause of TLS failures.
Throughout its validity period, the certificate needs to be monitored for upcoming expiration, revocation, and compliance with organizational policies. Renewal should begin well before the expiration date. With automation protocols like ACME, renewal can be fully automated.
The maximum validity period for TLS certificates has been steadily shrinking, and this trend is accelerating. Understanding why, and what it means for operations, is essential for any organization managing TLS certificates.
In 2012, certificates could be valid for up to 5 years. By 2018, the maximum dropped to 2 years. In 2020, Apple unilaterally reduced the maximum to 398 days for certificates trusted by Safari, and the CA/Browser Forum followed suit. In 2025, the Forum voted to reduce lifespans further: 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029. Domain validation reuse periods will shrink alongside, reaching just 10 days by 2029.
Shorter lifespans reduce the window of exposure if a key is compromised, since an attacker holding a stolen private key can only use it until the certificate expires. They also force more frequent domain validation, ensuring that certificate holders still actually control the domains on their certificates. Additionally, shorter lifespans reduce reliance on revocation mechanisms (CRL/OCSP), which have known reliability issues.
At 47-day lifespans, a single certificate requires roughly eight renewals per year. For an organization managing thousands of certificates, that means tens of thousands of renewal operations annually. Manual processes (spreadsheets, calendar reminders, ticket-based requests) simply cannot keep up. Automation is no longer optional; it is a prerequisite for operating TLS at scale.
Organizations that have not yet adopted automated certificate management should begin planning now. The transition timelines are already set, and the operational impact grows with every reduction in validity period.
Automate renewals at scale: Evertrust CLM automates the full TLS certificate lifecycle, from request through issuance to deployment and renewal, using ACME and native integrations with web servers, load balancers, and cloud platforms. When lifespans drop to 47 days, your renewals happen automatically.
Discover every TLS certificate: Network scanning, CT log monitoring, and endpoint discovery build a complete inventory of all TLS certificates across your infrastructure, including those procured outside of IT. No more surprise expirations.
Prevent outages: Real-time monitoring with configurable alerts ensures no certificate expires unnoticed. Dashboards show expiration timelines, compliance status, and certificates at risk, giving your team full visibility and time to act.
Work with any CA: Evertrust is CA-agnostic. Whether your TLS certificates come from Let's Encrypt, DigiCert, Sectigo, or your own private CA, CLM manages them all from a single platform.
