X.509 certificates and PKI
Binding public keys to identities
How it works
An X.509 certificate binds a public key to a subject (such as a domain name) and is signed by a certificate authority (CA). Clients trust a certificate by building a chain from it through intermediate CAs to a trusted root. Version 3 certificates carry extensions such as Subject Alternative Name, Key Usage and Basic Constraints.
Status: The standard certificate format; use SHA-256 or stronger signatures.
Strengths
- Scales trust across the internet through a hierarchy of CAs
- Standardised format used by TLS, S/MIME, code signing, smart cards and VPNs
Weaknesses and known attacks
- A compromised or careless CA can issue certificates for any domain (for example the DigiNotar breach in 2011).
- Revocation checking is unreliable in practice.
- Certificates signed with MD5 or SHA-1 are forgeable through collisions.
- Expired certificates cause outages if renewal is not automated.
Use it for
- TLS server and client authentication
- Code signing, email signing and encryption, device identity
Don't use it for
- Self-signed certificates on public services
- Wildcard certificates where their wide blast radius is not acceptable
Exam tip
Know the chain: root CA, intermediate CA, leaf certificate. The CA signs with its private key; clients verify with the CA's public key. A CSR contains the public key, never the private key.
References
Go deeper
Glossary: Public key infrastructure
Glossary: Digital certificate
Port 443: HTTPS
OCSP / CRL
Checking whether a certificate has been revoked
Pinning
Restricting which certificates or keys an application accepts
TLS 1.3
Secure transport protocol
Sign vs encrypt
Choosing the right key for confidentiality or authenticity
RSA
Public-key encryption and digital signatures