X.509 Certificate Fields
| Field | Contents | Why It Matters |
|---|---|---|
| Subject | Who the certificate belongs to (domain name, person, organization) | Identity being certified |
| Subject Alternative Names (SANs) | All domain names/IPs this certificate is valid for | Modern certificates list all valid names here; browsers check this field |
| Issuer | Which CA signed this certificate | Identifies whose trust chain to follow for verification |
| Public Key | The public key belonging to the subject | The key the CA has vouched for — used for TLS key exchange |
| Validity Period | Not Before and Not After dates | Certificate expires — must be renewed; expired certs produce browser warnings |
| Serial Number | Unique identifier assigned by the CA | Used in CRL and OCSP for revocation status checks |
| CA Signature | CA's digital signature over all above fields | Cryptographic proof the CA vouched for this binding; tamper-evident |
Certificate Chain of Trust
1
Root CA (Trust Anchor)
Self-signed certificate. Pre-installed in OS/browser trust store. Private key kept in HSM in physically secured facility. Almost never used to sign end-entity certificates directly.
Self-signed certificate. Pre-installed in OS/browser trust store. Private key kept in HSM in physically secured facility. Almost never used to sign end-entity certificates directly.
↓ Root CA signs Intermediate CA certificate
2
Intermediate CA
Certificate signed by Root CA. Signs end-entity certificates. Can be revoked without compromising the Root CA. Multiple intermediates allow operational segregation (one for TLS, one for code signing, etc.).
Certificate signed by Root CA. Signs end-entity certificates. Can be revoked without compromising the Root CA. Multiple intermediates allow operational segregation (one for TLS, one for code signing, etc.).
↓ Intermediate CA signs server certificate
3
End-Entity (Leaf) Certificate
The certificate installed on the server (bank.com). Sent to clients during TLS handshake. Verified by tracing up the chain: Intermediate → Root → trusted store match.
The certificate installed on the server (bank.com). Sent to clients during TLS handshake. Verified by tracing up the chain: Intermediate → Root → trusted store match.
Browser verification: (1) Is the server cert signed by an Intermediate CA I recognize? (2) Is that Intermediate CA's cert signed by a Root CA I trust? (3) Is that Root CA in my trusted store? If all three check out → connection trusted.
CSR Process: Getting a Certificate
1
Generate key pair
Admin generates a private/public key pair on the server. The private key is never shared — it stays on the server.
Admin generates a private/public key pair on the server. The private key is never shared — it stays on the server.
↓
2
Create CSR
Admin creates a Certificate Signing Request containing the public key, domain name, organization info, and SANs. The CSR is signed with the private key — proves possession of the private key.
Admin creates a Certificate Signing Request containing the public key, domain name, organization info, and SANs. The CSR is signed with the private key — proves possession of the private key.
↓
3
Submit to CA
CSR sent to CA. CA validates domain control (DV) and/or organization identity (OV/EV). Only the public key + identity claims travel to the CA — never the private key.
CSR sent to CA. CA validates domain control (DV) and/or organization identity (OV/EV). Only the public key + identity claims travel to the CA — never the private key.
↓
4
CA signs certificate
CA verifies the request, wraps the public key and identity info in an X.509 structure, and signs it with the CA's private key. Returns the signed certificate to the administrator.
CA verifies the request, wraps the public key and identity info in an X.509 structure, and signs it with the CA's private key. Returns the signed certificate to the administrator.
↓
5
Install certificate
Admin installs the certificate on the server alongside the private key. The server now presents this certificate during TLS handshakes. Clients verify the CA's signature to confirm authenticity.
Admin installs the certificate on the server alongside the private key. The server now presents this certificate during TLS handshakes. Clients verify the CA's signature to confirm authenticity.
Revocation Methods Compared
| Method | How It Works | Timeliness | Drawbacks |
|---|---|---|---|
| CRL | CA publishes a list of revoked certificate serial numbers; browsers download and cache it | Hours to days — lag between revocation and cache update | Lists grow large; caching introduces delay; soft-fail (browser uses cert if CRL unreachable) |
| OCSP | Client queries CA's OCSP responder with cert serial number; gets real-time status | Real-time | Extra latency per connection; exposes user's browsing to CA; soft-fail means attackers can block OCSP |
| OCSP Stapling | Server pre-queries OCSP, staples signed response to TLS handshake; client receives it with cert | Near real-time (stapled response timestamped, typically valid 24–48h) | Server must refresh staple regularly; slightly larger TLS handshake |
Wildcard vs. SAN Certificates
| Property | Wildcard (*.example.com) | SAN Certificate |
|---|---|---|
| Coverage | All subdomains at ONE level: www, api, mobile, etc. | Explicit list of any domains/IPs/email addresses |
| Sub-sub-domains | NOT covered: staging.api.example.com not matched | Can be explicitly included as a SAN |
| Multiple domains | Only one domain: *.example.com. Cannot cover another.com | Can cover completely different domains: example.com AND another.com |
| Risk | One compromised cert exposes ALL subdomains | Compromise limited to specifically listed names |
| Management | Simpler — one cert for all subdomains | More flexible but requires listing all names |