Certificates Explained: X.509, Keys, Chains and Revocation

This is for anyone who runs a website or a server and has to deal with certificates: buying or renewing one, fixing a browser warning, or working out why a client refuses to connect. It covers what a certificate contains and how a client decides to trust it. It doesn't cover cipher suites, post-quantum algorithms or step-by-step setup with a particular CA; those belong in their own guides.

Everything here is based on the RFCs and vendor documentation listed at the end, not on lab testing (checked October 27, 2026). Every name and address in the examples is made up.

What a certificate does#

A certificate ties a name, such as www.example.com, to a public key, and a certificate authority (CA) signs that statement. When your browser connects, the server shows its certificate and proves it holds the matching private key. The browser checks the CA's signature, the name, the dates and the rest of the chain. If any of that fails, you get a warning instead of a padlock.

The format is X.509 version 3, defined for the internet in RFC 5280. "SSL certificate" is the old name. The protocol it's used with today is TLS.

Keys: the public half and the private half#

Every certificate starts with a key pair. The public key goes into the certificate and anyone can see it. The private key stays on the server and never goes into the certificate.

The two halves are mathematically linked. Something signed with the private key can be checked with the public key. That's how the server proves, during each connection, that it's the real owner of the certificate rather than someone who copied it.

That makes the private key the part to protect. A certificate on its own is public information. A certificate plus its private key lets anyone impersonate your site. Files that bundle the two, such as PFX files, need the same care as a password.

The certificate signing request#

To get a certificate, you generate a key pair and send the CA a certificate signing request (CSR). The PKCS #10 format in RFC 2986 says a request "consists of a distinguished name, a public key, and optionally a set of attributes", signed with the requester's private key. That signature, the RFC explains, "prevents an entity from requesting a certificate with another party's public key".

The private key isn't in the CSR. You send the request; the key stays where you generated it. ACME, the protocol Let's Encrypt uses, works the same way: the client finishes an order "by submitting a PKCS#10 Certificate Signing Request (CSR)" (RFC 8555).

Some hosting plans generate the key and the CSR for you. The result is the same.

What's inside a certificate#

Here's what the main fields look like for an ordinary website certificate. The names, dates, serial number and URLs are all invented.

Subject:              CN=www.example.com
Subject Alt Names:    DNS:www.example.com, DNS:example.com
Issuer:               CN=Example Issuing CA 1, O=Example CA
Serial number:        01:23:45:67:89:ab:cd:ef
Validity:             Not before 2026-10-01 00:00 UTC
                      Not after  2026-12-30 00:00 UTC
Public key:           RSA, 2048 bits
Key usage:            Digital Signature, Key Encipherment
Extended key usage:   TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
Basic constraints:    CA:FALSE
CRL distribution:     http://crl.example.com/issuing-ca-1.crl
Authority info:       CA Issuers: http://crt.example.com/issuing-ca-1.crt

What each one means, with the RFC 5280 section:

• Subject and Subject Alternative Name (SAN). Who the certificate is for. The next section explains why the SAN is the one that counts.
• Issuer. The CA that signed it. The client uses this to find the next certificate up the chain.
• Serial number. It "MUST be unique for each certificate issued by a given CA" (§4.1.2.2). Revocation lists identify certificates by serial number.
• Validity. The certificate is valid "from notBefore through notAfter, inclusive" (§4.1.2.5).
• Key usage. What the key may do at a low level: digital signatures, encrypting keys, signing other certificates (keyCertSign) or signing CRLs (cRLSign) (§4.2.1.3).
• Extended key usage (EKU). What the certificate is for. Server Authentication (1.3.6.1.5.5.7.3.1) is for TLS servers and Client Authentication (1.3.6.1.5.5.7.3.2) for clients. "If the extension is present, then the certificate MUST only be used for one of the purposes indicated" (§4.2.1.12).
• Basic constraints. Whether this is a CA certificate. CA:FALSE means it can't sign other certificates. On a CA, a path length limit can stop it from creating further CAs below it (§4.2.1.9).
• CRL distribution points say where to download the CA's revocation list (§4.2.1.13). Authority information access says where to fetch the issuer's certificate, and can also name an OCSP responder (§4.2.2.1).

The OpenSSL inspection cheatsheet and the Windows certificate commands show how to read each of these fields on a real certificate.

Names: why the SAN matters#

The subject's common name (CN) used to carry the server name. It doesn't any more. RFC 9525, which replaced RFC 6125, says "The Common Name RDN MUST NOT be used to identify a service." Modern clients follow it: they match the name they connected to against the DNS names in the SAN and ignore the CN. Apple, for example, says TLS server certificates "must present the DNS name of the server in the Subject Alternative Name extension" and that "DNS names in the CommonName of a certificate are no longer trusted." Some older clients still fall back to the CN, and Microsoft's LDAPS guidance accepts the name in either. Don't rely on that: put every name the server answers to in the SAN.

Two rules that catch people out (RFC 9525 §6.3):

• A wildcard appears "only as the complete content of the left-most label". *.example.com is valid; www*.example.com and www.*.example.com aren't.
• A wildcard "can only match one label". *.example.com covers www.example.com but not example.com itself, and not a.b.example.com. To cover the bare domain too, list it in the SAN separately, as the illustration does.

An IP address works only if it's in the SAN as an IP address entry, and it has to match exactly (§6.2).

Chains and trust anchors#

A browser doesn't trust your certificate directly. It trusts a short list of root certificates that come with the operating system or browser. Those roots are the trust anchors. Your certificate is usually signed by an intermediate CA, and the intermediate is signed by the root:

1. Leaf: www.example.com, signed by the intermediate.
2. Intermediate: Example Issuing CA 1, signed by the root.
3. Root: Example Root CA, self-signed and already in the client's trust store.

The client builds this chain from your certificate up to a root it already trusts, checking each signature, the dates and the constraints on the way. If it can't reach a trusted root, the connection fails.

The server sends the chain. In TLS 1.3, the server's own certificate "MUST come in the first CertificateEntry", and each one after it "SHOULD directly certify the one immediately preceding it". The certificate that specifies the trust anchor "MAY be omitted" (RFC 8446 §4.4.2), because the client already has it. So the server sends the leaf plus the intermediates. If it sends only the leaf, a client that doesn't already have the intermediate can't build the chain, while another client that happens to have it connects fine. My advice: always install the full chain your CA gives you, and don't count on the client fetching a missing intermediate.

There can be more than one valid chain. CAs cross-sign their intermediates and roots, so "sometimes there's more than one valid chain for a given certificate", in Let's Encrypt's words. Let's Encrypt's own hierarchy changes over time. Its newer ISRG Root YE and YR were generated in September 2025 and, on its chains page dated July 8, 2026, are "not yet included in Root Program Trust Stores", so its default chains still end at ISRG Root X1. Don't hard-code a CA's chain from an old blog post; get it from the CA.

Trust stores differ. Windows, macOS, each browser and each Linux distribution keep their own list of roots. OpenSSL "does not provide a default set of trust anchors"; it uses whatever store the system gives it. A certificate that one client trusts can fail on another because the root isn't in that client's store.

Validity and lifetimes#

Every certificate has a hard end date, and certificate lifetimes are getting shorter. Let's Encrypt's default is 90 days. It plans to cut the maximum to 45 days by February 2028, and from March 15, 2029 the CA/Browser Forum's rules cap publicly trusted certificates at 47 days for every CA. Let's Encrypt also offers optional 6-day certificates.

At those lengths, renewing by hand stops being practical. Plan for automated renewal (ACME), and monitor expiry dates either way.

Clock problems look like validity problems. A device whose clock is wrong can reject a perfectly good certificate as "not yet valid" or "expired".

Revocation: CRLs and OCSP#

Sometimes a certificate has to be withdrawn before it expires, most urgently when its private key may have leaked. The CA then revokes it. There are two ways for clients to find out:

• Certificate revocation lists (CRLs). The CA publishes a signed list of revoked serial numbers. The certificate's CRL distribution point says where to get it.
• OCSP. The client asks the CA's responder about one certificate and gets back "good", "revoked" or "unknown" (RFC 6960). A server can fetch that answer itself and "staple" it to the handshake.

Don't assume OCSP is available. Let's Encrypt turned its OCSP service off on August 6, 2025, and now publishes revocation information "exclusively via Certificate Revocation Lists (CRLs)". Its certificates no longer carry an OCSP address. Other CAs, and internal CAs, may still run OCSP.

Revocation checking varies by client. Let's Encrypt's revoking page says that "some browsers will check CRLs". Treat revocation as damage control, not as the main defense: protect the private key, and replace the certificate as soon as you suspect a problem.

At Let's Encrypt you can revoke a certificate with the account that issued it, with the certificate's own private key, or from another account after proving control of every name in it. It accepts only four reasons: unspecified, keyCompromise, superseded and cessationOfOperation.

Where the certificate fits in the TLS handshake#

In TLS 1.3 (RFC 8446), a connection starts like this:

1. ClientHello. The client says which versions and algorithms it supports. It also sends the server name it wants (SNI, the server_name extension) so a server hosting several sites can pick the right certificate.
2. ServerHello. The server picks the parameters. "All handshake messages after the ServerHello are now encrypted," so in TLS 1.3 the certificate isn't visible on the wire.
3. Certificate. The server sends its certificate and the intermediates.
4. CertificateVerify. The server signs the whole handshake so far with its private key. This proves it holds the key, and because the signature covers this handshake's messages, it can't be reused in another connection.
5. Finished. Both sides confirm the handshake wasn't tampered with, then application data flows.

The client checks the chain and the name once it has the certificate. If a check fails, the handshake stops there.

Public certificates and internal ones#

A public CA such as Let's Encrypt only issues for names it can check you control from the internet. Let's Encrypt's HTTP-01 challenge puts a file on your web server, DNS-01 adds a TXT record at _acme-challenge.<your domain>, and TLS-ALPN-01 works over port 443. Only DNS-01 can issue wildcard certificates.

That's why a public certificate is the wrong tool for names that exist only on your internal network, such as dc01.corp.example.com when corp.example.com isn't public DNS. Those get certificates from an internal CA, often Microsoft Active Directory Certificate Services (AD CS), and the organization distributes its root to its own devices.

Internal certificates follow the same X.509 rules, but each role has its own requirements. A domain controller's LDAPS certificate needs the Server Authentication EKU and the DC's fully qualified name in the subject or SAN. Microsoft's requirements for a domain controller certificate issued by a third-party CA list both Client Authentication and Server Authentication, and the DC's DNS name in the SAN.

KDC Authentication (1.3.6.1.5.2.3.5) is needed only in some setups. Windows Hello for Business needs it on the domain controller's certificate. Smart card sign-in needs it when clients have the "Require strict KDC validation" policy turned on. With that policy off, Microsoft says the client "requires only that the KDC certificate contains the Server Authentication purpose". Microsoft's Windows Hello for Business guide notes that certificates from the Domain Controller and Domain Controller Authentication templates don't include the KDC Authentication OID.

A certificate that's right for one role isn't automatically right for another. The Active Directory side gets its own articles.

Check it yourself#

• On Linux or macOS: the OpenSSL certificate inspection cheatsheet reads any of the fields above and tests a live server with s_client.
• On Windows: the Windows certificate commands cheatsheet covers certlm.msc, certutil -verify and the PowerShell Cert: drive.
• Running a small-business website: the website hosting guide covers where TLS fits with your host and domain.