Appendix

Glossary

Every PKI and TLS term used on this site, from ACME to X.509, each with a one-line answer, a fuller explanation and the chapter that teaches it.

Each entry starts with a short answer you can read in a few seconds, then a fuller explanation for when you need the detail. Abbreviations such as CSR, HSM and SNI have their own short entries that point to the full term. Follow the chapter link under an entry to learn the idea properly, with diagrams, real commands and a quick check.

A

ACME#: Automatic Certificate Management Environment: the protocol that lets software request, validate and renew certificates from a CA without a human.; ACME (RFC 8555) automates the whole certificate process. A client creates an account with the CA, places an order for some names, proves control of each name by answering a challenge (HTTP-01, DNS-01 or TLS-ALPN-01), sends a CSR and downloads the certificate. Let's Encrypt made it popular, and most public and many private CAs now support it. With certificate lifetimes getting shorter, ACME or a similar automation is close to essential.; Also called: Automatic Certificate Management Environment; Chapter 20: ACME and the 47-day schedule
ACME challenge#: The test an ACME client passes to prove it controls a domain: HTTP-01, DNS-01 or TLS-ALPN-01.; For HTTP-01 the client publishes a token at a fixed path on the website; for DNS-01 it creates a TXT record under _acme-challenge; for TLS-ALPN-01 it answers a special TLS handshake. The CA checks the response from several network locations before issuing. Wildcard certificates need DNS-01. A passed challenge can be reused for a limited time.; Also called: challenge, HTTP-01, DNS-01, TLS-ALPN-01; Chapter 20: ACME and the 47-day schedule
AEAD (authenticated encryption)#: Encryption that also protects integrity: the receiver can detect any change to the ciphertext before trusting the decrypted data.; Authenticated Encryption with Associated Data combines encryption with an authentication tag computed under the same key. Decryption fails if a single bit of the ciphertext, the tag or the extra 'associated data' was changed. AES-GCM and ChaCha20-Poly1305 are AEAD modes, and TLS 1.3 allows only AEAD cipher suites. Each message needs a unique nonce for the same key.; Also called: authenticated encryption, AES-GCM, ChaCha20-Poly1305; Chapter 1: Symmetric encryption: one shared key
AES#: The Advanced Encryption Standard: the symmetric block cipher used to encrypt most data on the internet, with 128-, 192- or 256-bit keys.; AES (FIPS 197) encrypts data in 16-byte blocks with a shared secret key. On its own it is a building block; real protocols use it in a mode of operation such as GCM, which also protects integrity. AES is fast, often built into processors, and not broken by quantum computers: Grover's algorithm only weakens it, so 256-bit keys keep a large margin for long-term secrets.; Also called: Advanced Encryption Standard, Rijndael; Chapter 1: Symmetric encryption: one shared key
ARI (ACME Renewal Information)#: An ACME extension in which the CA tells each client when to renew a certificate, instead of the client guessing.; The CA publishes a renewalInfo endpoint that returns a suggested renewal window for each certificate. Clients check it regularly and renew inside the window. That spreads renewals out evenly and, if a CA must revoke many certificates early, lets it ask clients to renew at once, without anyone having to notice an email.; Also called: ACME Renewal Information, renewalInfo; Chapter 20: ACME and the 47-day schedule
ASN.1#: Abstract Syntax Notation One: the language used to describe the structure of certificates, CSRs, CRLs and keys.; ASN.1 describes data structures such as 'a certificate is a SEQUENCE of tbsCertificate, signatureAlgorithm and signatureValue'. The structures are then encoded into bytes with DER, a strict encoding that gives exactly one byte string for each value, which is what signatures are computed over. PEM files are DER bytes written in Base64 with a label.; Also called: Abstract Syntax Notation One; Chapter 8: Anatomy of an X.509 certificate
Asymmetric encryption#: Encryption with a key pair: anyone can encrypt with the public key, and only the holder of the matching private key can decrypt.; Asymmetric, or public-key, encryption solves the key-distribution problem: you can publish your public key freely. It is slow and limited in size, so in practice it protects a short secret, such as a session key, and fast symmetric encryption protects the data. Modern TLS 1.3 does not encrypt with the certificate key at all; it uses key exchange instead.; Also called: public-key encryption; Chapter 3: Key pairs: public and private keys
Authentication tag#: A short value computed with the secret key over an encrypted message, so the receiver can detect any change to it.; In authenticated encryption such as AES-GCM, the sender computes a tag from the key, the nonce, the ciphertext and any associated data. The receiver recomputes it and refuses to decrypt if the tags differ. Without the key, an attacker cannot produce a valid tag for a changed message, so tampering is detected instead of silently producing garbage or, worse, attacker-chosen plaintext.; Also called: MAC tag, tag; Chapter 1: Symmetric encryption: one shared key
Authenticode#: Microsoft's code signing format for Windows programs, drivers and scripts, with the signature embedded inside the file.; Authenticode stores a CMS signature, the signer's certificate chain and usually an RFC 3161 timestamp inside a Windows executable or script. Windows checks it when you run downloaded software or install drivers. SignTool creates and verifies Authenticode signatures, and PowerShell's Get-AuthenticodeSignature reads them. A valid signature shows who published the file and that it is unchanged, not that it is safe.; Chapter 24: Signed and sealed: code and document signing
Authority Information Access (AIA)#: A certificate extension with links to the issuer's certificate and, sometimes, its OCSP responder.; The AIA extension can contain a 'CA Issuers' URL where a client can download the issuing CA's certificate, and an OCSP URL for status checks. Browsers often use the CA Issuers link to fetch a missing intermediate, which hides a server's broken chain. Many other clients, such as curl, OpenSSL, Java and Python, do not, so they fail until the server sends the intermediate itself.; Also called: AIA, CA Issuers; Chapter 13: Certificate chains and path validation
Authority Key Identifier (AKI)#: A certificate extension that identifies the public key of the CA that signed the certificate.; The Authority Key Identifier usually holds a hash of the issuing CA's public key. It matches the Subject Key Identifier in the issuer's own certificate. Path-building software uses the pair to find the right issuer quickly, which matters when a CA has several certificates with the same name, for example after cross-signing or a key rollover.; Also called: AKI; Chapter 13: Certificate chains and path validation
Avalanche effect#: The property that a tiny change in the input of a hash function or cipher changes about half of the output bits.; Change one character of a document and its SHA-256 hash looks completely different, with no visible relation to the old one. This is what makes hashes useful as fingerprints: you cannot tweak data a little to get a hash that is only a little different, and similar inputs reveal nothing about each other.; Chapter 5: Hashes and fingerprints

B

Baseline Requirements#: The CA/Browser Forum's rules that every publicly trusted TLS certificate authority must follow.; The Baseline Requirements for publicly trusted TLS server certificates cover how CAs validate domains and organisations, what certificates may contain, how long they may be valid, how fast CAs must revoke, how keys are protected and how CAs are audited. Browsers' root programs require them. Separate CA/Browser Forum documents cover EV, code signing and S/MIME certificates.; Also called: BRs, CA/Browser Forum Baseline Requirements; Chapter 11: Proving you own the name: DV, OV, EV and CAA
Basic Constraints#: The certificate extension that says whether a certificate belongs to a CA (CA:TRUE) and may sign other certificates.; Basic Constraints holds the CA flag and an optional path length limit. CA:TRUE means the certificate's key may sign other certificates; CA:FALSE marks an end-entity certificate such as a server's. pathLenConstraint limits how many CA levels may follow below. Clients must refuse a chain in which a certificate without CA:TRUE signed another certificate.; Also called: CA flag, pathLenConstraint; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
Block cipher#: A symmetric cipher that encrypts fixed-size blocks of data, such as AES with 16-byte blocks.; A block cipher turns one block of plaintext into one block of ciphertext under a key. To encrypt messages of any length safely, it is used in a mode of operation such as GCM or CBC. Encrypting each block separately with the same key (ECB mode) leaks patterns, which is why modes and nonces matter.; Chapter 1: Symmetric encryption: one shared key
Brute force#: Trying every possible key until one works. Long enough keys make it impossible in practice.; A brute-force attack needs, on average, half of all possible keys. Each extra bit doubles the work, so a 128-bit key has about 3.4 × 10^38 possibilities, far beyond any computer. Good ciphers have no shortcut better than brute force. Grover's algorithm on a quantum computer would roughly halve the effective key length, which is one reason to prefer 256-bit keys for long-term secrets.; Also called: brute-force attack, exhaustive key search; Chapter 1: Symmetric encryption: one shared key

C

CAA record#: A DNS record in which a domain owner lists the certificate authorities allowed to issue certificates for that domain.; Certification Authority Authorization (RFC 8659) lets you publish, for example, 'only letsencrypt.org may issue for example.com'. Publicly trusted CAs must check CAA before issuing and refuse if they are not listed. CAA does not affect clients that validate certificates; it is a guard at issuance time against mistakes and some kinds of mis-issuance.; Also called: CAA, Certification Authority Authorization; Chapter 11: Proving you own the name: DV, OV, EV and CAA
Certificate#: A signed document that binds a public key to a name, such as a website's domain, issued by a certificate authority.; A digital certificate, almost always in X.509 format, contains a subject name, the subject's public key, the issuer, a validity period, extensions such as the subject alternative name, and the issuer's signature over all of it. It is public: anyone can copy it. It proves nothing on its own; the holder proves its identity by using the matching private key. Certificates do not encrypt anything.; Also called: digital certificate, X.509 certificate, public key certificate; Chapter 8: Anatomy of an X.509 certificate
Certificate authority (CA)#: An organisation or system that checks who controls a name or key and signs certificates that bind them together.; A CA verifies a request, for example that the requester controls a domain, then signs a certificate with its private key. Clients trust the certificate if they can build a chain from it to a root CA in their trust store. Public CAs are trusted by browsers and must follow the CA/Browser Forum rules and root program policies. Private CAs serve one organisation.; Also called: CA, certification authority; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Certificate chain#: The sequence of certificates from a server's leaf certificate, through one or more intermediates, up to a trusted root.; Each certificate in a chain is signed by the next one up. A server must send its leaf and the intermediates; the client supplies the root from its trust store. If an intermediate is missing, many clients fail with errors such as 'unable to get local issuer certificate'. A chain is only accepted if every signature, date, name and constraint checks out.; Also called: chain of trust, certification path; Chapter 13: Certificate chains and path validation
Certificate inventory#: A complete, kept-up-to-date list of the certificates an organisation uses, where they are installed, who owns them and when they expire.; Most certificate outages come from certificates nobody knew about. An inventory records each certificate's names, issuer, expiry date, key algorithm, location and owner, and is fed by automatic discovery: scanning endpoints, reading Certificate Transparency logs and querying CAs. It is the basis for renewal, for incident response when a CA is distrusted, and for planning algorithm changes such as post-quantum migration.; Also called: certificate discovery; Chapter 19: Inventory, expiry and renewal
Certificate lifecycle#: Everything that happens to a certificate: request, issuance, deployment, monitoring, renewal, and finally expiry, replacement or revocation.; Each step can fail: a forgotten renewal, a certificate installed without its intermediate, a service that never reloads the new file, a key that leaks. Managing the lifecycle means an inventory, automation such as ACME for issuance and renewal, monitoring of expiry dates and of what servers actually present, and clear owners for every certificate.; Also called: certificate lifecycle management, CLM; Chapter 19: Inventory, expiry and renewal
Certificate pinning#: Making an app accept only a specific certificate or public key for a server, instead of any certificate its trust store accepts.; Pinning hard-codes an expected certificate, public key or CA into a client. It can block mis-issued certificates, but it breaks the connection whenever the server's key or CA changes, which happens often with short-lived certificates and cross-signing. Browsers dropped HTTP public key pinning for that reason. If you pin at all, pin to several keys and have a tested way to update the pins.; Also called: pinning, public key pinning; Chapter 14: Two roads to the same root: cross-signing and root expiry
Certificate policy (CP)#: A document that sets the rules a CA's certificates follow and what relying parties can expect from them.; A certificate policy states who may get certificates, how identities are checked, how keys are protected and what the certificates may be used for. It is identified by an object identifier that can appear in certificates. RFC 3647 gives the standard outline. The CPS describes how a particular CA actually meets the policy.; Also called: CP; Chapter 22: A CA of your own: private two-tier PKI
Certificate signing request (CSR)#: A signed message that asks a CA for a certificate. It holds the public key and the requested names; the private key stays with you.; A CSR, in PKCS #10 format (RFC 2986), contains the subject name, the public key, optional requested extensions such as the subject alternative name, and a signature made with the matching private key. The signature proves the requester holds that key. The CA validates the request, may change or ignore fields, and issues the certificate. Never send the private key itself.; Also called: CSR, PKCS #10, certificate request; Chapter 10: Asking for a certificate: key generation and the CSR
Certificate Transparency (CT)#: A system of public, append-only logs where publicly trusted TLS certificates are recorded, so anyone can spot certificates issued for their domains.; CAs submit each certificate, or a precertificate, to several independent CT logs and receive signed certificate timestamps (SCTs), which browsers such as Chrome and Safari require. Logs are Merkle trees, so they can prove a certificate is included and that the log was only appended to. Domain owners and researchers use monitors to search the logs and catch mis-issued certificates.; Also called: CT; Chapter 17: Certificate Transparency
CertificateVerify#: The TLS 1.3 handshake message in which a server, or a client in mutual TLS, signs the handshake with its private key.; CertificateVerify contains a signature over a hash of all handshake messages so far, made with the private key that matches the certificate just sent. It proves the sender holds that key, for this connection only. The certificate key is used only for this signature; the session keys come from the ephemeral (EC)DHE key exchange.; Also called: Certificate Verify; Chapter 15: The TLS 1.3 handshake
Certification practice statement (CPS)#: A CA's document that describes in detail how it issues, manages and revokes certificates.; The CPS explains the CA's actual practices: validation steps, key ceremonies, HSMs, staff roles, audits, revocation and record keeping. Public CAs must publish one, and auditors check that the CA follows it. Together with the certificate policy, it is what lets a relying party judge how much to trust the CA's certificates.; Also called: CPS, certification practice statement; Chapter 22: A CA of your own: private two-tier PKI
Cipher#: An algorithm that turns readable plaintext into unreadable ciphertext with a key, and back again.; A cipher is the encryption algorithm itself, such as AES or ChaCha20. Its security should depend only on the key staying secret, never on the algorithm being secret. In TLS, a cipher suite names the combination of algorithms a connection uses, such as TLS_AES_128_GCM_SHA256.; Also called: encryption algorithm; Chapter 1: Symmetric encryption: one shared key
Cipher suite#: A named set of cryptographic algorithms that a TLS connection uses, such as TLS_AES_128_GCM_SHA256.; In TLS 1.3 a cipher suite names only the AEAD cipher and the hash used for key derivation; key exchange and signature algorithms are negotiated separately. TLS 1.2 suites named everything at once, including the key exchange. Client and server agree on one suite during the handshake. Configuring only strong suites is part of hardening a server.; Chapter 15: The TLS 1.3 handshake
Ciphertext#: Encrypted data. Without the right key it looks like random bytes and reveals nothing about the plaintext except, usually, its length.; Ciphertext is what an eavesdropper sees on the network. A good cipher makes it impossible to learn the plaintext without the key. Encryption alone does not stop someone changing the ciphertext, which is why modern systems use authenticated encryption that detects any tampering.; Chapter 1: Symmetric encryption: one shared key
Client certificate#: A certificate that a client, such as a service, device or user, presents to prove its identity to a server in mutual TLS.; When a server asks for it, the client sends its certificate and signs the handshake with the matching private key. The server checks the chain against its own trust anchors for clients, usually a private CA, and the clientAuth purpose in the extended key usage. Public TLS certificates are becoming server-only, so client certificates come from private or dedicated CAs.; Also called: client authentication certificate; Chapter 23: Both sides show ID: mutual TLS
Clock skew#: A difference between a computer's clock and the real time, which can make valid certificates look expired or not yet valid.; Certificates are valid only between their notBefore and notAfter times, so a client checks them against its own clock. A device whose clock is wrong, for example after a dead battery or before it syncs with a time server, rejects good certificates. Some CAs set notBefore slightly in the past to tolerate small skews. Device onboarding protocols must cope with devices that do not know the time.; Chapter 8: Anatomy of an X.509 certificate
Code signing#: Signing software so users and systems can check who published it and that it has not been changed since.; The publisher signs a hash of the program with a private key, usually kept in hardware, and attaches its certificate and a trusted timestamp. Operating systems verify the signature, the chain and the codeSigning purpose. A valid signature proves the publisher's identity and the file's integrity, not that the software is safe: attackers can sign malware too.; Chapter 24: Signed and sealed: code and document signing
Common Name (CN)#: A field in a certificate's subject, often holding a hostname. Browsers ignore it for hostname checks; the subject alternative name counts.; Historically the CN held the website name. RFC 2818 deprecated that use long ago, and modern browsers check only the subject alternative name (SAN). Go ignores it too. Some libraries, including OpenSSL-based clients, Python and Node.js, still fall back to the CN when the certificate has no DNS name in its SAN: no SAN at all, or only IP addresses. Always put every name in the SAN.; Also called: CN; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
CRL (certificate revocation list)#: A list, signed by a CA, of the serial numbers of certificates it has revoked before their expiry date.; A CRL contains revoked serial numbers, their revocation dates and reasons, and a validity window (thisUpdate and nextUpdate). Clients download it from the URL in the certificate's CRL Distribution Points extension. CRLs are now mandatory for publicly trusted TLS CAs, and browsers build their own compact revocation lists from them.; Also called: certificate revocation list; Chapter 16: Taking it back: CRLs, OCSP and stapling
CRLite#: Firefox's compact, privacy-friendly way to check whether any publicly trusted certificate has been revoked, without asking the CA.; Mozilla builds compressed data structures from CRLs and Certificate Transparency logs that cover all publicly trusted TLS certificates, and pushes updates to Firefox regularly. Firefox can then check revocation locally: no network request, nothing revealed about the sites you visit, and no soft-fail when a responder is down. Chrome uses a smaller curated list called CRLSets.; Chapter 16: Taking it back: CRLs, OCSP and stapling
Cross-signing#: When a CA's certificate is also signed by another CA, so clients that trust either root can build a valid chain.; A new root CA is not yet in older trust stores. If an established root signs a certificate for the new CA's key, clients can build a path through the old root instead. The same key then has two certificates, and clients may build different paths. Cross-signs expire, so older devices can suddenly fail, as happened when the DST Root CA X3 cross-sign that Let's Encrypt relied on expired.; Also called: cross-certificate, cross-sign; Chapter 14: Two roads to the same root: cross-signing and root expiry
Crypto-agility#: The ability to replace cryptographic algorithms and keys quickly, without rebuilding the systems that use them.; Crypto-agility is a set of habits, not a product: an inventory of where each algorithm is used, algorithms configured rather than hard-coded, protocols that negotiate, and automated certificate renewal. It matters whenever an algorithm weakens, as SHA-1 did, and for the move to post-quantum cryptography, which will touch almost every system that uses RSA or elliptic curves.; Also called: cryptographic agility; Chapter 26: Post-quantum cryptography
Cryptoperiod#: The length of time a key may be used before it must be replaced.; Limiting how long a key is used limits the damage if it leaks and the amount of data an attacker could collect for analysis. NIST SP 800-57 gives recommended cryptoperiods per key type. A CA key's period of use is often shorter than the validity of the certificates it signed, and a root key may be used for years while a TLS session key lives for one connection.; Also called: key lifetime; Chapter 21: Guarding the keys: HSMs and key ceremonies
CSR#: Short for certificate signing request: the signed message with your public key and names that you send to a CA.; A CSR (PKCS #10) proves you hold the private key, because it is signed with it, and lists the names you want in the certificate. You generate the key pair and the CSR on your own system and send only the CSR. The CA checks it, may adjust the fields, and returns a certificate. See also: certificate signing request.; Also called: certificate signing request, PKCS #10; Chapter 10: Asking for a certificate: key generation and the CSR
CT log#: A public, append-only server that records TLS certificates and returns a signed promise (SCT) that it has logged them.; Each Certificate Transparency log is a Merkle tree run by an independent operator. Anyone can download its entries and check proofs that a certificate is included and that the log only ever grew. Browsers accept only logs on their approved lists, and a certificate needs SCTs from several different logs.; Also called: Certificate Transparency log; Chapter 17: Certificate Transparency
CT monitor#: A service that watches Certificate Transparency logs and alerts you when a certificate is issued for one of your domains.; Because browsers accept publicly trusted TLS certificates only if they were logged, a monitor can see every such certificate for your names, including ones you did not request. That is how mis-issuance is noticed; some monitors also watch for look-alike names used in phishing. Several CAs and security companies offer free monitors, and some organisations run their own.; Also called: certificate monitor; Chapter 17: Certificate Transparency

D

Decryption#: Turning ciphertext back into readable plaintext with the right key.; With symmetric encryption, the same secret key encrypts and decrypts. With public-key encryption, the private key decrypts what was encrypted to the matching public key. Authenticated encryption also checks during decryption that the ciphertext was not changed, and refuses to return any plaintext if it was.; Chapter 1: Symmetric encryption: one shared key
DER#: Distinguished Encoding Rules: the strict binary encoding of ASN.1 used for certificates, CSRs, CRLs and keys.; DER gives exactly one byte sequence for each value, which matters because signatures are computed over those exact bytes. A DER certificate usually starts with the bytes 30 82. Windows and Java often use DER files with .cer or .der extensions. PEM is the same DER data in Base64 between BEGIN and END lines.; Also called: Distinguished Encoding Rules; Read the chapter
Device attestation#: A device proving it is genuine hardware from a known manufacturer by signing a fresh challenge with a factory-installed key.; The verifier sends a nonce. The device signs it, together with information about itself, using a private key kept in secure hardware, and returns its certificate chain. The verifier checks the chain to the manufacturer's root, the signature and the nonce. Matter smart-home devices do this with their Device Attestation Certificate; TPMs offer a similar mechanism for PCs.; Also called: attestation; Chapter 25: Machines with passports: device identity
Device certificate#: A certificate that identifies one physical device, usually installed at the factory with its private key locked in a secure chip.; A device certificate names the manufacturer, model and serial number rather than a domain. Its key is generated inside a secure element or TPM and cannot be exported, so the certificate cannot be cloned onto another device. It may be valid for the device's whole life. Owners often add their own, renewable certificate for daily use.; Also called: factory certificate, device identity certificate; Chapter 25: Machines with passports: device identity
Diffie-Hellman#: A method for two parties to agree a shared secret over a public channel, without ever sending the secret itself.; Each side picks a private value and sends a public value derived from it. Combining your private value with the other side's public value gives both sides the same secret, which an eavesdropper cannot compute. Modern TLS uses the elliptic-curve version (ECDHE) with fresh values for every connection. On its own it does not prove who is on the other end, so TLS adds certificates and signatures.; Also called: DH, Diffie-Hellman key exchange; Chapter 4: Key exchange and hybrid encryption
Digital signature#: A value computed from a message and a private key that anyone with the public key can check, proving who signed and that nothing changed.; The signer hashes the message and applies a signing algorithm, such as ECDSA, EdDSA or RSA-PSS, with the private key. A verifier uses the public key to check the signature against the message's hash. Any change to the message makes the check fail. A signature is not 'encrypting with the private key': the message is not hidden, and the maths differs by algorithm.; Also called: signature; Chapter 6: Digital signatures
Distinguished name (DN)#: A structured name made of attributes such as CN, O and C, used for the subject and issuer of a certificate.; A distinguished name looks like 'CN=example.com, O=Example Ltd, C=BE'. Certificates use DNs for the subject and the issuer, and chain building matches the issuer DN of one certificate with the subject DN of the next. Hostnames for TLS belong in the subject alternative name, not in the DN.; Also called: DN, subject name; Chapter 8: Anatomy of an X.509 certificate
Distrust#: When browsers or operating systems stop trusting a CA, so its certificates are rejected even though they have not expired.; Root programs can remove a CA's root from their trust stores, or stop trusting certificates it issues after a certain date, when the CA breaks the rules or is compromised. Sites using that CA must switch to another one, often under time pressure. DigiNotar, Symantec's old infrastructure and Entrust are well-known examples.; Also called: root removal; Chapter 18: Famous failures and what changed
Domain validation (DV)#: A CA checking that the requester controls a domain name before issuing a certificate for it, by an HTTP, DNS or TLS challenge.; The CA asks the requester to place a random token on a web page, in a DNS TXT record or in a special TLS handshake, then checks it from several network locations. A DV certificate proves control of the name at that moment, nothing about the organisation behind it. With ACME, wildcard certificates need the DNS method. Most TLS certificates today are DV.; Also called: DV, domain control validation, DCV; Chapter 11: Proving you own the name: DV, OV, EV and CAA

E

ECDHE#: Elliptic-curve Diffie-Hellman Ephemeral: the usual key exchange in TLS 1.3, agreeing a fresh secret for every connection.; Client and server each generate a new elliptic-curve key pair for the connection, exchange the public halves in the handshake and compute the same shared secret. The session keys are derived from it, then the temporary private keys are thrown away. That gives forward secrecy: stealing the server's certificate key later does not reveal past sessions. X25519 is the most common curve.; Also called: ephemeral elliptic-curve Diffie-Hellman, ECDH; Chapter 4: Key exchange and hybrid encryption
ECDSA#: The Elliptic Curve Digital Signature Algorithm, widely used in TLS certificates, often on the P-256 curve.; ECDSA gives strong signatures with much smaller keys than RSA: a P-256 key offers roughly the security of a 3072-bit RSA key. Many CAs issue ECDSA certificates and ECDSA intermediates. Each signature needs a fresh, secret random value; reusing it leaks the private key. Like RSA, ECDSA would be broken by a large quantum computer.; Also called: Elliptic Curve Digital Signature Algorithm; Chapter 6: Digital signatures
eIDAS#: The EU regulation on electronic identification and trust services, including electronic signatures, seals, time stamps and qualified certificates.; eIDAS (Regulation (EU) No 910/2014, updated by Regulation (EU) 2024/1183) sets the legal effect of electronic signatures across the EU and the rules for qualified trust service providers. A qualified electronic signature has the same legal effect as a handwritten one. The update adds the European Digital Identity Wallet.; Also called: eIDAS Regulation, eIDAS 2; Chapter 24: Signed and sealed: code and document signing
Elliptic-curve cryptography#: Public-key cryptography based on the maths of elliptic curves, giving strong security with small keys.; Elliptic curves power ECDHE key exchange (such as X25519) and ECDSA and EdDSA signatures. A 256-bit elliptic-curve key is roughly as strong as a 3072-bit RSA key, so handshakes are smaller and faster. Like RSA, elliptic-curve cryptography would be broken by a large quantum computer running Shor's algorithm.; Also called: ECC; Chapter 3: Key pairs: public and private keys
Encryption#: Turning readable data into ciphertext with a key, so only someone with the right key can read it.; Encryption protects confidentiality. Symmetric encryption, such as AES, uses one shared key; public-key encryption uses a key pair. On the web, TLS encrypts the traffic with session keys from a key exchange. Certificates themselves do not encrypt anything: they bind a public key to a name.; Chapter 1: Symmetric encryption: one shared key
Extended Key Usage (EKU)#: A certificate extension that lists what the certificate may be used for, such as server authentication, client authentication or code signing.; Common EKU values are serverAuth for TLS servers, clientAuth for TLS clients, codeSigning, emailProtection for S/MIME and timeStamping. When the extension is present, the certificate may only be used for the listed purposes. Public TLS certificates are moving to serverAuth only, so client authentication needs certificates from a private or dedicated CA.; Also called: EKU, extKeyUsage; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
Extended validation (EV)#: The strictest identity check for public TLS certificates, verifying the legal organisation behind a website.; Under the CA/Browser Forum EV Guidelines, the CA checks the organisation's legal existence, address and the requester's authority. The organisation's name appears in the certificate. Browsers no longer show EV specially in the address bar, so most users never see the difference. EV does not make the connection more secure than DV.; Also called: EV, EV certificate; Chapter 11: Proving you own the name: DV, OV, EV and CAA

F

Fingerprint#: A hash of a certificate or public key, used as a short, unique way to identify and compare it.; A SHA-256 fingerprint of a certificate is computed over its DER bytes, so any change produces a different value. People compare fingerprints over a trusted channel to make sure they have the right key, as SSH asks you to do on first connection. Windows shows a SHA-1 'thumbprint'. A fingerprint is not stored inside the certificate; tools compute it.; Also called: thumbprint, certificate hash; Chapter 5: Hashes and fingerprints
Forward secrecy#: A property of key exchange: stealing a server's long-term private key later does not let anyone decrypt past sessions.; With ephemeral key exchange such as ECDHE, each session's keys come from temporary values that are thrown away after use. The certificate's private key only signs the handshake. An attacker who recorded traffic and later steals that key still cannot recover the old session keys. TLS 1.3 provides it for every full handshake; only resumption with a pre-shared key and no fresh key share gives it up. It does not protect recorded traffic against a future quantum computer.; Also called: perfect forward secrecy, PFS; Chapter 15: The TLS 1.3 handshake

G

Grover's algorithm#: A quantum algorithm that speeds up brute-force search, roughly halving the effective strength of symmetric keys and hashes.; Grover's algorithm could search 2^n possibilities in about 2^(n/2) steps, but the steps are slow and hard to run in parallel. It weakens AES and SHA-2 rather than breaking them. Using 256-bit keys keeps a large margin for long-term secrets; NIST's draft transition report considers AES-128 adequate for its lowest post-quantum category.; Also called: Grover; Chapter 26: Post-quantum cryptography

H

Hardware security module (HSM)#: A tamper-resistant device that generates and stores private keys and uses them inside, so the keys cannot be copied out.; An HSM performs signing and decryption internally and exposes only the results. CAs keep their keys in HSMs validated under FIPS 140 or Common Criteria, and publicly trusted code signing keys must be in hardware too. HSMs enforce access rules, such as several administrators being needed for sensitive operations. Cloud providers offer HSMs as a service.; Also called: HSM; Chapter 21: Guarding the keys: HSMs and key ceremonies
Harvest now, decrypt later#: Recording encrypted traffic today in the hope of decrypting it once a large quantum computer can break the key exchange.; If a connection's key exchange uses classical algorithms such as ECDHE, a future quantum computer could compute the session keys from a recording and read the data. Secrets that must stay confidential for many years are therefore at risk now. Post-quantum or hybrid key exchange, such as X25519MLKEM768, closes the gap for new traffic. Signatures are not affected in the same way.; Also called: store now, decrypt later, HNDL; Chapter 26: Post-quantum cryptography
Hash#: The short, fixed-size output of a hash function, such as a 256-bit SHA-256 value. Also called a digest.; A hash acts as a fingerprint of data: the same input always gives the same hash, and any change gives a completely different one. Signatures are made over the hash of a message, and certificate fingerprints are hashes. You cannot turn a hash back into the data, and finding two inputs with the same hash must be infeasible.; Also called: digest, hash value, message digest; Chapter 5: Hashes and fingerprints
Hash function#: A function that turns any data into a short fixed-size value, so that changing the data changes the value unpredictably.; A cryptographic hash function such as SHA-256 must be one-way (you cannot find an input for a given hash) and collision-resistant (you cannot find two inputs with the same hash). SHA-1 and MD5 fail collision resistance and must not be used for signatures. Hashes contain no key, so anyone can compute them; for proof of origin you need a MAC or a signature.; Also called: cryptographic hash function; Chapter 5: Hashes and fingerprints
HMAC#: A message authentication code built from a hash function and a secret key, such as HMAC-SHA256.; HMAC (RFC 2104) lets two parties who share a key check that a message came from one of them and was not changed. Unlike a signature, anyone who can check an HMAC can also create one, so it does not prove which of the two sent it. TLS 1.3 uses HMAC inside HKDF to derive its keys.; Also called: hash-based message authentication code; Chapter 5: Hashes and fingerprints
HSM#: Short for hardware security module: a tamper-resistant device that keeps private keys inside and uses them without ever exporting them.; HSMs protect the most valuable keys, such as CA keys and code signing keys. Operations happen inside the device, access needs authorised people or systems, and many HSMs are validated under FIPS 140. Network HSMs, USB tokens, smart cards and cloud HSM services are all forms of the same idea. See also: hardware security module.; Also called: hardware security module; Chapter 21: Guarding the keys: HSMs and key ceremonies
HSTS#: HTTP Strict Transport Security: a header that tells browsers to use only HTTPS for a site and to refuse certificate warnings.; After a browser sees the Strict-Transport-Security header, it upgrades every request to that site to HTTPS for the stated time, and does not let the user click through certificate errors. Sites can also be built into browsers' preload lists. HSTS protects against being downgraded to plain HTTP on hostile networks.; Also called: HTTP Strict Transport Security, Strict-Transport-Security; Chapter 15: The TLS 1.3 handshake
Hybrid encryption#: Using public-key cryptography to agree or protect a symmetric key, and that fast symmetric key to encrypt the actual data.; Public-key operations are slow and handle little data, while symmetric ciphers are fast. So systems combine them: a key exchange or key encapsulation gives both sides a fresh symmetric key, and AES or ChaCha20 encrypts the bulk data. TLS, S/MIME and almost every other secure protocol work this way.; Chapter 4: Key exchange and hybrid encryption
Hybrid key exchange#: Running a classical and a post-quantum key exchange together and combining both secrets, so the result is safe if either one holds.; X25519MLKEM768, now on by default in major browsers, combines X25519 with ML-KEM-768 in one TLS 1.3 key share. Both shared secrets feed the key schedule. An attacker must break both algorithms to recover the session keys, which protects against a future quantum computer and against an unexpected flaw in the newer algorithm.; Also called: X25519MLKEM768, PQ/T hybrid; Chapter 26: Post-quantum cryptography

I

IDevID#: Initial Device Identifier: the manufacturer-installed, globally unique identity certificate of a device, defined in IEEE 802.1AR.; The manufacturer generates or installs the device's key in protected hardware and issues the IDevID certificate, naming the device, at the factory. It is meant to last for the device's lifetime and is used to prove the device is genuine, typically during onboarding. Owners then usually issue their own LDevID for daily use.; Also called: Initial Device Identifier; Chapter 25: Machines with passports: device identity
Intermediate certificate#: A CA certificate between the root and the server's certificate. The root signs the intermediate, and the intermediate signs the server certificates.; Intermediates let a root CA's key stay offline while day-to-day issuance happens with an intermediate key. A server must send its intermediates along with its own certificate, because clients usually have only roots in their trust stores. A missing intermediate is one of the most common causes of certificate errors outside browsers.; Also called: intermediate CA, subordinate CA, issuing CA; Chapter 13: Certificate chains and path validation
Issuer#: The CA that signed a certificate, named in the certificate's issuer field.; The issuer field holds the distinguished name of the signing CA. To validate a certificate, a client finds a CA certificate whose subject matches that issuer name, ideally whose key identifier matches too, and checks the signature with its public key. For a self-signed certificate, issuer and subject are the same.; Also called: issuing CA; Chapter 8: Anatomy of an X.509 certificate

K

Key#: A secret or public value that controls what a cryptographic algorithm does, such as which ciphertext encryption produces.; In symmetric cryptography one secret key both encrypts and decrypts, so everyone who holds it must keep it secret. In public-key cryptography keys come in pairs: a private key you keep and a public key you share. A key is really just a large number; its security comes from being random and long enough that guessing is hopeless.; Also called: cryptographic key; Chapter 1: Symmetric encryption: one shared key
Key ceremony#: A scripted, witnessed and recorded procedure for creating or using a CA's most important keys, such as a root key.; In a key ceremony, several people with separate roles follow a written script in a secure room: they initialise the HSM, generate the key, sign certificates and back up the key in parts that no single person can use. Witnesses and video record every step for auditors. Public CAs must hold ceremonies for root keys; private CAs should too.; Also called: root key ceremony; Chapter 21: Guarding the keys: HSMs and key ceremonies
Key compromise#: When a private key has been, or may have been, exposed to someone who should not have it.; If a certificate's private key leaks, anyone with it can impersonate the certificate's subject. The response is to replace the key, issue a new certificate and ask the CA to revoke the old one, giving keyCompromise as the reason. Public CAs must revoke within a short, fixed deadline. Because many clients check revocation poorly, short certificate lifetimes limit the damage.; Also called: compromised key; Chapter 16: Taking it back: CRLs, OCSP and stapling
Key distribution#: Getting the right keys to the right people safely. With shared secret keys, it is the hard problem that public-key cryptography solves.; Symmetric encryption needs both sides to hold the same secret key, but sending that key over the network exposes it, and meeting in person does not scale: n people need n(n-1)/2 keys. Key distribution centres, key exchange and certificates are the different answers. Public-key cryptography turns the problem into a simpler one: making sure a public key really belongs to its owner.; Also called: key distribution problem; Chapter 2: The key-distribution problem
Key distribution centre (KDC)#: A trusted server that shares a secret key with every user and hands out session keys so two users can talk.; Each user shares one long-term key with the KDC instead of one key with every other user. When two users want to talk, the KDC creates a session key and gives it to both, protected under their long-term keys. Kerberos works this way. The KDC must be online and trusted completely: whoever controls it can read everything.; Also called: KDC, key distribution center; Chapter 2: The key-distribution problem
Key encapsulation mechanism (KEM)#: A way to agree a shared secret: one side encapsulates a fresh secret to a public key, and only the private key recovers it.; A KEM has three operations: generate a key pair, encapsulate (produce a shared secret and a ciphertext from a public key) and decapsulate (recover the secret from the ciphertext with the private key). ML-KEM, standardised in FIPS 203, is a post-quantum KEM. In TLS it plays the role ECDH plays in classical key exchange.; Also called: KEM; Chapter 26: Post-quantum cryptography
Key escrow#: Keeping a protected copy of a key with a trusted party so that it can be recovered, for example to read old encrypted data.; Escrow makes sense for encryption keys, such as S/MIME or file encryption keys, because losing them means losing data. It must not be used for signing keys: a signature is only meaningful if nobody else could have made it. Escrowed keys need strong protection and controlled recovery, typically requiring several people.; Also called: key recovery, key archival; Chapter 21: Guarding the keys: HSMs and key ceremonies
Key exchange#: A protocol by which two parties agree a shared secret over an open network, so they can then use fast symmetric encryption.; Diffie-Hellman and its elliptic-curve form ECDHE let both sides compute the same secret from values exchanged in public. A key encapsulation mechanism such as ML-KEM achieves the same with a different method. Key exchange alone does not prove who is on the other end; TLS adds certificates and signatures for that.; Also called: key agreement, key establishment; Chapter 4: Key exchange and hybrid encryption
Key pair#: A matching public key and private key. What one key does, only the other can check or undo.; You generate a key pair yourself, keep the private key secret and share the public key freely. Others use your public key to verify your signatures or to agree keys with you. Knowing the public key does not reveal the private key. A certificate binds the public half to your name; the private half never goes into the certificate.; Also called: asymmetric key pair; Chapter 3: Key pairs: public and private keys
Key substitution#: An attack in which someone swaps a public key for their own, so you encrypt to them or trust their signatures by mistake.; The cryptography is not broken: the victim simply uses the wrong key. A man-in-the-middle can substitute keys on both sides of a conversation and read everything. The defence is to know whose key you hold, by checking its fingerprint over a trusted channel or by trusting a certificate from a CA you already trust.; Also called: key swap; Chapter 7: Whose key is it? Binding identity to keys
Key Usage#: A certificate extension that limits the cryptographic operations the key may be used for, such as digital signatures or signing certificates.; Key Usage bits include digitalSignature, keyEncipherment, keyAgreement, keyCertSign and cRLSign. A CA certificate needs keyCertSign; a TLS 1.3 server certificate needs digitalSignature. Extended Key Usage then says for which application, such as server authentication. Clients reject a certificate whose key is used for an operation its Key Usage does not allow.; Also called: KU, keyUsage; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
Keystore#: A file or system store that holds private keys with their certificate chains, and often trusted CA certificates, for an application.; Java applications use keystores in PKCS #12 or the older JKS format, managed with keytool. Each entry has an alias: a PrivateKeyEntry holds a key and its chain, a trustedCertEntry holds a CA certificate to trust. Windows has certificate stores, and macOS has keychains, which play the same role. A keystore used only for trusted CAs is often called a truststore.; Also called: truststore, JKS, certificate store; Read the chapter

L

LDevID#: Locally significant Device Identifier: a device certificate issued by the owner's own CA, defined in IEEE 802.1AR.; After checking a device's factory identity (IDevID) during onboarding, the owner's CA issues an LDevID, often for a new key pair also kept in the device's secure hardware. The device uses it day to day, for example for 802.1X network access or mutual TLS. The owner can renew and revoke it, and it need not reveal the factory serial number.; Also called: Locally Significant Device Identifier; Chapter 25: Machines with passports: device identity
Leaf certificate#: The certificate at the bottom of a chain, issued to a server, client or device rather than to a CA.; A leaf, or end-entity, certificate has CA:FALSE in Basic Constraints and cannot sign other certificates. It holds the names a client checks, such as the website's DNS names in the subject alternative name. The server sends it first in the chain, followed by the intermediates.; Also called: end-entity certificate, server certificate; Chapter 13: Certificate chains and path validation

M

Man-in-the-middle#: An attacker who sits between two parties, relays their messages and can read or change them, often by swapping keys.; If you cannot be sure a public key really belongs to the other party, an attacker in the middle can give each side its own key instead and decrypt everything in between. Certificates, checked against a trusted root and the right name, stop this. Clicking through certificate warnings or turning off verification brings the risk back.; Also called: MITM, machine-in-the-middle, on-path attacker; Chapter 7: Whose key is it? Binding identity to keys
Merkle tree#: A tree of hashes in which each node hashes its children, so one root hash commits to every entry below it.; Certificate Transparency logs are Merkle trees. With a few hashes, a log can prove that a given certificate is included, and that a newer version of the log still contains everything from an older one. Changing or removing any entry would change the root hash, so it would be detected.; Also called: hash tree; Chapter 17: Certificate Transparency
Message authentication code (MAC)#: A short value computed from a message and a shared secret key, which proves the message is unchanged and came from a key holder.; Both parties share the key, so either can compute and check the MAC. That proves integrity and origin between the two of them, but unlike a digital signature it cannot prove to a third party which one sent the message. HMAC and the authentication tags in AES-GCM are MACs.; Also called: MAC; Chapter 5: Hashes and fingerprints
ML-DSA#: Module-Lattice-Based Digital Signature Algorithm: a post-quantum signature standard (FIPS 204), derived from CRYSTALS-Dilithium.; ML-DSA is expected to become the general replacement for RSA and ECDSA signatures once quantum computers are a risk. It is fast, but its public keys and signatures are large: ML-DSA-44 has 1,312-byte public keys and 2,420-byte signatures. Its use in X.509 certificates is standardised; public web certificates do not use it yet.; Also called: FIPS 204, Dilithium; Chapter 26: Post-quantum cryptography
ML-KEM#: Module-Lattice-Based Key-Encapsulation Mechanism: the post-quantum key agreement standard (FIPS 203), derived from CRYSTALS-Kyber.; ML-KEM lets two parties agree a shared secret that a quantum computer should not be able to recover. ML-KEM-768 has a 1,184-byte encapsulation key and a 1,088-byte ciphertext. Browsers use it in the hybrid TLS group X25519MLKEM768, together with classical X25519, to protect traffic against harvest now, decrypt later.; Also called: FIPS 203, Kyber; Chapter 26: Post-quantum cryptography
Mode of operation#: The rule for using a block cipher on messages longer than one block, such as GCM, CTR or CBC.; A block cipher like AES encrypts only 16 bytes at a time. A mode says how to chain blocks together, usually with a nonce or initialisation vector, so that equal blocks do not produce equal ciphertext. GCM also authenticates the data. ECB, which encrypts each block separately, leaks patterns and should not be used.; Also called: block cipher mode, GCM, CBC, CTR; Chapter 1: Symmetric encryption: one shared key
Multi-perspective issuance corroboration (MPIC)#: A CA checking domain validation and CAA from several network locations, so one hijacked network path cannot fool it.; An attacker who controls routing near the CA could answer a validation challenge for someone else's domain. With MPIC, the CA repeats the check from several distant vantage points and issues only if enough of them agree. The CA/Browser Forum requires it for publicly trusted TLS certificates.; Also called: MPIC, multi-perspective validation; Chapter 11: Proving you own the name: DV, OV, EV and CAA
Mutual TLS (mTLS)#: TLS in which the client also presents a certificate and proves its private key, so both sides are authenticated.; The server sends a CertificateRequest; the client answers with its certificate and a CertificateVerify signature. The server checks the client's chain against its own trust anchors for clients, usually a private CA. mTLS is common between services, in service meshes, for APIs between organisations and for devices. It authenticates the client; deciding what the client may do is a separate step.; Also called: mTLS, client certificate authentication, two-way TLS; Chapter 23: Both sides show ID: mutual TLS

N

Name Constraints#: A CA certificate extension that limits which names its certificates may contain, such as only names under example.com.; Name Constraints list permitted and excluded name spaces for DNS names, email addresses, IP ranges and directory names. Clients reject a certificate below that CA whose names fall outside the limits. It is useful for private CAs and for intermediates given to a partner, because a compromised or careless CA cannot then issue for other domains.; Also called: nameConstraints; Chapter 22: A CA of your own: private two-tier PKI
Nonce#: A number used once: a random or counter value that makes each message, request or handshake unique.; Nonces stop replays and keep encryption safe. AES-GCM needs a nonce that is never reused with the same key. TLS handshakes include random values so that signatures cannot be replayed on another connection. Timestamp requests and device attestation include a nonce so that an old answer cannot be passed off as a fresh one.; Also called: number used once; Chapter 1: Symmetric encryption: one shared key

O

OCSP#: Online Certificate Status Protocol: a way to ask a CA's server whether one specific certificate has been revoked.; The client sends a certificate's serial number to the OCSP responder named in the certificate and gets back a signed answer: good, revoked or unknown. It is fresher than a CRL, but slow, a privacy leak (the CA learns which sites you visit) and usually soft-fail. OCSP became optional for publicly trusted TLS CAs, and some, such as Let's Encrypt, have shut it down.; Also called: Online Certificate Status Protocol; Chapter 16: Taking it back: CRLs, OCSP and stapling
OCSP stapling#: The server fetches a signed OCSP answer about its own certificate and sends it in the handshake, so clients need not ask the CA.; Stapling removes OCSP's extra round trip and privacy leak: the CA never sees which clients connect. The stapled answer is signed by the CA, so the server cannot fake it, and it is only valid for a short time. Stapling only works if the certificate has an OCSP URL, which is becoming rare as CAs move to CRLs.; Also called: stapling, TLS Certificate Status Request; Chapter 16: Taking it back: CRLs, OCSP and stapling
Offline root CA#: A root CA whose private key is kept on a device that is never connected to a network and is used only in key ceremonies.; Because a root key cannot easily be replaced, it is kept offline, usually in an HSM in a safe, and used only occasionally to sign intermediate CA certificates and CRLs. Day-to-day issuance happens with an online intermediate. If the intermediate is compromised, the root can revoke it and sign a new one.; Also called: offline root; Chapter 22: A CA of your own: private two-tier PKI
Organization validation (OV)#: A TLS certificate check that confirms the organisation behind a domain, in addition to domain control.; For OV certificates the CA verifies the organisation's name and location from official records and includes them in the certificate subject. Browsers do not show the difference to users, so OV mainly matters for policies and for people who inspect certificates. It adds no cryptographic strength compared with DV.; Also called: OV, organisation validation; Chapter 11: Proving you own the name: DV, OV, EV and CAA
Out-of-band#: Through a separate channel from the one you are trying to secure, such as checking a key's fingerprint by phone.; If you receive a public key over the network, an attacker could have swapped it. Comparing its fingerprint over another channel you already trust, in person, by phone or on a printed letter, detects the swap. Certificates automate this: a CA you already trust vouches for the key instead.; Also called: out-of-band verification, side channel check; Chapter 2: The key-distribution problem

P

Path validation#: The checks a client runs on a certificate chain: signatures, validity dates, CA flags, constraints, names and revocation, up to a trusted root.; RFC 5280 section 6 defines the algorithm. The client builds a path from the leaf to a trust anchor, then checks each certificate: signed by the next, within its dates, issued by a CA with CA:TRUE and the right key usage, within any path length and name constraints, and not revoked if it checks. Hostname checking against the SAN is an extra step.; Also called: certificate path validation, chain validation; Chapter 13: Certificate chains and path validation
PEM#: A text format for certificates and keys: Base64-encoded DER between lines such as -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.; PEM is what OpenSSL, nginx, Apache and most Linux software use. The label on the BEGIN line says what is inside: CERTIFICATE, CERTIFICATE REQUEST, PRIVATE KEY and so on (RFC 7468). A PEM file can hold several objects one after another, such as a server certificate followed by its intermediates. Extensions vary: .pem, .crt, .cer and .key.; Also called: Privacy-Enhanced Mail format, Base64 certificate; Read the chapter
PKCS #12#: A password-protected file format that bundles a private key with its certificate and chain, with the extension .p12 or .pfx.; PKCS #12 (RFC 7292) is the usual way to move a complete identity between systems: Windows and IIS import and export it, Java uses it as its default keystore type, and cloud services accept it. Because it contains the private key, treat the file like the key itself. PFX is an older name for the same format.; Also called: PFX, P12; Read the chapter
PKCS #7#: A container format, now called CMS, used for signed and encrypted data and for bundles of certificates without a private key (.p7b).; PKCS #7, standardised further as the Cryptographic Message Syntax (RFC 5652), carries signatures in Authenticode, S/MIME and timestamps. A .p7b file is a certificates-only PKCS #7 structure: a convenient way to ship a chain. OpenSSL converts it to PEM with 'openssl pkcs7 -print_certs'.; Also called: P7B, CMS, Cryptographic Message Syntax; Read the chapter
PKCS #8#: The standard format for a single private key, optionally encrypted, shown in PEM as BEGIN PRIVATE KEY or BEGIN ENCRYPTED PRIVATE KEY.; PKCS #8 (RFC 5208, extended by RFC 5958) holds any kind of private key with an algorithm identifier, which is why it replaced the older algorithm-specific formats such as BEGIN RSA PRIVATE KEY. OpenSSL 3 writes PKCS #8 by default, and 'openssl pkey' converts between the formats.; Also called: PrivateKeyInfo, OneAsymmetricKey; Read the chapter
PKI#: Short for public key infrastructure: everything needed to issue, trust, check and revoke certificates that bind public keys to identities.; PKI covers certificate authorities, registration, trust stores, revocation services, standards such as X.509 and ACME, and the policies and audits that hold them together. The web PKI is the public one that browsers use; organisations also run private PKIs for internal servers, devices and mutual TLS. See also: public key infrastructure.; Also called: public key infrastructure; Chapter 7: Whose key is it? Binding identity to keys
Plaintext#: The readable data before encryption or after decryption.; Plaintext can be text, an image or any other data. Encryption turns it into ciphertext. An attacker who sees only ciphertext should learn nothing about the plaintext except, usually, its length. In TLS, the plaintext is the HTTP request or response being protected.; Also called: cleartext; Chapter 1: Symmetric encryption: one shared key
Post-quantum cryptography (PQC)#: Public-key algorithms designed to stay secure even against large quantum computers, running on ordinary hardware.; Shor's algorithm would break RSA and elliptic-curve cryptography on a large quantum computer. Post-quantum algorithms rest on other problems, such as module lattices (ML-KEM, ML-DSA) or hash functions (SLH-DSA), standardised by NIST. Key exchange in browsers already uses a hybrid of X25519 and ML-KEM. Certificates and other signatures are next.; Also called: PQC, quantum-safe cryptography, quantum-resistant cryptography; Chapter 26: Post-quantum cryptography
Pre-shared key (PSK)#: A secret key that both parties received in advance, outside the protocol that uses it.; Pre-shared keys are simple: no certificates, no key exchange. But every pair of parties needs its own key, distributed safely, and a leaked key exposes all traffic that used it. TLS 1.3 also uses the term for session resumption, where a key from an earlier connection lets a client reconnect faster.; Also called: PSK, shared secret; Chapter 2: The key-distribution problem
Precertificate#: A copy of a certificate with a poison extension that a CA logs in Certificate Transparency before issuing the real certificate.; To embed SCTs in a certificate, the CA first creates a precertificate, which a special critical extension makes unusable as a real certificate, and submits it to CT logs. The logs return SCTs, which the CA puts into the final certificate. Monitors see the precertificate in the logs even if the final certificate is never used.; Also called: precert; Chapter 17: Certificate Transparency
Private CA#: A certificate authority run by an organisation for its own systems, trusted only where it has been added to trust stores.; Private CAs issue certificates for internal servers, mutual TLS, devices, VPNs and Wi-Fi. They are not in browsers' trust stores, so every client that should trust them needs their root installed. A good design has an offline root and online issuing CAs, documented policies, protected keys and automation. Public certificates are becoming server-only, so client authentication increasingly needs a private CA.; Also called: internal CA, enterprise CA, private PKI; Chapter 22: A CA of your own: private two-tier PKI
Private key#: The secret half of a key pair. Whoever holds it can sign as you or decrypt messages meant for you, so never share it.; The private key stays on the server, device or HSM where it was generated. It never goes into a certificate or a CSR. It makes signatures that others verify with the public key, and it decrypts or decapsulates what others sent to the public key. If it leaks, replace it and have the certificate revoked.; Also called: secret key (asymmetric); Chapter 3: Key pairs: public and private keys
Proof of possession#: Showing that you hold the private key for a public key, usually by signing something with it, as a CSR does.; A CSR is signed with the private key that matches the public key inside it, and the CA checks that signature before issuing. Without this check, someone could request a certificate for another party's public key. TLS handshakes and device attestation also rely on proof of possession: the certificate is public, the fresh signature is the proof.; Also called: POP, proof-of-possession; Chapter 10: Asking for a certificate: key generation and the CSR
Public key#: The shareable half of a key pair. Others use it to check your signatures or send you secrets only your private key opens.; A public key can be published freely; knowing it does not reveal the private key. The hard part is knowing that a public key really belongs to the person or server you think: that is the job of a certificate, in which a CA binds the public key to a name. Certificates contain the public key in their SubjectPublicKeyInfo field.; Chapter 3: Key pairs: public and private keys
Public key infrastructure (PKI)#: The people, policies, systems and standards that create, distribute, check and revoke certificates binding public keys to identities.; A PKI includes certificate authorities, registration processes, trust stores, revocation services, the formats and protocols (X.509, TLS, ACME), and the rules that hold it together (CA/Browser Forum requirements, root programs, audits). The web PKI is the public one browsers use; organisations also run private PKIs for internal systems and devices.; Also called: PKI; Chapter 7: Whose key is it? Binding identity to keys

Q

Qualified electronic signature (QES)#: Under EU eIDAS, an advanced electronic signature made with a qualified signature device and a qualified certificate; legally equal to handwriting.; A QES needs a qualified certificate from a qualified trust service provider on an EU trusted list, and a qualified signature creation device such as a smart card or a certified remote signing service. eIDAS gives it the equivalent legal effect of a handwritten signature, and it is recognised in every EU member state. A scanned handwritten signature is not a QES.; Also called: QES; Chapter 24: Signed and sealed: code and document signing

R

Registration authority (RA)#: The part of a PKI that checks who is asking for a certificate before the CA issues it.; A registration authority verifies identities, approves or rejects requests and passes approved ones to the CA for signing. It can be a team, a separate system or an automated process, such as ACME validation. Separating the RA from the CA lets organisations delegate checks without giving out access to the CA's key.; Also called: RA; Chapter 22: A CA of your own: private two-tier PKI
Relying party#: Whoever checks a certificate and relies on it to decide whether to trust a connection, signature or device.; A browser checking a website, a server checking a client certificate and an operating system checking a signed driver are all relying parties. They decide which roots to trust, which checks to run and what to do when a check fails. CA policies and root program rules exist to protect relying parties.; Also called: RP, verifier; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Revocation#: A CA cancelling a certificate before its expiry date, for example because its private key leaked or it was issued by mistake.; The CA publishes the revocation in a CRL and, if it runs one, an OCSP responder. Clients only learn about it if they check, and most browsers check softly or rely on their own pushed lists. That is why short certificate lifetimes increasingly do the job revocation was meant to do. For publicly trusted certificates, revocation is permanent.; Also called: certificate revocation; Chapter 16: Taking it back: CRLs, OCSP and stapling
Root certificate#: A CA certificate at the top of a chain, trusted because it is already in a trust store, not because it is self-signed.; A root certificate is usually self-signed, but anyone can make a self-signed certificate. A root is trusted only because a browser, operating system or administrator put it in a trust store after checking the CA. Root keys are kept offline and sign intermediate CAs. Removing a root from trust stores distrusts every certificate below it.; Also called: root CA, trust anchor; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Root program#: A browser's or operating system's process for deciding which CAs' roots it trusts, with rules those CAs must follow.; Chrome, Mozilla, Apple and Microsoft each run a root program. They review CAs before inclusion, require audits and compliance with the CA/Browser Forum requirements plus their own policies, and can distrust a CA that breaks the rules. Their policies drive many industry changes, such as shorter lifetimes and server-only TLS hierarchies.; Also called: root store program, root store policy; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
RSA#: The oldest widely used public-key algorithm, for signatures and encryption, based on the difficulty of factoring large numbers.; RSA keys of 2048 or 3072 bits are common in certificates. RSA can sign (for example with RSA-PSS) and encrypt, but TLS 1.3 uses it only for signatures. Its keys and signatures are larger than elliptic-curve ones for the same strength. A large quantum computer running Shor's algorithm would break it.; Also called: Rivest-Shamir-Adleman; Chapter 3: Key pairs: public and private keys

S

S/MIME#: The standard for signing and encrypting email with certificates, defined in RFC 8551.; S/MIME signs a message with the sender's private key and can encrypt it to the recipient's public key, using CMS. The certificate names the email address and carries the email protection purpose. Signing does not encrypt: encryption needs the recipient's certificate. Publicly trusted S/MIME certificates follow their own CA/Browser Forum Baseline Requirements.; Also called: Secure/Multipurpose Internet Mail Extensions, email certificate; Chapter 24: Signed and sealed: code and document signing
SCT (signed certificate timestamp)#: A CT log's signed promise to add a certificate to its log, which browsers require before trusting a public TLS certificate.; When a CA submits a certificate or precertificate to a Certificate Transparency log, the log returns an SCT. The SCT is delivered to clients embedded in the certificate, in a TLS extension or in a stapled OCSP response. Chrome, Apple and Firefox require SCTs from several independent logs. A certificate without enough valid SCTs is rejected. The SCT is a promise; an inclusion proof shows the entry really is in the log.; Also called: signed certificate timestamp; Chapter 17: Certificate Transparency
Secret key#: The single shared key in symmetric encryption, which both sides must hold and nobody else may know.; With a secret key, the same value encrypts and decrypts, so anyone who has it can read and forge messages. Getting it to the other side safely is the key-distribution problem. In TLS, a fresh secret session key is agreed for every connection through key exchange, and is thrown away afterwards.; Also called: symmetric key, shared key; Chapter 1: Symmetric encryption: one shared key
Secure element#: A tamper-resistant chip that generates and stores keys and performs cryptography inside, so the keys cannot be read out.; Secure elements sit in phones, payment cards, passports and many IoT devices. A device's identity key is generated inside one at the factory and never leaves it; the chip signs challenges on request. That makes the device's certificate impossible to clone onto other hardware without physically attacking the chip.; Also called: SE, secure chip; Chapter 25: Machines with passports: device identity
Self-signed certificate#: A certificate signed with its own private key, so issuer and subject match. It is trusted only if deliberately added to a trust store.; Root CA certificates are self-signed, and so are many test and device certificates. Self-signing proves nothing about identity: anyone can create one for any name. A self-signed certificate becomes trustworthy only when someone deliberately puts it in a trust store after checking it. Clients otherwise report errors such as 'self-signed certificate in certificate chain'.; Also called: self-signed; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Separation of duties#: Splitting sensitive tasks so that no single person can complete them alone, such as using or restoring a CA key.; In a PKI, different people hold different roles: security officers, operators, auditors. HSMs can require several smart cards to activate a key, and key backups are split into shares held by different people. Misuse then needs collusion, and every action is witnessed and logged. Auditors check that CAs enforce it.; Also called: dual control, M of N control; Chapter 21: Guarding the keys: HSMs and key ceremonies
Serial number#: A number, unique per CA, that identifies a certificate. Revocation lists and OCSP refer to certificates by it.; Every certificate has a serial number chosen by its issuer. Publicly trusted CAs must use at least 64 bits of randomness in it, which makes attacks on the signature harder. CRLs and OCSP responses list serial numbers, so the issuer name plus the serial number identify a certificate uniquely.; Also called: certificate serial number; Chapter 8: Anatomy of an X.509 certificate
Server Name Indication (SNI)#: A TLS extension in which the client says which hostname it wants, so a server hosting many sites can pick the right certificate.; SNI travels in the ClientHello. Without it, a server with many sites on one IP address can only send a default certificate, which often fails the name check. Tools need it too: 'openssl s_client' takes '-servername'. SNI is sent unencrypted unless Encrypted Client Hello is used, so the hostname is visible on the network.; Also called: SNI; Chapter 15: The TLS 1.3 handshake
Service mesh#: An infrastructure layer that handles traffic between services, typically giving each service a certificate and using mutual TLS for every call.; A mesh runs a proxy next to each service, or on each node, and a control plane with its own CA. The proxies request short-lived certificates, renew them automatically and encrypt and authenticate all service-to-service traffic, without changes to the services. Istio and Linkerd are examples; many use SPIFFE IDs.; Also called: mesh; Chapter 23: Both sides show ID: mutual TLS
Session key#: A symmetric key that protects one connection or session, then is thrown away.; In TLS 1.3, client and server derive session keys from the shared secret of the ephemeral key exchange, and use them with an AEAD cipher to encrypt the traffic. The keys are never sent over the network and are not the certificate's key. Because they are discarded, stealing a server key later does not expose old sessions.; Also called: traffic key, session keys; Chapter 4: Key exchange and hybrid encryption
SHA-256#: The most widely used hash function today, from the SHA-2 family, producing a 256-bit value.; SHA-256 (FIPS 180-4) is used in certificate signatures, fingerprints, Certificate Transparency, code signing and much more. No practical collision or preimage attack is known. Its predecessor SHA-1 is broken for collisions and no longer allowed in new publicly trusted certificates. SHA-384 and SHA-512 are larger members of the same family.; Also called: SHA-2; Chapter 5: Hashes and fingerprints
Shor's algorithm#: A quantum algorithm that could factor large numbers and compute discrete logarithms, breaking RSA and elliptic-curve cryptography.; On a large, error-corrected quantum computer, Shor's algorithm would recover private keys from public keys for RSA, Diffie-Hellman, ECDH, ECDSA and EdDSA. No machine large enough exists today, and nobody knows when one will. Because of harvest now, decrypt later, key exchange is already moving to post-quantum algorithms.; Also called: Shor; Chapter 26: Post-quantum cryptography
Short-lived certificate#: A certificate valid for only days or hours, so that a stolen key stops working soon even if revocation is never checked.; Short lifetimes shrink the window in which a leaked key or mis-issued certificate can be abused, and they make automation unavoidable. Under the CA/Browser Forum rules, very short-lived certificates may even leave out revocation information. Service meshes and Sigstore issue certificates valid for minutes or hours.; Chapter 20: ACME and the 47-day schedule
Sigstore#: An open-source signing service that issues short-lived certificates for an OpenID Connect identity and records signatures in a public transparency log.; With Sigstore, a developer or CI pipeline signs without managing a long-lived key. Its CA, Fulcio, certifies a fresh key for the signer's identity for a few minutes; the transparency log, Rekor, records the signature with a signed timestamp. Verifiers check the expected identity, the log entry and that signing happened while the certificate was valid. The cosign tool uses it.; Also called: cosign, Fulcio, Rekor; Chapter 24: Signed and sealed: code and document signing
SLH-DSA#: Stateless Hash-Based Digital Signature Algorithm: a post-quantum signature standard (FIPS 205) whose security rests only on hash functions.; SLH-DSA, derived from SPHINCS+, is a conservative choice because hash functions are well understood. Its public keys are tiny, 32 bytes at the lowest level, but its signatures are large, from about 8 to 50 kilobytes depending on the parameter set, and signing is slow. It suits long-lived roots and firmware signing more than busy TLS servers.; Also called: FIPS 205, SPHINCS+; Chapter 26: Post-quantum cryptography
SNI#: Short for Server Name Indication: the hostname a TLS client sends in its first message, so the server picks the right certificate.; Without SNI, a server hosting several sites sends a default certificate, and the client reports a name mismatch. Browsers always send it; with command-line tools you may have to ask, as with 'openssl s_client -servername'. SNI is visible to network observers unless Encrypted Client Hello is in use. See also: Server Name Indication.; Also called: Server Name Indication; Chapter 15: The TLS 1.3 handshake
Soft-fail#: When a client cannot get a revocation answer, it accepts the certificate anyway instead of failing the connection.; Browsers soft-fail on OCSP and CRL fetches because failing hard would break sites every time a CA's server is slow or blocked. The cost is that an attacker who can block the check may get a revoked certificate accepted. Browser-pushed lists such as CRLite and CRLSets, and short lifetimes, are the industry's answer.; Also called: soft fail; Chapter 16: Taking it back: CRLs, OCSP and stapling
SPIFFE#: Secure Production Identity Framework for Everyone: a standard for giving software workloads identities, usually as short-lived X.509 certificates.; A SPIFFE ID is a URI such as spiffe://example.org/payments/api. In an X.509-SVID it sits in the subject alternative name as the one URI. Workloads get their SVIDs through the local Workload API and use them for mutual TLS. SPIRE is the reference implementation; service meshes such as Istio use the same ID format.; Also called: SPIRE, SPIFFE ID; Chapter 23: Both sides show ID: mutual TLS
SPKI (SubjectPublicKeyInfo)#: The certificate field that holds the subject's public key and its algorithm. Its hash identifies a key independently of any certificate.; Every certificate and CSR contains a SubjectPublicKeyInfo structure; PEM files labelled PUBLIC KEY contain one on its own. Hashing the SPKI gives a value that stays the same when a certificate is renewed with the same key, which is why pinning and key-matching checks use it. 'openssl x509 -pubkey' extracts it.; Also called: SubjectPublicKeyInfo, SPKI hash; Chapter 8: Anatomy of an X.509 certificate
SSH certificate#: An OpenSSH key signed by an SSH certificate authority, with a key ID, allowed user or host names and a validity period.; OpenSSH certificates use a simple format of their own, not X.509. Servers trust a user CA key instead of listing every user key, and clients trust a host CA instead of accepting fingerprints on first use. Short-lived user certificates, valid for hours, replace long-lived keys copied to every server.; Also called: OpenSSH certificate; Chapter 25: Machines with passports: device identity
Stream cipher#: A symmetric cipher that produces a stream of key-dependent bytes and combines it with the data, such as ChaCha20.; A stream cipher encrypts data of any length without splitting it into blocks. Its security depends on never reusing the same key and nonce: two messages encrypted with the same stream can be combined to reveal information. ChaCha20 with Poly1305 is the stream-cipher choice in TLS 1.3, popular on devices without AES hardware.; Also called: ChaCha20; Chapter 1: Symmetric encryption: one shared key
Subject#: The certificate field naming who or what the certificate was issued to, as a distinguished name.; The subject holds attributes such as the Common Name, organisation and country. For TLS, the names that matter for hostname checks are in the subject alternative name extension, not in the subject. Chain building matches each certificate's issuer with the subject of the CA certificate above it.; Also called: subject DN; Chapter 8: Anatomy of an X.509 certificate
Subject Alternative Name (SAN)#: The certificate extension that lists the DNS names, IP addresses, email addresses or URIs the certificate is valid for.; Clients check the hostname they connected to against the DNS names (or IP addresses) in the SAN. Browsers and Go ignore the Common Name entirely; some libraries fall back to it only when the SAN holds no DNS name at all. One certificate can list many names. A wildcard entry such as *.example.com covers exactly one label and never the bare domain.; Also called: SAN, subjectAltName; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
Subject Key Identifier (SKI)#: A certificate extension with an identifier, usually a hash, of the certificate's own public key.; In a CA certificate, the Subject Key Identifier is what the Authority Key Identifier of the certificates it signs points to. Path-building software matches the two to find the right issuer, especially when a CA name is shared by several certificates after cross-signing or key rollover.; Also called: SKI; Chapter 13: Certificate chains and path validation
SVID#: SPIFFE Verifiable Identity Document: the certificate or token that proves a workload's SPIFFE ID.; An X.509-SVID is a short-lived certificate whose subject alternative name contains exactly one URI, the workload's SPIFFE ID. Leaf SVIDs have CA:FALSE, and if they carry an extended key usage it includes both serverAuth and clientAuth, because workloads act as both. There is also a JWT form for cases where TLS is not possible.; Also called: X.509-SVID, SPIFFE Verifiable Identity Document; Chapter 23: Both sides show ID: mutual TLS
Symmetric encryption#: Encryption in which the same secret key both encrypts and decrypts, such as AES.; Symmetric ciphers are fast and handle any amount of data, so they protect almost all encrypted traffic and storage. Their weakness is key distribution: both sides need the same key, and sending it safely is hard. Public-key cryptography solves that, and TLS combines both: key exchange agrees a fresh symmetric key, and AES or ChaCha20 encrypts the data.; Also called: secret-key encryption, shared-key encryption; Chapter 1: Symmetric encryption: one shared key

T

Timestamp#: A token, signed by a timestamping authority, proving that some data, such as a signature, existed at a given time.; An RFC 3161 time-stamp token contains a hash of the data, the time, a serial number and the authority's signature. Attached to a code or document signature, it lets verifiers check the signing certificate at that time instead of today, so the signature stays valid after the certificate expires. The signer cannot change the time.; Also called: time-stamp token, trusted timestamp; Chapter 24: Signed and sealed: code and document signing
Timestamping#: Adding a trusted timestamp to a signature, so the signature remains verifiable after its certificate expires.; Right after signing, the signer sends a hash of its signature to a timestamping authority, which returns a signed token with the current time. Verifiers then check the certificate at that time. Without timestamping, code and document signatures effectively expire with their certificates. SignTool's /tr option and 'openssl ts' both use the RFC 3161 protocol.; Also called: time-stamping, trusted timestamping; Chapter 24: Signed and sealed: code and document signing
Timestamping authority (TSA)#: A trusted service that signs timestamps, using a key and certificate reserved only for that purpose.; A TSA receives a hash, adds an accurate time and signs the result. Its certificate must carry only the timeStamping extended key usage, marked critical. TSAs used for public code signing follow the CA/Browser Forum's code signing rules; under eIDAS, qualified TSAs issue qualified electronic time stamps with a legal presumption of accuracy.; Also called: TSA, time-stamp authority; Chapter 24: Signed and sealed: code and document signing
TLS#: Transport Layer Security: the protocol that encrypts and authenticates connections such as HTTPS, using certificates to prove the server's identity.; TLS runs a handshake to agree session keys and authenticate the server, optionally the client too, then protects all data with authenticated encryption. TLS 1.3 is the current version and TLS 1.2 is still common; SSL and TLS 1.0 and 1.1 are retired. HTTPS, secure email, VPNs and most APIs are built on it.; Also called: Transport Layer Security, SSL; Chapter 15: The TLS 1.3 handshake
TLS handshake#: The opening exchange of a TLS connection, in which client and server agree keys and the server proves its identity.; In TLS 1.3 the client sends a ClientHello with key shares; the server answers with its own share, its certificate chain, a CertificateVerify signature and Finished. Both derive session keys from the ephemeral key exchange. The certificate key only signs; it never encrypts the session keys. Most certificate errors are reported during the handshake.; Also called: handshake; Chapter 15: The TLS 1.3 handshake
TLS inspection#: A proxy or firewall that decrypts TLS traffic by presenting its own certificates, signed by a CA installed on the organisation's devices.; Inspection devices end the TLS connection from the client, inspect the traffic and open a new connection to the server. Clients accept the proxy's certificates only if its CA is in their trust store. Tools with their own trust stores, such as Java, Python, Node.js or Git, then fail with errors like 'unable to get local issuer certificate' until that CA is added to them.; Also called: TLS interception, SSL inspection, HTTPS inspection; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
TPM#: Trusted Platform Module: a security chip in most PCs and many servers that stores keys and can prove the machine's identity and state.; A TPM generates keys inside and does not export private keys. It has an endorsement key, usually with a certificate from its manufacturer, which lets it prove it is a genuine TPM. Operating systems use it for disk encryption, protected credentials and attestation, for example to show a device management service that a PC is genuine before enrolling it.; Also called: Trusted Platform Module; Chapter 25: Machines with passports: device identity
Trust anchor#: A public key or certificate that a relying party trusts directly, where path validation ends.; Trust anchors are usually root certificates in a trust store, but any certificate or key can be configured as one, for example your own client CA in a server's mutual TLS settings. Everything a client accepts traces back to a trust anchor, so the list of anchors should be as small and deliberate as possible.; Also called: anchor; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Trust on first use (TOFU)#: Accepting a key the first time you see it and then warning if it ever changes, as SSH does by default.; On the first connection, the client shows the server key's fingerprint and remembers the key if you accept it. Later changes trigger a warning. TOFU is simple, but the very first connection is unprotected, and most people accept fingerprints without checking them. SSH host certificates remove the need for it.; Also called: TOFU; Chapter 25: Machines with passports: device identity
Trust store#: The list of root certificates a system or application trusts, used as the starting point for checking every certificate chain.; Operating systems, browsers, Java (cacerts), Python (often certifi) and Node.js each may use a different trust store, which is why a certificate can work in one tool and fail in another. Adding a root to a trust store is a powerful act: that CA can then vouch for any name. Private CAs and TLS inspection proxies need their roots added deliberately.; Also called: root store, CA bundle, truststore; Chapter 12: Who do we trust? CAs, trust stores and self-signed certificates
Two-tier PKI#: A CA hierarchy with an offline root CA that signs one or more online issuing CAs, which issue the end-entity certificates.; The root's key stays offline in an HSM and is used only in key ceremonies, so it is very hard to steal. The issuing CAs do the daily work and can be revoked and replaced by the root if something goes wrong. It is the most common design for private PKIs; larger organisations sometimes add a third, policy tier.; Also called: two-tier hierarchy, two-level PKI; Chapter 22: A CA of your own: private two-tier PKI

V

Validity period#: The time window between a certificate's notBefore and notAfter dates during which it may be accepted.; Clients reject a certificate before notBefore and after notAfter, comparing against their own clock. Maximum validity periods for public TLS certificates are set by the CA/Browser Forum and are getting shorter in steps. Expired certificates are one of the most common causes of outages, which is why automation and inventories matter.; Also called: notBefore, notAfter, certificate lifetime; Chapter 8: Anatomy of an X.509 certificate

W

Wildcard certificate#: A certificate for a name like *.example.com, which matches any single label in that position but not the bare domain or deeper names.; *.example.com matches www.example.com and shop.example.com, but not example.com itself and not a.b.example.com: the wildcard covers exactly one label. Add the bare domain as its own SAN entry if you need it. Wildcards are convenient but spread one private key over many services, so a single leak affects them all.; Also called: wildcard; Chapter 9: Names and jobs: SANs, wildcards, key usage and the CA flag
Workload identity#: An identity given to a piece of running software, such as a service or job, rather than to a person or a machine.; In cloud and container platforms, workloads come and go constantly, so identities are issued automatically, often as short-lived certificates or tokens, based on attested facts such as the namespace and service account. SPIFFE standardises the format. Workloads then authenticate each other with mutual TLS instead of shared passwords.; Also called: service identity, machine identity; Chapter 23: Both sides show ID: mutual TLS

X

X.509#: The standard format for public-key certificates used in TLS, code signing, email and most other PKIs.; X.509 comes from the ITU-T; RFC 5280 profiles it for the internet. A version 3 certificate contains a serial number, signature algorithm, issuer, validity period, subject, the subject's public key and extensions such as the subject alternative name, key usage and basic constraints, all signed by the issuer. SSH certificates and PGP keys use other formats.; Also called: X.509 certificate, X.509v3; Chapter 8: Anatomy of an X.509 certificate
X25519#: A fast, widely used elliptic-curve Diffie-Hellman function on Curve25519, the default key exchange in most TLS 1.3 connections.; X25519 (RFC 7748) uses 32-byte public values and is designed to be easy to implement safely. In TLS 1.3 it provides the ephemeral key exchange that gives forward secrecy. Browsers now combine it with ML-KEM-768 in the hybrid group X25519MLKEM768 to protect against future quantum computers.; Also called: Curve25519; Chapter 4: Key exchange and hybrid encryption

Early edition. Checked against the standards; an independent expert review is in progress. Found a mistake? Tell us.

Last reviewed 20 October 2026

A

B

C

D

E

F

G

H

I

K

L

M

N

O

P

Q

R

S

T

V

W

X

Can we count your visit?