Digital Certificates — Term Reference

A digitally signed document that binds a public key to an identity (domain, person, organization). Issued and signed by a Certificate Authority (CA) after identity verification. The CA's signature vouches that the public key belongs to the claimed identity — enabling trust without prior relationship.

The ITU-T standard defining the format of digital certificates. All TLS/SSL certificates follow X.509 format. Key fields: Subject, Issuer, Public Key, Validity Period (Not Before / Not After), Subject Alternative Names (SANs), and the CA's digital signature over all fields.

A trusted third party that issues and signs digital certificates. Verifies the identity of certificate requestors before signing. CAs may be public (trusted by browsers and operating systems worldwide — DigiCert, Let's Encrypt, GlobalSign) or private (internal organization CA trusted only within that organization's systems).

The top-level Certificate Authority in a trust hierarchy. Root CA certificates are self-signed and pre-installed in operating systems and browsers (the trust anchor). Root CAs almost never sign end-entity certificates directly — they sign intermediate CA certificates. Root private keys are stored in HSMs in physically secured facilities.

A Certificate Authority whose certificate was signed by a Root CA or another Intermediate CA. Signs end-entity (server, user) certificates. Intermediate CAs provide defense in depth: if an intermediate CA is compromised, it can be revoked without compromising the Root CA. The Root CA remains isolated and secure.

The hierarchical structure connecting a server certificate to a trusted Root CA. Typical chain: Root CA → Intermediate CA → End-entity certificate. A browser verifies each link: the server cert is signed by the Intermediate CA, the Intermediate CA cert is signed by the Root CA, and the Root CA is in the browser's trusted store.

A message generated by a server administrator containing the server's public key and identity claims (domain name, organization), signed with the server's private key. Submitted to a CA for certificate issuance. The private key is never included in or sent with the CSR — only the public key.

A certificate signed by its own private key rather than by a CA. The subject and issuer are the same entity. Not trusted by browsers or operating systems by default — browsers display an "untrusted" warning. Used for internal testing, internal services where trust can be manually configured, or as Root CA certificates (which are necessarily self-signed).

A certificate extension listing the additional domain names, IP addresses, or email addresses that the certificate covers. Modern certificates list all covered names as SANs (Common Name alone is deprecated by browsers). A SAN cert can cover multiple unrelated domains: bank.com, payments.bank.com, bankapp.net.

A certificate covering all subdomains at one level with an asterisk: *.example.com covers www.example.com, api.example.com, mobile.example.com — any single label. Does NOT cover sub-sub-domains (staging.api.example.com) or the apex domain (example.com) unless specifically listed. Reduces the number of certificates needed for a single domain's subdomains.

A list published by a CA of all certificates that have been revoked before their expiration date. Browsers periodically download and cache CRLs. Drawbacks: CRLs can be large; there is a lag between revocation and browser cache update; browsers may accept revoked certificates if their cached CRL is outdated.

A real-time certificate status check — the client queries the CA's OCSP responder with a certificate's serial number and receives a signed response: "Good," "Revoked," or "Unknown." More timely than CRL. Drawbacks: adds latency per connection; exposes browsing activity to the CA (privacy concern).

A TLS extension where the server itself queries the CA's OCSP responder and includes the signed, time-stamped OCSP response (stapled) in the TLS handshake. The client receives certificate validity confirmation without making a separate OCSP request. Eliminates the latency and privacy concerns of client-side OCSP while providing real-time revocation status.

A technique where an application is configured to only accept specific certificates or public keys for specific connections, regardless of what the OS trust store says. Prevents MITM attacks even if a rogue CA is trusted. Drawback: pins must be updated when certificates are renewed — mobile apps with pinning can break on certificate rotation.

A critical vulnerability in OpenSSL's TLS heartbeat extension (2014). An attacker could send a crafted request causing the server to return up to 64KB of memory contents — potentially including private keys, session keys, and credentials. Affected millions of servers. Required patching OpenSSL, revoking and reissuing all certificates, and changing passwords and session tokens.

A framework requiring CAs to log all issued certificates to public, append-only CT logs. Allows domain owners and the public to monitor for unauthorized certificates issued for their domains. Browsers require CT log inclusion for trust. A CA issuing a rogue certificate will have it publicly logged — detectable by the domain owner.