What is an SSL Certificate?

Every time you enter a password, submit a form, or check out with a credit card, you are trusting that the connection between your browser and the website is private. An SSL certificate is what makes that trust possible. It is one of the most widely deployed security technologies on the internet, yet it is often misunderstood, in part because the industry still calls it “SSL” even though the underlying protocol changed years ago.

What is an SSL certificate?

An SSL certificate is a digital credential that binds a website’s identity to a public key. The encryption itself is performed by the TLS protocol, which uses that public key during the handshake to authenticate the server and establish session keys. The certificate’s job is narrower but just as important: it gives the client a reason to believe the key belongs to the site it thinks it is visiting, and not to an attacker in the middle. It enables trust.

The term “SSL” is a bit of a historical artifact. As mentioned before, the associated protocol is TLS. SSL stands for Secure Sockets Layer, the original cryptographic protocol for authenticating and encrypting communications over a network. That protocol was replaced some time ago by the more advanced and secure successor TLS (Transport Layer Security). Even so, “SSL certificate” remains the industry shorthand, and most people still say SSL when they technically mean TLS. Throughout this guide, “SSL certificate” or “SSL/TLS“ refers to the certificates that secure today’s TLS connections.

For organizations, an SSL/TLS certificate is far more than an encryption tool. It enforces data integrity, enables authentication, and secures web transactions, making it a foundational layer of digital trust. It is what allows users, partners, and systems to interact safely across the internet.

It is also worth clarifying a common point of confusion: every SSL/TLS certificate follows the X.509 certificate standard, the format that defines how the certificate’s fields and identity information are structured. X.509 is the broader specification, and SSL/TLS is just one of many places it appears. In other words, all SSL certificates are X.509 certificates, but X.509 certificates also show up in email signing, code signing, VPNs, device identity, etc.

A brief history of SSL and TLS

SSL was developed by Netscape in the 1990s to encrypt and secure communications over the internet. SSL v1.0 was never released because of security flaws, SSL v2.0 followed in 1995 with significant weaknesses, and SSL v3.0 in 1996 delivered the major improvements that shaped secure communication on the web. By 2015, SSL v3.0 and earlier versions had been deprecated, and by 2020 SSL was retired entirely.

While Netscape refined SSL, the Internet Engineering Task Force developed TLS as its successor. TLS is essentially a newer, more secure version of SSL: TLS 1.0 arrived in 1999 (based on SSL v3.0), followed by TLS 1.1 in 2006 and the long-serving TLS 1.2 in 2008. The name “SSL” simply stuck in everyday usage, which is why people still say “SSL certificate” when the connection actually runs on TLS.

The current standard is TLS 1.3, finalized in 2018 and now securing most modern connections. It is now faster and more secure than ever before. For a fuller side-by-side of the two protocols, see our companion coverage of SSL and TLS.

How SSL/TLS certificates work

An SSL/TLS certificate secures communication by combining two types of cryptography and two distinct protocols. Understanding both is the key to understanding why the technology is so effective.

At the highest level, TLS creates a secure transport-layer connection between two endpoints: a server and a client. That connection is usually between a website server and a browser, or between a mail server and an email application such as Outlook. To make it work, TLS relies on two separate protocols:

• The handshake protocol authenticates the server (and optionally the client), negotiates which cryptographic methods to use, and generates a shared key.
• The record protocol isolates each connection and uses that shared key to secure communication for the remainder of the session.

The handshake: where trust is established

The TLS handshake is an asymmetric cryptographic process that establishes a secure channel between the server and client. Every HTTPS connection begins with it. During the handshake, the server holds a private key while the client receives the corresponding public key within the SSL/TLS certificate, which it then uses to authenticate the server and confirm its identity. Besides the client being able to authenticate the server, they also establish session keys during the handshake, which they use to encrypt the communication thereafter.

A successful handshake happens instantly and automatically behind the scenes, without disturbing the user experience. A failed handshake, on the other hand, terminates the connection and usually surfaces a warning in the browser.

When the handshake succeeds, it delivers three security benefits:

• Authentication: the server’s identity is verified for as long as the connection is valid.
• Confidentiality: data is encrypted and visible only to the server and client.
• Integrity: digital signatures confirm that the data was not altered in transit.

Once the handshake establishes a shared session key, asymmetric cryptography has done its job. It is then when the record protocol takes over, using faster symmetric encryption to protect the flow of data for the rest of the session.

The certificate itself carries the identifying details a browser needs to confirm who you are, along with the public key, an expiration date and other important information. If you want to inspect these components in practice, our guide on how to check an SSL certificate walks through what each part means and how to view it in your browser.

Public key infrastructure and SSL

SSL/TLS certificates do not operate in isolation. They live inside a larger framework called public key infrastructure (PKI), which manages security through encryption and governs digital certificates throughout their lives. When you receive an SSL/TLS certificate from a Certificate Authority (CA), you install it on your server, typically alongside an intermediate certificate that links your certificate back to the authority’s trusted root. All of these are elements and procedures of the PKI.

The clearest way to picture PKI is as a digital Department of Motor Vehicles. A DMV verifies who you are before issuing a license, and the license it hands back is more than a statement of your name. It carries your photo, which is what makes it useful: anyone can check that the person presenting the license is the person it was issued to.

An SSL/TLS certificate works similarly. A certificate authority verifies a website’s identity and issues a certificate that carries the site’s public key, the certificate’s equivalent of the photo. Anyone can check that the server presenting the certificate actually holds the matching private key. And like a license, a certificate names its holder, carries an expiration date, and can be revoked before that date if something goes wrong.

The chain of trust

For an SSL/TLS certificate to be trusted, it must trace back to a trusted root CA. This linkage is called the chain of trust. At the core of every PKI sits the root CA, the trusted source of integrity for the entire system. When a root CA signs a certificate, it starts the chain. If that root CA is publicly trusted, then any valid certificate chained to it is automatically trusted by major browsers and operating systems.

Browsers verify this chain automatically. Your browser already knows the public keys of a handful of trusted CAs. When it receives a website’s certificate, it uses those keys to check the certificate’s signature, then repeats the process for each certificate in the chain until it reaches a root CA it recognizes. This is exactly what happens behind the padlock icon in your address bar: a quick, recursive verification that the certificate you are relying on comes from a trustworthy source. For a deeper look at how trust chains and certificate authorities work at the specification level, see our X.509 guide.

Types of SSL certificates

One of the most misunderstood aspects of SSL/TLS certificates is that there are different types at all. It is worth being clear about what separates them. The type of a certificate is a procedural distinction, not a cryptographic one. Every SSL/TLS certificate, whatever its type, uses the same encryption, the same chain of trust, and the same handshake. What changes from one type to the next is the evidence the certificate authority collected before signing.

There are three types, each defined by a different claim and a different check:

• Domain Validated (DV): the CA confirms that the applicant controls the domain, often through a simple DNS record check. This is the fastest and most basic type, frequently issued within minutes, and it carries no organization details. DV certificates suit personal or internal sites more than public-facing business websites. Learn more about domain validation in our dedicated page.
• Organization Validated (OV): the CA confirms domain control plus the legal existence of the organization, checking its identity against government records and requiring additional documentation. Organization details appear in the certificate, giving visitors more assurance. OV is a good fit for commercial sites that collect user data. See our page on organization validation if you’re curious about it.
• Extended Validation (EV): the most rigorous type. The CA conducts an in-depth review of the organization’s legal, physical, and operational existence, confirms the requester’s authorization, and applies two-person issuance controls. The request must be initiated by the organization itself. EV certificates are governed by the CA/Browser Forum’s EV Guidelines, and browsers may display enhanced indicators signaling the elevated trust level. To learn more, see our deep dive on extended validation.

The type of a certificate is also visible inside the certificate itself. OV and EV details populate the subject fields, EV adds attributes such as the organization’s business category, jurisdiction of incorporation, and registration number, and a policy identifier marks which type the certificate is. Relying parties recognize EV by mapping that identifier back to a trusted root.

Choosing the right type comes down to your site’s purpose, risk profile, and how much identity assurance your users need. We will publish a dedicated deep dive on choosing and validating certificates soon; for most organizations, the practical rule is that a more rigorous type signals greater credibility, which matters most when handling sensitive data or financial transactions. Learn more about certificate validation in our dedicated blog.

Benefits of SSL/TLS certificates

Deploying an SSL/TLS certificate delivers benefits that reach well beyond the padlock icon. The four most significant are data protection, identity verification, improved search visibility, and regulatory compliance.

Encrypting sensitive data

The core benefit of an SSL/TLS certificate is that it encrypts sensitive data in transit, which is what stops man-in-the-middle (MitM) attacks. In a MitM attack, a bad actor intercepts information meant for a legitimate destination, sometimes by standing up a fake site that dupes visitors into handing over credentials or payment details. Consider an online banking login: if someone intercepts that unencrypted traffic, your credentials could be exposed, opening the door to identity theft or financial loss. TLS prevents this by encrypting the data so that intercepted traffic reads as unintelligible gibberish, and by verifying the identity of the domain owner so visitors reach the real site.

Verifying website ownership

An SSL/TLS certificate validates that a site is owned by who it claims to be. Because a certificate authority issues the certificate only after verifying the applicant’s identity and domain ownership, a signed certificate effectively vouches for the organization. Since browsers trust the CA, they extend that trust to the verified organization, giving visitors confidence that they are dealing with a legitimate business.

Supporting regulatory compliance

Most regulations that govern sensitive data do not mention TLS by name. They require that data in transit be protected with strong cryptography, and TLS is the mechanism the industry settled on for meeting that requirement. PCI DSS is the most explicit, calling for strong cryptography during transmission across open public networks and deprecating early TLS versions outright. HIPAA treats transmission security as an addressable specification, which permits alternatives in principle but leaves you documenting why encryption was not appropriate. GDPR names encryption as an example of an appropriate technical measure rather than mandating it, though its breach notification rules give it real teeth: data rendered unintelligible to an unauthorized party changes what you are obliged to disclose. These are just a few examples from a very large list of laws and security frameworks.

The cost of not having one

HTTPS stopped being a differentiator some years ago and became the baseline. Google added HTTPS as a lightweight ranking signal in 2014, but with near-universal adoption today it separates almost nothing. The consequence now runs the other way. Browsers label plain HTTP sites as “Not secure,” and a growing list of web platform features are restricted to secure origins. A certificate no longer earns you credit; its absence costs you.

Common use cases for SSL/TLS certificates

Although SSL/TLS certificates are most visible on websites, their applications extend across both internet-facing and internal enterprise environments. The same underlying protocol secures a surprisingly wide range of connections.

Securing websites and web applications

This is the use case most people picture. When a signed SSL/TLS certificate secures a website, it proves the organization has authenticated its identity with a trusted third party, and the browser extends its trust to that organization. Technically, unsecured web traffic runs over HTTP on port 80, a plain-text protocol that is relatively easy for an attacker to intercept and read. TLS uses port 443 instead, encrypting the exchange between browser and server and authenticating the connection. When security is needed, the browser automatically switches to the secure connection, provided the server has a valid certificate installed. Because of the spread of phishing, browsers such as Chrome now redirect to HTTPS by default.

Enterprise and intranet applications

Enterprises use SSL/TLS certificates well beyond their public websites. Common internal use cases include network access controls, virtual private network (VPN) authentication, and single sign-on (SSO) implementations. In each case, a digital identity replaces the friction of long, frequently rotated passwords. Placing a digital identity on a desktop, server, or wireless access point ensures that only authorized devices can connect to corporate resources, and SSO products lean on the same trust model to grant access across a portal or cloud services.

Internet of Things (IoT) device security

SSL/TLS certificates also authenticate machines. A digital identity installed on an IoT device ensures that only trusted devices can connect to a network, and it authenticates the data those devices exchange with authorized applications. As connected device fleets grow, this certificate-based identity becomes essential to keeping untrusted hardware out.

Email and communication security

The same PKI foundation that supports TLS also underpins secure email and communications. It is worth noting that email signing certificates are distinct from SSL/TLS certificates because they use different key-usage functions, but they draw on the same infrastructure. This is another reminder that X.509 certificates and their common use cases reach far beyond the web browser.

Managing SSL/TLS certificates at scale

Basic definitions of SSL/TLS certificates rarely mention the hardest part: managing them. Most organizations rely on dozens or even hundreds of certificates spread across environments, and keeping them all valid is a genuine operational challenge. Three problems come up again and again, and manual tracking through spreadsheets and calendar reminders tends to break down as volumes grow.

The certificate expiration problem

SSL/TLS certificates do not last forever, and they are expiring faster than ever. Miss a single renewal and the consequences are immediate: websites and applications can go down, users lose trust, and your security posture takes a hit. A certificate management solution tracks expiration dates across every certificate so teams get plenty of notice rather than scrambling at the last minute. As lifespans shorten, this early-warning capability shifts from a convenience to a necessity.

Visibility and sprawl across environments

As certificate inventories grow, visibility erodes. Teams often cannot say how many certificates they manage, which ones are close to expiring, or where each one is deployed. Sprawl compounds the problem: organizations sometimes stack multiple certificates on a single domain simply to avoid leaving it unprotected during a renewal scramble, which adds yet another item to maintain. Without a clear inventory, a single overlooked certificate can trigger an outage.

Why automation is now essential

Certificate management solutions solve these problems by automating discovery, tracking expirations, and simplifying maintenance. Automated discovery builds an accurate, continuously updated record of every certificate in the enterprise, so certificates are provisioned and renewed at the right time without manual effort. The result is fewer manual errors, less labor overhead, and far lower odds of a costly, avoidable outage. This is the practical, day-to-day side of certificate lifecycle management, and it is where most organizations feel the pressure first.

The shift to shorter SSL/TLS certificate lifespans

The single biggest change on the horizon for SSL certificates is a dramatic reduction in how long they remain valid. In April 2025, the CA/Browser Forum, the body that sets global standards for digital certificates, approved Ballot SC-081v3, which shortens the maximum lifespan of publicly trusted SSL/TLS certificates on a fixed schedule.

Under that schedule, the maximum validity period steps down from today’s baseline toward a fraction of its former length:

• 200-day maximum by March 15, 2026
• 100-day maximum by March 15, 2027
• 47-day maximum by March 15, 2029

The operational implications are substantial. At a 47-day maximum, organizations will need to renew each certificate roughly eight times more often than under the previous 398-day maximum. This is, in effect, the end of “set it and forget it” certificate management. A task that used to be an annual chore becomes a near-continuous operational process.

For IT and security teams, the practical response is to prepare now rather than react later. That means building a complete inventory of existing certificates, identifying where manual renewals still happen, and adopting automation before the shorter windows arrive. Protocols such as ACME (Automated Certificate Management Environment) can handle issuance, renewal, and revocation automatically, and they are now widely supported across certificate authorities. Teams that treat certificate lifecycle management in practice as a core, ongoing discipline, rather than a once-a-year event, will absorb the change far more smoothly than those relying on manual tracking.

How Keyfactor can help

The challenges covered throughout this guide, from expiration and sprawl to the accelerating pace of renewals, all point to the same conclusion: certificates must be managed with speed, flexibility, and cryptographic agility in mind. Keyfactor helps organizations do exactly that across three complementary areas.

• Modern PKI infrastructure. 
  For organizations that want to issue certificates at enterprise scale, Keyfactor’s EJBCA is an open-source, enterprise-grade PKI platform that establishes trust and issues identities across large, complex environments.
• Certificate lifecycle automation. 
  Keyfactor Command provides end-to-end visibility, automated discovery, and automated renewal, so teams always know how many certificates they have, where they are deployed, and when they expire. This directly addresses the expiration, sprawl, and visibility problems that make manual management a liability.
• PKI as a Service. 
  For teams that need robust certificate infrastructure without the operational overhead of running it themselves, PKI as a Service delivers managed PKI and certificate automation together.

Taken together, these capabilities reflect Keyfactor’s approach to managing digital trust at scale: helping organizations stay ahead of the 47-day lifespan shift, prevent outages, and keep every certificate accounted for as their environments grow.