What are Digital Certificates? A Complete Guide to Types of Certificates, Formats, and Trust

Every time you load an HTTPS page, sign into a server over SSH, send an encrypted email, or bring a device onto a network, a digital certificate is working quietly in the background. These credentials are the foundation of secure communication across the internet and inside enterprise environments. They bind a verified identity to a cryptographic key so that systems can trust one another without ever having met before.

That quiet role has become a loud operational concern. Organizations now manage more machines, services, and devices than ever, and the volume of certificates in production has grown with them. At the same time, the maximum lifespan of a publicly trusted certificate is set to fall to just 47 days starting in March 2029, which compresses renewal windows and makes manual tracking unsustainable.

This guide covers what a certificate is, the major format families you will encounter, how trust is established through certificate authorities and chains, and how certificates are invalidated before they expire. By the end, you will understand not just the mechanics but why certificate management has become foundational to digital trust.

What is a digital certificate?

A digital certificate is a file that binds a verified identity, such as a domain name, organization, person, or device, to a cryptographic key pair. That binding lets two systems authenticate each other and encrypt data in transit, even if they have never interacted before.

One way to picture it is a digital passport. A passport contains information about its holder and is issued by a trusted authority that vouches for that information. A certificate does the same for a machine or user, carrying identity details plus a public key, and it is signed by an authority that other systems already trust.

At the heart of every certificate is a key pair. The public key is embedded in the certificate and shared openly, while the matching private key stays securely under the control of the entity the certificate represents. That asymmetric pairing is what makes identity verification possible.

How a digital certificate works

In practice, a certificate follows a simple flow. It carries a public key and identity data. A trusted authority signs it to confirm that the identity is legitimate. A relying party, such as a browser or an application, checks that signature before it agrees to trust the connection.

The most visible example is the TLS handshake that secures web traffic. At a high level it runs like this:

1. Client hello: The client opens the connection, sending its supported TLS version and cipher suites along with a random value known as a nonce.
2. Certificate presentation: The server responds with its signed certificate and a signature over the nonce, presenting its verified identity.
3. Validation: The client verifies the nonce signature with the public key in the certificate, then traces the certificate’s own signature up the chain to a trusted root. This confirms the server is who it claims to be.
4. Key exchange: Once identity is confirmed, the two sides negotiate a shared symmetric key.
5. Secure channel: That symmetric key encrypts the rest of the session, protecting the data from interception or tampering.

The signature is what makes the whole model work. Because anyone can obtain a copy of a public certificate, checking that the nonce was signed correctly proves the other party actually holds the matching private key. In most web connections only the server presents a certificate, but mutual TLS (mTLS) requires both sides to authenticate, a pattern that is increasingly common in API security, zero-trust architectures, and industrial systems.

Another familiar example is SSH, which secures remote administration. This high level description of the protocol is as follows.

1. Client hello: The client opens the connection, exchanging protocol version banners and a list of supported key exchange, host key, encryption, and MAC algorithms.
2. Key exchange: Both sides generate ephemeral key pairs and exchange public values, deriving a shared secret that neither side transmits. Everything said so far is folded into a single exchange hash.
3. Host authentication: The server either presents its certificate or its bare public key, along with a signature over that exchange hash, proving control of the matching host private key and binding the identity to this specific exchange.
4. Validation: The client checks the signature, then checks whether it trusts the host key itself, either because the key already appears in its list of known hosts, or because the key is carried in a certificate signed by an authority the client trusts. From this point the channel is encrypted.
5. User authentication: Inside the now-encrypted channel, the client proves who the user is, most often by signing a challenge with a private key whose public half the server already accepts.

It is worth mentioning that, in the case of SSH, certificates are optional. The no-certificate model works well at small scale, where each client keeps a list of known hosts and each server keeps a list of authorized keys. It strains as the fleet grows, for two reasons. First, the number of trust relationships to distribute grows with the product of users and hosts, whereas a certificate authority reduces it to a single trusted key on each side. Second, entries in these files carry no expiry, so access persists until someone removes it by hand, while certificates expire on their own. There is also a gap the file-based model cannot close: on a first connection to an unknown host, the client has nothing to validate against and falls back on asking the user to accept a fingerprint they rarely verify.

How many types of digital certificates are there?

There are three primary functional types of digital certificates:

• Server certificates secure data in transit over the open internet and confirm that a site is what it claims to be. They supply the public key that underpins the security of the protocol and help prevent domain spoofing and man-in-the-middle attacks.
• Code-signing certificates prove who published a piece of software and confirm that the code has not been altered since it was signed. A timestamp applied at signing keeps the signature valid even after the certificate itself expires, which matters for long-lived software.
• User/client certificates authenticate people or devices. They work like a far stronger replacement for passwords, and they are a natural fit for two-factor authentication and zero-trust access schemes.

The three differ in purpose, but they share one common trait: trust. Each depends on a verified identity and a key pair that a relying party can check.

Certificate format families

There is not a one-size-fits-all certificate format that can fit every application. Different protocols call for different formats, each designed around the needs of the system it serves. The X.509 standard, for example, notes that SSH deliberately uses a different certificate type because the SSH protocol has its own requirements, and that PGP relies on a decentralized model rather than central authorities.

Four families cover most of what you will encounter in practice: X.509, SSH, OpenPGP, and the JSON-based JOSE formats. The sections below walk through each before comparing them side by side.

X.509 certificates

X.509 is the foundation of public key infrastructure (PKI). It is rooted in the X.500 directory standard, was introduced by the International Telecommunication Union, and has been adopted as an internet standard in RFC 5280. It binds a verified identity to a key pair and defines the exact fields that make a certificate interoperable across systems. Here we give a brief overview of this format. To learn more about it, see our complete guide on X.509 certificates.

Core fields. 
Every X.509 certificate carries a defined set of data, including a version number, a serial number assigned by the issuing certificate authority, a signature algorithm identifier, the issuer name, a validity period, and the subject public key information. The validity period is set by two timestamps, not before and not after, which limit how long the certificate can be trusted and reduce the damage a leaked private key can cause.

Version 3 extensions. 
Version 3 introduced an extensions framework that greatly expanded what a certificate can express. Each extension has an identifier, a critical flag, and a value. If a recipient does not recognize an extension marked critical, it must reject the certificate. Common extensions include key usage constraints, subject alternative names (which let one certificate cover multiple domains), certificate policies, and basic constraints that distinguish CA certificates from end-entity certificates.

Version history. 
Version 1 (1988) defined the core structure. Version 2 (1993) added issuer and subject unique identifiers, now considered deprecated. Version 3 (1996 onward) added the extensions framework, and virtually all certificates in production today are Version 3.

Encoding: DER vs. PEM. 
The standard defines what a certificate contains but not how to encode it for storage or transport. Two formats dominate. DER (Distinguished Encoding Rules) is a compact binary format, processed efficiently by browsers, operating systems, and Java applications, and commonly uses the .der or .cer extensions. PEM (Privacy Enhanced Mail) takes that binary data and converts it to Base64 text, recognizable by its “BEGIN CERTIFICATE” header, and is the common choice on Linux systems, web servers, and command-line tools like OpenSSL. Both contain identical data; the only difference is representation, and converting between them is straightforward.

Use cases. 
X.509 certificates power web security through HTTPS, email security through S/MIME, code signing, device authentication, VPN authentication, and mutual TLS for APIs. They also secure operational technology, where standards such as OPC UA rely on them and IEC 62443 mandates certificate-based security above a certain assurance level.

SSH certificates

Plain SSH key authentication forces both client and server to store and manually manage trusted key lists, which is hard to scale and vulnerable to impersonation during key exchange. SSH certificates solve this by binding an identity to a key and shrinking the point of trust down to a single CA that can authenticate both clients and servers.

SSH defines two certificate types: User certificates for clients and Host certificates for servers. Instead of the distinguished names used by X.509, SSH certificates rely on principals, which bind a certificate to specific identities, usernames for clients and host names for servers. Certificates can also carry critical options that tighten how they may be used, including:

• force-command, which locks the certificate to a single command regardless of what the user types.
• source-address, a list of addresses the certificate may be used from.
• verify-required, which requires FIDO user verification such as a PIN or biometric for security-key types.

SSH supports RSA of any size, the elliptic curve types EC P256, P384, and P521, and ed25519. Notably, the signing algorithm is not selected separately; in SSH it is defined by the key type. And because SSH does not define a CA hierarchy, SSH CAs are normally self-signed, relying on the public key alone.

OpenPGP certificates

OpenPGP certificates take a fundamentally different approach to trust. Instead of routing every decision through a central authority, OpenPGP uses a decentralized “web of trust” in which any user can vouch for another user’s identity by signing their key. Trust accumulates from the endorsements of many peers rather than descending from a single root.

This model reflects OpenPGP’s origins in secure email and file signing among individuals and communities, where no shared central authority exists or is wanted. Its strength is autonomy: no gatekeeper decides who can participate. Its weakness is scale and consistency, because trust depends on how well connected a given key is within the web and how carefully participants verify one another before signing. For that reason, the web of trust tends to work best within tight-knit communities rather than across the open internet, which is where the hierarchical model has become dominant.

JOSE (JWT, JWS, JWK) formats

The JOSE family, short for JSON Object Signing and Encryption, brings identity and integrity to JSON-based systems rather than to the binary structures X.509 relies on. It is worth understanding as a comparison point, since it appears constantly in modern web and API development even though it is not a certificate format in the traditional sense.

• JWT (JSON Web Token) is a compact, URL-safe token that carries claims about a subject, most familiar as the bearer tokens passed around in web authentication and single sign-on.
• JWS (JSON Web Signature) defines how to sign that JSON content so a recipient can verify it has not been tampered with.
• JWK (JSON Web Key) represents a cryptographic key as a JSON object, which makes key distribution simple for services that already speak JSON.

Where X.509 packages an identity and a public key into a signed certificate validated through a CA chain, JOSE formats typically move signed claims and keys between services that already share a trust relationship, such as an identity provider and the applications that rely on it. The two often coexist: an API gateway might terminate a TLS connection with an X.509 certificate and then authorize the request using a JWT.

Comparing the format families at a glance

Format	Trust model	Typical use	Encoding
X.509	Hierarchical CAs	TLS, S/MIME, code signing, device and mTLS authentication	DER (binary) or PEM (Base64 text)
SSH	Single, usually self-signed SSH CA	Client and server authentication for remote access	SSH certificate format, keyed by RSA, EC, or ed25519
OpenPGP	Decentralized web of trust	Email and file signing and encryption	OpenPGP message and key format
JOSE (JWT/JWS/JWK)	Shared trust between services	Web and API tokens, claims, and key exchange	JSON text

The clearest dividing line is the trust model. X.509 and SSH lean on designated authorities, OpenPGP distributes trust across peers, and JOSE assumes a trust relationship already exists between the services exchanging tokens.

The trust model: how certificates establish trust

Underneath every format sits a question of trust: why should a relying party believe a certificate at all? Two models answer it.

The hierarchical model places certificate authorities at the top. A small number of widely trusted roots anchor the system, and everything else derives its trust from them. The decentralized web of trust, used by OpenPGP, spreads trust across peers who vouch for one another with no central anchor.

Both are valid, but they scale differently. The hierarchical model is the one that underpins enterprise and internet use, because centralized trust decisions and automated validation are exactly what large, fast-moving environments need. The web of trust, by contrast, thrives in smaller communities where participants can personally verify one another.

Certificate chains and certificate authorities

Hierarchical trust works through a chain that a client can walk from the certificate in front of it back to a root it already trusts. A typical chain has three levels:

1. A self-signed root CA certificate, pre-installed in browser and operating system trust stores, whose private key is kept safely offline.
2. An intermediate CA certificate, which does the everyday work of signing certificates so the root’s key stays protected.
3. The end-entity certificate presented by a website, server, or device.

When a client receives an end-entity certificate, it validates each signature up the chain, accepting the certificate only if every link checks out and it reaches a trusted root. Trust stores vary by client. Firefox maintains its own store with roughly 120 roots trusted for TLS, according to the Mozilla Included CA Certificate List, while Chrome generally defers to the operating system’s store, with exceptions such as its separate list for Extended Validation and its Certificate Transparency requirement. Trust can even span organizations through cross-certification, where two roots sign each other’s certificates so that clients trusting one will accept certificates issued under the other.

Validation levels

Every certificate system, whatever its format, has to answer the same question before it issues anything: how confident are we that the subject is who they claim to be? The answer is never binary, so each family develops a way of grading it and communicating that grade to whoever will later rely on the certificate. In TLS this is the familiar ladder of Domain Validation, which proves only control of a name; Organization Validation, which additionally verifies that a legal entity exists and is connected to that name; and Extended Validation, which adds incorporation records, physical presence, and confirmation of signing authority. Code signing uses the same graded logic, having retired its lowest tier so that publisher identity is now always organization-verified with keys held in hardware. Client and S/MIME certificates run the same pattern from mailbox control up through verified individual identity backed by government documents. In each case the grade is recorded as a policy OID inside the certificate, so a relying party can read the assurance level rather than infer it.

The same instinct appears wherever certificates are used, even in systems that look nothing like the public CA model. PGP records it as a confidence value the signer attaches to each signature, letting the relying party weigh several attestations rather than defer to one. SSH records it implicitly, in the provisioning process behind the CA: a certificate issued only after the host is enrolled in configuration management, or after the user authenticates to an identity provider, carries exactly as much assurance as those upstream checks provide, which is why SSH CAs can safely issue certificates measured in hours. What differs across the families is where the grade is written down and who is trusted to assign it. What they share is the recognition that a certificate is only ever as strong as the identity check performed before it was signed, and that the strength of that check has to travel with the certificate rather than being left for the relying party to guess.

Self-signed vs. CA-issued certificates

A self-signed certificate is signed by the same entity that created it. It can still enable authentication, but it offers no independent verification of identity. The passport analogy is apt: writing your own name on a piece of paper and presenting it at a border produces a nice document with no proven identity behind it. Practitioners describe self-signed certificates as unmanaged as well as unverified, since no one tracks the expiration date the creator quietly set. When those certificates lapse, the result is often an outage, and self-signed certificate problems are a common cause of them.

For that reason, self-signed certificates are appropriate only in controlled, non-production settings such as local development, isolated internal labs, and proof-of-concept demonstrations. CA-issued certificates are required for production, because they provide a verifiable chain of trust that browsers and applications validate automatically, backed by an authority that checked the holder’s identity and a managed lifecycle that tracks expiration. One nuance worth noting: root CA certificates are themselves self-signed, but that is a structural property of a trust anchor, with trust conferred by distribution into trust stores rather than by the signature.

Certificate revocation

Certificates carry a built-in expiration, but expiration alone is not enough. Sometimes a certificate has to be invalidated well before its “not after” date, for example when a private key is compromised, a system is decommissioned, or a certificate is simply no longer needed. The moment a private key is known to be compromised, the certificate is undermined regardless of how much validity remains.

It helps to separate two ideas. Expiration is the passive validity window built into every certificate. Revocation is the active step of withdrawing trust ahead of that window. Revocation is a core stage of certificate lifecycle management and the control that keeps the trust chain honest when real-world conditions change faster than validity periods allow.

How revocation checking works (CRL and OCSP)

Relying parties need a way to learn that a certificate has been revoked. Two mechanisms dominate.

A certificate revocation list (CRL) is a signed, timestamped file published by a CA that lists the serial numbers of certificates revoked before their expiration. Defined in RFC 5280, each entry includes the serial number, the revocation date, and optionally a reason code such as key compromise or cessation of operation. A relying party finds the list through the CRL Distribution Points extension in the certificate, downloads it, and checks whether the serial number appears. CRLs are simple and universally supported, but they can grow large, which is why partitioned and delta CRLs exist to keep downloads manageable. You can dive deeper in this guide to what a certificate revocation list is.

The Online Certificate Status Protocol (OCSP), defined in RFC 6960, flips the model. Instead of downloading a full list, the client asks about a single certificate by querying the OCSP responder named in the certificate’s Authority Information Access extension. The responder returns a small signed answer of “good,” “revoked,” or “unknown.” OCSP stapling improves this further by letting the web server fetch and cache the response, then deliver it during the TLS handshake, which cuts latency and protects user privacy. For the mechanics, see this explainer on how OCSP works.

The two approaches trade off freshness against efficiency, and many teams use both. If you are weighing which to lean on, this comparison of CRL vs. OCSP lays out the decision. Worth noting: for the public web, browsers are shifting toward locally distributed revocation data, while OCSP and CRLs remain central to enterprise and private PKI.

Revocation across formats

Revocation is not identical across every certificate type. SSH, for instance, uses Key Revocation Lists (KRLs) rather than X.509-style CRLs, and it leans heavily on short-lived, sometimes ephemeral certificates. When a certificate lives for only hours, the window in which revocation matters shrinks dramatically, which reduces reliance on revocation checking in the first place. That pattern, favoring short lifetimes over active invalidation, is increasingly influential across the wider certificate world as public lifespans shrink toward 47 days.

How Keyfactor can help

Managing one certificate is easy. Managing every certificate and format across an enterprise, without outages or policy gaps, is the real challenge, and it is where automation becomes essential. As lifespans shorten toward 47-day renewals, the operational volume of renewals rises roughly eightfold, and spreadsheets and email reminders stop working.

Keyfactor addresses this with an end-to-end approach to certificate lifecycle automation across X.509 and SSH. EJBCA, its enterprise PKI platform, issues and manages certificates at scale, supports standard enrollment protocols such as SCEP, CMP, EST, and ACME, and offers the crypto-agility needed for the post-quantum transition. Keyfactor Command sits across every CA in the environment to provide discovery, inventory, monitoring, renewal, and revocation from one place, along with CRL and OCSP endpoint monitoring so an expired list or unreachable responder never goes unnoticed. For teams that would rather not run the infrastructure themselves, PKI as a Service delivers managed PKI and revocation infrastructure.

The payoff connects directly to the challenges in this guide: fewer outages, consistent policy enforcement, readiness for shorter certificate lifespans, and a head start on post-quantum cryptography.