Certificate management sounds like a wall of acronyms—PKI, CA, CSR, SAN, CRL, OCSP—until you see how the pieces connect. This page is a concept-first guide for anyone new to TLS and OpenSSL: what each term means, how trust flows from a root CA down to your web server, and what happens during a TLS handshake before encrypted data moves.
I organized it the way most teams learn: keys and certificates first, then CAs and chains, then formats and revocation, then TLS and mutual TLS. Short OpenSSL commands appear where they make the ideas concrete; I ran them on Ubuntu 25.04 so you can compare your output. When you are ready to issue real certs, continue with the OpenSSL & PKI tutorial hub.
Tested on: Ubuntu 25.04 (Plucky Puffin); kernel 6.14.0-37-generic; OpenSSL 3.4.1.
Quick answer: what is PKI?
Public Key Infrastructure (PKI) is the framework that binds identities to public keys using digitally signed certificates. A Certificate Authority (CA) you trust signs a server’s certificate; your browser or API client validates that signature against trusted root CAs, checks expiry and revocation, then uses the server’s public key to set up encrypted TLS traffic.
Without PKI you still have encryption—but you cannot be sure you are talking to the real site, not an impostor with another key pair.
Glossary: terms you will hear daily
| Term | Plain meaning |
|---|---|
| PKI | The whole system: keys, certs, CAs, trust stores, revocation |
| Asymmetric crypto | Key pair: public key encrypts or verifies; private key decrypts or signs |
| X.509 | Standard format for public-key certificates (versions v1–v3; v3 adds extensions) |
| DN (Distinguished Name) | Text identity in a cert, e.g. CN=www.example.com,O=Acme |
| CSR | Certificate Signing Request—unsigned request sent to a CA for signing |
| CA | Entity that issues and signs certificates |
| Root CA | Top of the chain; its cert is self-signed and stored in trust stores |
| Intermediate CA | Sub-CA signed by root; signs end-entity (leaf) certificates |
| Leaf / end-entity cert | Server, client, or user certificate used in production |
| SAN | Subject Alternative Name—DNS names, IPs, emails the cert is valid for |
| Trust store | OS or browser bundle of trusted root CA certificates |
| CRL | Certificate Revocation List—periodic download of revoked serial numbers |
| OCSP | Online Certificate Status Protocol—real-time good/revoked/unknown check |
| TLS / SSL | Protocol that encrypts traffic; certificates authenticate the server (and sometimes the client) |
| mTLS | Mutual TLS—both sides present and verify certificates |
Public keys, private keys, and why trust matters
In asymmetric cryptography each party has a key pair:
- The private key must stay secret. Whoever holds it can prove ownership of the matching certificate or decrypt data meant for that key.
- The public key can be shared. It appears inside the certificate and is used during the TLS handshake.
Encrypting traffic alone is not enough. An attacker can present their own key pair and still speak TLS with you. PKI adds identity: a CA (or your internal policy) attests that this public key belongs to www.yourbank.com or your corporate VPN gateway.
What is a digital certificate?
A certificate is a signed document that says: “this public key belongs to this identity, for this period, according to this issuer.” The most common format is X.509 version 3.
Typical fields you will inspect with openssl x509:
| Field | What it tells you |
|---|---|
| Subject | Who the cert is for (CN, organization, country) |
| Issuer | Which CA signed it |
Validity (notBefore / notAfter) |
When the cert is valid |
| Serial number | Unique ID per issuer; used in revocation |
| Public key | RSA, ECDSA, or Ed25519 key bound to the cert |
| Extensions | SAN, key usage, basic constraints, EKU, etc. |
On a lab host I issued a three-level chain (root → intermediate → server) and printed the leaf metadata:
openssl x509 -in server.pem -noout -subject -issuer -dates -serialsubject=CN=www.example.test
issuer=CN=Demo Intermediate CA
notBefore=Jul 2 07:05:30 2026 GMT
notAfter=Jul 2 07:05:30 2027 GMT
serial=2B9CEB3E35AC58FCFAA75045A9D9F642B6A0CB1EThe issuer of the leaf should match the subject of the intermediate above it in the chain. To decode a file on disk, see View certificate with OpenSSL.
Certificate Signing Requests (CSR)
Before a CA signs your certificate, you usually generate a key pair locally and create a CSR. The CSR contains the public key and the name(s) you want in the certificate; it is signed with your private key so the CA knows you control that key.
Typical flow:
- Generate private key (
openssl genrsaoropenssl genpkey). - Create CSR with desired DN and SAN (
openssl req -new). - Submit CSR to a CA (public CA, internal portal, or your own
openssl ca). - Receive signed certificate (and often intermediate chain files).
The CSR is not a certificate—it cannot enable HTTPS until the CA signs it. Pitfalls (wrong SAN, weak key size, missing extensions) are covered in Things to consider when creating a CSR and Generate CSR with OpenSSL.
Certificate Authorities and the chain of trust
A Certificate Authority issues certificates after it validates identity according to its policy. There are two broad classes:
| Type | Who uses it | Examples |
|---|---|---|
| Public CA | Internet-facing sites and services | DigiCert, Sectigo, Google Trust Services, Let's Encrypt |
| Private CA | Internal apps, VPN, mTLS meshes, dev clusters | Your company's root CA on Linux |
CAs are rarely a single hop. A root CA signs an intermediate CA; the intermediate signs your server certificate. Clients trust the root (preinstalled in the OS or browser); they build a path from leaf → intermediate → root.
The root certificate is self-signed: no higher authority exists, so the root signs itself and you explicitly trust it (public roots ship in trust stores; private roots are distributed by your IT team).
Verify a chain with OpenSSL once you have the PEM files:
openssl verify -CAfile root.pem -untrusted intermediate.pem server.pemserver.pem: OKHands-on CA build: Create a Root CA on Linux and Build the certificate chain.
Common certificate types
| Type | Purpose | Notes |
|---|---|---|
| Server TLS | HTTPS, LDAPS, SMTPS | Needs SAN matching every hostname clients use |
| Wildcard | *.example.com |
One cert for many subdomains; SAN or CN pattern |
| SAN (multi-name) | Several hostnames or IPs on one cert | Standard for modern public CAs |
| Client | Identifies a user or device to a service | Used in VPN and mTLS |
| Code signing | Signs software binaries | Different EKU and key storage rules |
| Email (S/MIME) | Sign or encrypt email | Less common in DevOps guides |
A self-signed certificate is signed by the same key that it contains—typical for a lab root CA or generate self-signed certificate on localhost. Browsers do not trust self-signed server certs unless you import them manually.
X.509 extensions that matter in production
Version 3 certificates carry extensions—extra rules beyond subject and public key:
| Extension | Why it matters |
|---|---|
subjectAltName |
Hostnames and IPs clients must match (required for HTTPS in practice) |
basicConstraints |
CA:TRUE for CAs; CA:FALSE for servers |
keyUsage |
What the key may do (digitalSignature, keyEncipherment, keyCertSign, …) |
extendedKeyUsage |
serverAuth, clientAuth, codeSigning, etc. |
subjectKeyIdentifier / authorityKeyIdentifier |
Link certs in a chain |
Example SAN on the lab server cert:
openssl x509 -in server.pem -noout -ext subjectAltNameX509v3 Subject Alternative Name:
DNS:www.example.testMore examples: Subject Alternative Name and Add X.509 extensions.
Certificate file formats (PEM, DER, PKCS#12, PKCS#7)
The same logical certificate can be stored in different encodings:
| Format | Encoding | Typical extensions | Common use |
|---|---|---|---|
| PEM | Base64 text with BEGIN/END lines |
.pem, .crt, .key |
Linux, nginx, Apache, OpenSSL CLI |
| DER / CER | Binary | .der, .cer |
Windows exports, Java keystores import |
| PKCS#12 | Binary bundle (cert + key + chain) | .pfx, .p12 |
Windows IIS, Java, Azure |
| PKCS#7 | ASCII or DER cert bag | .p7b, .p7c |
CA bundles from some vendors |
Convert or inspect without guessing:
# PEM text cert — human readable
openssl x509 -in cert.pem -text -noout
# Binary DER — add -inform DER
openssl x509 -in cert.cer -inform DER -text -nooutExport and import PKCS#12: Create PFX from CRT and KEY and Extract private key from PFX. Default OpenSSL paths on disk: OpenSSL config locations.
Revocation: CRL and OCSP
Certificates have an expiry date, but compromise or policy change can require early invalidation. Revocation answers: “should this serial number still be trusted?”
Certificate Revocation List (CRL)
The CA publishes a signed CRL file listing revoked serial numbers (until they expire). Clients or TLS libraries download the CRL periodically and reject listed certs. CRLs can grow large and stale between updates.
Online Certificate Status Protocol (OCSP)
The client sends the certificate serial number to an OCSP responder. The responder returns good, revoked, or unknown without downloading the full CRL. Stapling (OCSP stapling) lets the server attach a fresh OCSP response during TLS to save client round trips.
| Mechanism | Pros | Cons |
|---|---|---|
| CRL | Simple offline model; works in locked-down networks | Large files; delay until next CRL fetch |
| OCSP | Fast per-cert check | Responder must be online; privacy considerations |
OpenSSL revocation labs: Revoke certificate and generate CRL and Revoke a missing or lost certificate.
How TLS uses certificates (handshake overview)
When a browser opens https://example.com, TLS negotiates encryption and authenticates the server. Simplified steps:
- ClientHello — client offers TLS versions and cipher suites.
- ServerHello — server picks parameters and sends its certificate (and often intermediates).
- Certificate validation — client builds a chain to a trusted root, checks hostname against SAN, expiry, and revocation (CRL/OCSP).
- Key exchange — client and server agree on session keys (modern TLS 1.3 uses fewer round trips than TLS 1.2).
- Finished — both sides confirm; application data flows encrypted with symmetric keys.
openssl s_client -servername hostname. Without SNI you may inspect the wrong certificate on shared hosting.
Quick live check (dates change when the site renews):
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesInstall a cert on a web server: Install SSL certificate on Nginx.
Mutual TLS (mTLS) in brief
Standard HTTPS (TLS) proves the server to the client. Mutual TLS also proves the client to the server—both sides present certificates.
Typical mTLS flow differences:
- Server sends its certificate as usual.
- Server requests a client certificate (
CertificateRequest). - Client sends its certificate; server validates chain and policy.
- Session keys are derived; both identities are established.
Use mTLS for service-to-service APIs, zero-trust meshes, and admin interfaces—not for ordinary public websites. End-to-end lab: Mutual TLS authentication.
Common misconceptions
| Myth | Reality |
|---|---|
| “A certificate encrypts traffic” | TLS encrypts; the certificate identifies the peer and carries the public key |
| “CN alone is enough for HTTPS” | Clients require SAN; CN-only certs fail hostname checks |
openssl verify checks cert matches private key |
It checks chain trust only; use modulus or pubkey compare for key pairing (verify cert matches key) |
| “Self-signed is fine for production public sites” | Visitors get warnings unless they manually trust your root |
| “Revocation never happens” | Compromised keys and early reissues require CRL or OCSP |
Next steps: hands-on OpenSSL lessons
This page is conceptual. The OpenSSL & PKI tutorial hub walks through each task in order:
| Goal | Start here |
|---|---|
| Install the CLI | Install OpenSSL on Ubuntu |
| Issue SAN server certs | Generate CSR and SAN certificate |
| Renew and revoke | Renew SSL/TLS server certificate |
References
Summary
PKI ties identities to public keys through signed X.509 certificates. You generate a private key and CSR locally; a Certificate Authority signs the CSR after validation; clients trust the result only if they can chain the cert to a root they already believe. Extensions such as SAN and key usage define where and how the cert may be used. PEM is the usual Linux format; PKCS#12 bundles cert and key for Windows and Java. When a cert must die early, CRLs and OCSP tell clients not to trust it. TLS uses that trust to set up encryption; mTLS adds client authentication. Use the diagrams and sample openssl output above as a map, then follow the OpenSSL tutorial hub for step-by-step commands on your own machine.
