IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Certificates and chains of trust
Bot A connects to api.example.com. How does it know the server's public key really belongs to that name? A certificate says so. A chain of signers backs it up, and the chain ends at a short list that your computer already trusts. Your goal: read a certificate chain and know which checks decide if it is good.
- A certificate ties a public key to a name. A CA signs it.
- The server name must match the SAN field.
- A chain goes leaf, intermediate, root. The root is already trusted.
- Only a certificate with CA:TRUE may sign other certificates.
- Public certificates are logged in public. Never turn checks off.
A signed name tag for a public key
A public key is only a long number. It cannot say who holds the private key. A certificate says: "this public key belongs to this name, for this time." A certificate authority (CA) signs it. Almost every certificate is an X.509 certificate. See keys and signatures for the basics.
The field that counts for names is the SAN (Subject Alternative Name). It lists the names the certificate is valid for. The current rules take the server's name only from the SAN. The old subject CN field no longer counts. A plain name like example.com matches only itself.
A wildcard such as *.example.com covers exactly one level. It matches api.example.com. It does not match example.com. It does not match v2.api.example.com.
Root, intermediate, leaf
The root CA certificate vouches for itself. Its private key stays offline. The root signs intermediate CA certificates. The intermediates do the daily work and sign leaf certificates for servers. If an intermediate is hacked, replace it. The root stays untouched.
a notarized copy of a document. A notary checks your ID once, then stamps the paper. A bank accepts it because it trusts the notary, and a government office registered that notary. Change one word after the stamp, and the stamp no longer fits. The same holds for a certificate.
What "validating the chain" checks
The client's TLS library checks every certificate from the leaf upward.
- The links. Each issuer is the next certificate's subject. The path ends at a root in the client's trust store.
- The signatures. Each one verifies with the issuer's public key.
- The dates. Today is inside every certificate's valid dates.
- The CA flags. Every certificate that signed another one has
CA:TRUE. A leaf withCA:FALSEcannot make more certificates, even if its own signature is valid. - The name. The host you meant to reach matches a SAN entry.
- The purpose. The key use fits:
serverAuthfor a server,clientAuthfor an mTLS client. - Revocation. Nobody has taken the certificate back.
The server sends its leaf and its intermediates. It does not send the root. The client must already have it.
Certificate Transparency
Certificate Transparency (CT) makes wrong certificates visible. CAs put every public TLS certificate in public, append-only logs. So anyone can see every host name on it, even staging-payments.example.com. Keep internal names on a private CA.
Your TLS library checks all this until someone switches it off with curl -k, verify=False or InsecureSkipVerify: true. Then TLS is "encrypted, to anyone at all". Fix the certificate or trust the right CA instead.
Go deeper: Certificate fields
| Field | What it says | Example |
|---|---|---|
| Subject | Who the certificate is about | CN=api.example.com |
| SAN | The names it is valid for: DNS names, IP addresses, URIs, emails | DNS:api.example.com |
| Issuer | The CA that signed it | CN=Example Issuing CA 2 |
| Validity | Not before, not after | 2026-08-01 → 2026-11-29 |
| Public key | The key being vouched for | an EC P-256 key |
| Serial number | Unique for each issuer. Revocation uses it. | 5A:1F:… |
| Key usage | What the key may do | serverAuth or clientAuth |
| Basic constraints | May this certificate sign others? | CA:FALSE on a server certificate |
| Signature | The issuer's signature over all of the above | change one byte and it fails |
The name rules are in RFC 9525 (November 2023). X.509 is defined in RFC 5280. A SPIFFE ID, from the SPIFFE lesson, also sits in the SAN, as a URI.
Forgetting the intermediate is a common bug. Some browsers fetch a missing intermediate, so the site looks fine. Command-line tools, phone apps and API clients fail with "unable to get local issuer certificate".
Go deeper: Trust stores, private CAs and self-signed certificates
A trust store is the list of root certificates a client accepts. Operating systems, browsers and language runtimes each carry their own. Adding a root is powerful: that CA can vouch for any name. Company inspection proxies install their own root on company laptops.
For internal services and mTLS, companies run a private CA. It is their own root, trusted only by their own machines. Open-source options include step-ca and EJBCA Community. SPIRE issues SPIFFE certificates for workloads.
A self-signed certificate vouches for itself. That is fine for local development, or when the other side was set up in advance with that exact certificate. It is harmful where people learn to click past the warning.
Go deeper: Revocation: CRL, OCSP and shorter lives
If a private key leaks, the CA revokes its certificate. There are two classic ways to publish this.
- A CRL (certificate revocation list, RFC 5280) is a signed list of revoked serial numbers. Clients download it.
- OCSP (Online Certificate Status Protocol, RFC 6960) lets a client ask the CA about one certificate. With OCSP stapling, the server attaches the answer to the handshake.
Live OCSP had problems. It told the CA which sites visitors opened. It added delay. If the CA did not answer, clients carried on. So the industry is moving away from it. From March 15, 2024 (CA/Browser Forum ballot SC-063), OCSP is optional and CRLs are required for public TLS CAs. Let's Encrypt switched off its OCSP service on August 6, 2025. Chrome uses pushed lists called CRLSets. Firefox 137 turned on CRLite in 2025.
The other answer is short-lived certificates. Under ballot SC-081, the longest life of a public TLS certificate shrinks over time. By 2029 it is 47 days. The TLS lesson has the dates.
Go deeper: More on Certificate Transparency
CT is defined in RFC 6962. The logs give back signed receipts (SCTs). They usually travel inside the certificate. Chrome and Apple platforms reject public TLS server certificates without them. Domain owners can watch the logs for certificates they did not ask for.
Bot A's calls to a partner API fail with "unable to get local issuer certificate", though the site looks fine in a browser. Zara prints the chain the server really sends. It holds only the leaf. The partner left out the intermediate when renewing. A developer says: turn verification off tonight. Zara says no. The partner adds the full chain.
🧪 Interactive lab — enable JavaScript to play with this one.
badssl.com is an open-source test site with broken certificates. Try expired.badssl.com, wrong.host.badssl.com, untrusted-root.badssl.com and incomplete-chain.badssl.com. To see the chain a real server sends, run openssl s_client -connect example.com:443 -servername example.com -showcerts. Each certificate shows its subject (s:) and issuer (i:). The root is not sent, because the client's trust store already holds it. Then grade a real certificate with Cert Lint.