8 Public Key Infrastructure and X.509 Digital Certificates: know who you are talking to

Public key cryptography secures data, but it doesn’t, by itself, prove who owns a given public key. During initial handshakes, an attacker can swap in their own key and intercept traffic. To bind a public key to an identity, systems rely on X.509 digital certificates and a Public Key Infrastructure (PKI). A certificate packages a public key with identity and operational metadata, allowing clients to decide whether to trust the key they received. Developers mainly need to recognize three core fields: subject (who the certificate is for), issuer (who signed it), and validity (when it’s usable). Subject Alternative Name (SAN) extends identity to include network identifiers—most importantly DNS names for servers—while certificates are distributed in common encodings such as PEM, DER, and PKCS#12.

In practice, developers inspect certificates to verify identity and fit-for-purpose. The subject and SAN fields must match the service being contacted (for example, the requested DNS name), and the key type/parameters (RSA or elliptic curve) must be acceptable for the application’s security profile. Validity enforces time-based use; shorter lifetimes reduce risk because private keys are hard to protect over long periods. Tools like OpenSSL make it straightforward to download, view, and parse certificates without needing to alter application code, and understanding the core formats and fields simplifies troubleshooting across languages, frameworks, and platforms.

Verification hinges on digital signatures and the certificate’s signature algorithm, but trust comes from building a chain of trust from the end-entity certificate through one or more intermediates to a trusted root in the local trust store provided by operating systems and browsers. A common failure—“unable to get local issuer certificate”—usually means the verifier can’t assemble that chain. Successful verification also requires checking dates, intended usage, and SAN matches, and then considering operational risk: even a valid certificate is unsafe if the owner’s private key is compromised. When compromise is discovered, revocation via CRLs or OCSP communicates that loss of trust. The developer’s takeaway is to combine algorithmic checks (signature, chain, dates, name) with risk assessment (CA trust and key hygiene) to confidently know who you are talking to.

Public keys are exchanged over an insecure connection can be modified by a man in the middle attacker. The client needs a way to validate that the public key it received from the server has not been tampered with. Using X.509 digital certificate the client can determine who the public key belongs to.

DigiCert Certificate authority with a full list of certificates of the certificate authority

Details Links for the certificate of the DigiCert TLS Hybrid ECC SHA384 2020 CA1 certificate authority

How trust is established by following the certificate chain to a trusted root certificate authority. Hint read this diagram from the bottom to the top.

• X.509 certificates contain a public key and metadata about who owns the key and who issued it.
• The three key certificate fields developers need to know are Subject (owner identity), Issuer (certificate authority), and Validity (time range).
• Subject Alternative Name (SAN) extension lists network addresses like DNS names, emails, IP addresses, or URIs.
• Certificate authorities (CAs) digitally sign certificates to prove authenticity and prevent tampering.
• Root CAs are self-signed and pre-installed in operating systems, while intermediate CAs create a safer trust hierarchy.
• Certificate verification follows a chain of trust from end-entity certificate to intermediate CA to trusted root CA.
• Common certificate formats include PEM (text-based), DER (binary), and PKCS#12 (can store multiple certificates and keys).
• Certificate validation checks digital signatures, validity dates, and that the CA is trusted.
• Certificate revocation lists (CRLs) track stolen or compromised certificates that should no longer be trusted.
• OpenSSL command-line tools can inspect, verify, and create certificates for testing and development.

FAQ