Understanding X.509 Digital Certificates: SSL and TLS Explained

A digital certificate is an electronic document that binds a cryptographic public key to a verified identity — a website, an application, a device or a person — and is signed by a Certificate Authority so that anyone can verify the binding is genuine.

Almost every certificate you will encounter follows the X.509 standard, which defines what a certificate contains and how it is structured. Every time you see the padlock icon in your browser, an X.509 certificate is doing that work.

Key points

• X.509 is the standard that defines certificate format and structure. SSL, TLS, code signing and S/MIME certificates are all X.509 certificates used for different purposes.
• A certificate proves identity because a trusted Certificate Authority signed it, not because of anything in the certificate itself.
• Public TLS certificate lifetimes are shortening on a fixed schedule: 200 days from March 2026, 100 days from March 2027, 47 days from March 2029.
• That makes manual certificate management impractical for any estate of meaningful size.

What is an X.509 certificate?

X.509 is an ITU-T standard that specifies the format of public key certificates. When people talk about SSL certificates, TLS certificates or digital certificates in a business context, they almost always mean X.509 certificates.

The certificate itself is a structured document containing defined fields. The current version, X.509 v3, includes the following.

What an X.509 certificate contains

• Version. Which X.509 version the certificate conforms to. Almost always v3.
• Serial number. A unique identifier assigned by the issuing CA. Used to identify the certificate in revocation lists.
• Signature algorithm. The algorithm the CA used to sign the certificate, for example SHA-256 with RSA.
• Issuer. The distinguished name of the Certificate Authority that issued it.
• Validity period. Not-before and not-after dates. Outside this window the certificate is invalid, and the services depending on it will fail.
• Subject. The distinguished name of the entity the certificate identifies.
• Subject public key info. The public key itself, plus the algorithm it uses. This is the part the certificate exists to distribute.
• Extensions. The v3 additions that carry most of the operational detail — see below.
• Signature. The CA's digital signature over everything above. This is what makes the certificate trustworthy.

The extensions that matter

• Subject Alternative Name (SAN). The domain names the certificate covers. Modern browsers ignore the Common Name field entirely and rely on SAN, so a certificate without it will fail validation.
• Key Usage and Extended Key Usage. What the certificate is permitted to do — server authentication, client authentication, code signing, email protection. Applications enforce these, and a mismatch causes failures that are difficult to diagnose.
• Basic Constraints. Whether the certificate is a CA certificate and how many levels can sit beneath it.
• CRL Distribution Points and Authority Information Access. Where to check revocation status and where to find the issuing certificate.
• Certificate Policies. Object identifiers indicating the policy under which the certificate was issued.

Certificates are encoded in either DER, a binary format, or PEM, which is base64-encoded DER wrapped in header and footer lines. PEM files are the ones you will recognise, beginning with BEGIN CERTIFICATE.

What is a "509 compliant" digital certificate?

This is a common way of asking the question and the terminology is slightly off. The standard is X.509, not 509, and certificates are not usually described as "509 compliant" — they either conform to X.509 or they are not certificates in any useful sense.

What people generally mean is one of two things. Either they need a certificate that follows the X.509 v3 standard, which any certificate from any reputable CA will do by default. Or a procurement document has specified "X.509 compliant" and they need confirmation that a proposed solution meets it, which again it almost certainly will.

If the requirement comes from a compliance framework, the substantive questions are usually about key length, signature algorithm, validity period and where the private key is stored — not about X.509 conformance itself.

How SSL, TLS and X.509 relate to each other

These three terms get used interchangeably and they mean different things.

• SSL (Secure Sockets Layer) is the original protocol for encrypting connections. Every version of it has been deprecated and it should not be in use anywhere.
• TLS (Transport Layer Security) is its successor and what actually secures connections today. TLS 1.2 and 1.3 are the current versions.
• X.509 is the certificate format that TLS uses to establish identity during the handshake.

So "SSL certificate" is a misnomer that has outlived the protocol it refers to. The industry kept the term because it was familiar. What is actually being sold and deployed is an X.509 certificate used by TLS.

The relationship to public key infrastructure is straightforward: PKI is the whole framework — the certificate authorities, policies, revocation infrastructure and processes — that issues and manages X.509 certificates. TLS is one protocol that consumes them. Code signing, S/MIME and client authentication are others.

The certificate chain

A certificate is only trusted because something else vouches for it. That chain has three levels.

• Root CA. A self-signed certificate held in the trust store of the operating system or browser. Root private keys are kept offline, usually in a hardware security module, and used only to sign intermediates.
• Intermediate CA. Signed by the root, and used to issue end-entity certificates. Intermediates exist so the root can stay offline and so a compromise can be contained without invalidating everything beneath the root.
• End-entity certificate. The certificate on your server, device or user. Also called a leaf certificate.

Validation works upwards. A client checks the server's certificate, follows the chain to the intermediate, then to the root, and accepts the connection if the root is one it already trusts. If any intermediate is missing from what the server presents, validation fails — which is one of the most common causes of certificate errors that appear to make no sense.

How to get an X.509 certificate

Three routes, depending on what the certificate is for.

From a public Certificate Authority

For anything a browser or external party must trust automatically. You generate a key pair and a Certificate Signing Request, submit it to a CA such as DigiCert or Sectigo, complete their validation process, and receive the signed certificate. Cost and validation depth vary by certificate type.

Free, via ACME

Let's Encrypt and other ACME-enabled CAs issue domain-validated certificates at no cost, fully automated. ACME handles the validation challenge, issuance and renewal without human involvement, which is why it has become the default for public-facing web services. Our guide to certificate management protocols covers how ACME compares with EST, SCEP and CMP.

From your own internal CA

For internal systems, devices and users, organisations run their own Certificate Authority using platforms such as Microsoft AD CS or EJBCA. You control the trust store, the validity periods and the policy, and there is no per-certificate cost. Internal certificates are not trusted by external parties, which is the point.

Choosing between these is an architecture decision rather than a procurement one, and it is part of what our PKI design and build service addresses.

Types of digital certificate

Validation levels for TLS certificates

Public TLS certificates come in three validation levels. All three provide identical encryption — the difference is how much the CA verified before issuing.

• Domain Validated (DV). Confirms only that the applicant controls the domain. Validation is automated and completes in minutes, via an HTTP file, a DNS TXT record or an email to a pre-approved address. Suitable for personal sites, internal services and development environments. Provides no assurance about the organisation behind the domain.
• Organisation Validated (OV). Adds manual verification of the organisation's registered name, address and incorporation jurisdiction against government records and business databases, plus confirmation that the requester is authorised. Takes days. The organisation name appears in the certificate details.
• Extended Validation (EV). Adds verification of legal status, operational existence, contact details and financial standing, with the requester's identity verified individually. Takes weeks. Provides the highest identity assurance, though its practical value has declined since browsers stopped displaying the green address bar that once distinguished EV certificates visually.

Certificates for other purposes

• Code signing certificates verify that software has not been tampered with since publication and comes from a verified publisher.
• S/MIME certificates enable email encryption and digital signing.
• Client certificates authenticate users and devices, commonly for VPN access, mutual TLS and zero trust architectures.
• Document signing certificates provide cryptographic proof of authorship and integrity for legally binding documents.

The certificate lifecycle

Every certificate follows the same sequence.

• Key generation and request. A key pair is generated and a Certificate Signing Request submitted to a CA. The private key never leaves the requesting system.
• Validation and issuance. The CA verifies the request and signs the certificate.
• Deployment. The certificate is installed on the server, application, device or user store. A renewal is not complete until the application is actually serving the new certificate, which usually requires a restart or configuration reload.
• Monitoring and renewal. The certificate must be replaced before its not-after date, with enough lead time to retry if the renewal fails.
• Revocation. If the private key is compromised or the certificate mis-issued, the CA revokes it and publishes that status.
• Retirement. The certificate is removed from systems and records archived for audit.

Our guide to certificate lifecycle management covers this in detail.

Why certificate management matters now

Certificate lifetimes are shortening on a fixed schedule. In April 2025 the CA/Browser Forum voted to reduce the maximum validity of publicly trusted TLS certificates in three stages:

• March 2026 — maximum lifetime reduces to 200 days
• March 2027 — maximum lifetime reduces to 100 days
• March 2029 — maximum lifetime reduces to 47 days

Domain control validation reuse periods shorten alongside them, meaning re-validation as well as re-issuance becomes more frequent.

By 2029, a certificate that needed renewing once a year will need renewing roughly eight times. An organisation with a thousand public certificates moves from a thousand renewal events annually to around eight thousand. We have covered what the reduction in TLS certificate lifetimes means in practice separately.

The security rationale is sound — shorter lifetimes narrow the window of exposure if a key is compromised or a certificate mis-issued. The operational consequence is that manual management stops working.

Growing certificate complexity

The estate is diversifying as well as accelerating. Internal TLS and mutual TLS, code signing, S/MIME, and certificates embedded in IoT devices and operational technology all have their own issuance workflows, validation requirements, lifespans and revocation mechanisms.

As these proliferate across cloud platforms, pipelines, devices and users, visibility fragments. Most organisations cannot say where every certificate is deployed, who owns it or when it expires. That sprawl increases operational risk and expands the attack surface. Our article on why traditional certificate management is no longer enough explores this.

The DevOps challenge

Cloud-native architectures have increased certificate turnover dramatically. Containers, microservices and short-lived workloads need certificates issued, rotated and revoked at machine speed. In many environments certificates exist for hours, yet must still be trusted, tracked and secured.

Processes designed for static infrastructure and annual renewals do not scale to environments where services are created and destroyed continuously. Without automation integrated into CI/CD pipelines and orchestration platforms, certificate management becomes a bottleneck or a source of outages. The four pillars of CLM sets out how to address this.

Certificate Transparency and revocation

Certificate Transparency

Certificate Transparency provides publicly accessible, append-only logs recording the issuance of publicly trusted TLS certificates. CAs submit certificates to multiple independent logs at issuance.

The purpose is detection. If someone fraudulently obtains a certificate for your domain, monitoring CT logs reveals its existence even if it was never deployed. Browser policies, notably Chrome's, require certificates to include Signed Certificate Timestamps from multiple distinct logs.

Requiring SCTs from several independent logs improves resilience. If one log becomes unavailable or is later disqualified, certificates carrying SCTs from other trusted logs remain verifiable — and concealing a mis-issued certificate would require multiple independent logs to collude. Certificates failing SCT requirements may be rejected outright or trigger security warnings.

Revocation

• Certificate Revocation Lists (CRLs) are periodically published lists of revoked certificates. They can become large and are increasingly impractical at internet scale.
• Online Certificate Status Protocol (OCSP) allows near real-time status checks by querying the CA directly.
• OCSP stapling has the server fetch its own OCSP response periodically and include it in the TLS handshake, removing the need for the client to contact the CA. Particularly useful where clients cannot reach the CA directly.

Revocation is the component most often assumed to work rather than tested. In segmented networks, systems frequently have no route to the distribution points the design assumed would be reachable.

How Unsung supports certificate management

We help organisations gain visibility and control over their certificate estates.

• Discovery identifying certificates across the infrastructure, including those outside the visibility of central IT.
• PKI health checks assessing current practice against security best practice and compliance requirements.
• Certificate lifecycle management covering automated issuance and renewal, continuous monitoring and proactive alerting.
• PKI consultancy for organisations building or extending automation in house.
• Managed PKI where you would rather transfer operational delivery entirely.

For guidance on evaluating solutions, see our article on key features in an enterprise CLM deployment. Contact us to discuss your certificate estate.

Frequently asked questions

What is the difference between an SSL certificate and an X.509 certificate?

There is no difference in practice. SSL certificate is an informal term that has outlived the protocol it refers to. What is being sold and deployed is an X.509 certificate, used by TLS rather than SSL. SSL itself has been deprecated in all versions.

What is a 509 compliant digital certificate?

The standard is X.509, and any certificate issued by a reputable Certificate Authority conforms to it by default. Where a procurement or compliance document specifies "X.509 compliant", the substantive requirements are usually about key length, signature algorithm, validity period and private key protection rather than the certificate format itself.

How do I get an X.509 certificate?

Three routes. For anything externally trusted, apply to a public Certificate Authority and complete their validation. For automated public TLS, use an ACME-enabled CA such as Let's Encrypt, which issues and renews without human involvement. For internal systems, issue from your own Certificate Authority using a platform such as Microsoft AD CS or EJBCA.

What is inside an X.509 certificate?

Version, serial number, signature algorithm, issuer, validity period, subject, the subject's public key, v3 extensions and the issuing CA's signature. The extensions carry most of the operational detail, including Subject Alternative Name, Key Usage, Basic Constraints and revocation distribution points.

What is the difference between DER and PEM?

Both encode the same certificate. DER is a binary format. PEM is base64-encoded DER wrapped in BEGIN CERTIFICATE and END CERTIFICATE lines, which makes it readable as text and easier to paste into configuration.

Why does my certificate fail validation even though it has not expired?

Most commonly because the server is not presenting the full chain. A client needs the intermediate certificate to link the server certificate to a trusted root. Other frequent causes are a missing or incorrect Subject Alternative Name, an Extended Key Usage that does not permit the intended purpose, or the client being unable to reach the revocation distribution point.

What is the difference between DV, OV and EV certificates?

The level of verification the CA performs before issuing, not the strength of the encryption, which is identical. DV confirms domain control only and issues in minutes. OV adds verification of the organisation and takes days. EV adds verification of legal status, operations and the requester's identity, and takes weeks.

How long are certificates valid for?

Publicly trusted TLS certificates are limited to 200 days from March 2026, reducing to 100 days from March 2027 and 47 days from March 2029. Internal certificates issued by your own Certificate Authority are not subject to these limits, though many organisations align internal policy with the public standard.

Can a certificate be cancelled before it expires?

Yes, through revocation. The Certificate Authority publishes the revoked status via a Certificate Revocation List or the Online Certificate Status Protocol, and clients that check these will stop trusting the certificate. Revocation only works if the relying systems can actually reach the revocation infrastructure.

What happens when a certificate expires?

The services depending on it fail immediately. Websites become inaccessible, APIs stop responding and users see security warnings. Expiry is not a gradual degradation — validation fails the moment the not-after date passes.